Its great that so many people are trying to be more "green" these days, but I can't quite seem to fathom the (IMO) excessive concern over infrequent and unfortunate events. Surely there have been far greater wastes of resources in our entire human history that we shouldn't get too upset over something like this?

I totally agree with that.

However in relation to AP I was thinking more of the 'set and forgetters' who have machine that exceed min spec but are otherwise 'low work output' for various reasons, would probably keep returning every AP they ever get after the deadline. And even if they did get credit for every one, each WU would have been reissued an 'extra time' for no really good reason. That is a preventable waste.

One thought I had was AP defaulting to a third 'Maybe' condition where AP,s are sent, but any 'No Reply' for an AP WU from that host switches to a 'no'.

This would stop sending AP's to computers that are unable to process them in time to meet the short deadline. The owner would still have the option of manually selecting yes/no at any time.

I am quite vocal about this because I have had a couple of AP wingmen who appear to fit that 'set and forget' profile.

Maybe one day when we're old and gray, everthing will run smoothly and efficiently.
(Oh Damn!, I just remembered hearing my dad say that, and I just realized that I already am, and nothing does!)

[quote]...
One thought I had was AP defaulting to a third 'Maybe' condition where AP,s are sent, but any 'No Reply' for an AP WU from that host switches to a 'no'.

This would stop sending AP's to computers that are unable to process them in time to meet the short deadline. The owner would still have the option of manually selecting yes/no at any time.

...

I do have to generally agree with this, however, I don't think "one strike and you're out" is the way to go. It would add more overhead to an already stressed system, but I think if this idea were to go mainstream, they would have to miss the deadline twice in a row and/or miss more than 1/4 of the deadlines to trigger the automatic cut-off.

As a matter of fact, isn't the "average turn-around time" also used to decide what tasks should/shouldn't be sent to a host? I think if someone keeps missing the 30-day deadline, and their average turn-around is 17 days, and they have 13 days worth of tasks assigned to them, I don't think BOINC is supposed to ask for work in that case. Maybe not those exact numbers, but you get what I'm saying..

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I'll go have a look and see if anyone has raise a Trak ticket regarding this.

Doesn't look like anyone has asked for it so I have raise Trak ticket 812.

I see there is a response to your requset:

12/27/08 19:17:03 changed by Nicolas ¶

I agree. But note David Anderson wrote in a different ticket:

DCF is a kludge to compensate for bad FLOP estimates by projects. I don't want to make the kludge even more complicated.

Which makes me wonder if Dr.A is actually on this planet.
When testing AP on Beta site before its release here, I noticed that Pappa's X2 6000+ and my Q6600 had similar benchmarks. From that Dr. A would assume that performance on AP tasks was similar, when it fact my computer was over twice as fast as Pappa's. Therefore with Dr.A's totally meaningless benchmarks in the BOINC client, the DCF is not a kludge but an absolute necessity.

It will be interesting to see if he has a work around or will make the kludge more complicated after all. As I pointed out on the trak ticket Seti now has 3 apps (MB, CUDA MB and AP) and Einstein is planning on 2 more as well, so that puts a bit more pressure on them to look at it.

---

BOINC blog

However in relation to AP I was thinking more of the 'set and forgetters' who have machine that exceed min spec but are otherwise 'low work output' for various reasons, would probably keep returning every AP they ever get after the deadline. And even if they did get credit for every one, each WU would have been reissued an 'extra time' for no really good reason. That is a preventable waste.

I see what you're saying, and at the beginning I understand that this was happening a lot, but as I understand it, it is happening less and less as the system adjusts appropriately and stops sending work to those clients after the proper estimates and stats have been adjusted on their machine(s). Sure, it will still happen from time to time, but I would think that its such a small percentage that I cannot advocate making it opt-in altogether. Besides, if they set-it-and-forget-it, they're probably not too worried about wasted power if they don't check up at least once in a while.

Maybe one day when we're old and gray, everthing will run smoothly and efficiently.
(Oh Damn!, I just remembered hearing my dad say that, and I just realized that I already am, and nothing does!)

LOL Nothing ever does, but if we didn't have problems, then we'd be a perfect society with perfect technology, and that type of society will never exist. Perfection is the absence of flaw and the absence of learning. I don't want to ever stop learning! :)

Let's hold the poll then:

- Should "use GPU?" be a global (rather than per-project) preference? No
- Should it default to No? Yes

I'll go have a look and see if anyone has raise a Trak ticket regarding this.

Doesn't look like anyone has asked for it so I have raise Trak ticket 812.

I see there is a response to your requset:

12/27/08 19:17:03 changed by Nicolas ¶

I agree. But note David Anderson wrote in a different ticket:

DCF is a kludge to compensate for bad FLOP estimates by projects. I don't want to make the kludge even more complicated.

Which makes me wonder if Dr.A is actually on this planet.
When testing AP on Beta site before its release here, I noticed that Pappa's X2 6000+ and my Q6600 had similar benchmarks. From that Dr. A would assume that performance on AP tasks was similar, when it fact my computer was over twice as fast as Pappa's. Therefore with Dr.A's totally meaningless benchmarks in the BOINC client, the DCF is not a kludge but an absolute necessity.

I read the same quote and I see it as being grounded in reality.

It is a kluge, and unfortunately, a necessary one.

There is no such thing as a benchmark that isn't "totally meaningless" -- every benchmark that ever existed is artificial, either producing some artificial result, or a set of arbitrary commands to some common applications.

The only "accurate" benchmark of an application's performance is the application itself.

Maybe the best way to solve this is to just replace the benchmark with some constant -- something that is very small.

But "accurate benchmark" is like "fair taxation" or the easter bunny. Fun to think about, but it doesn't really exist.

---

But "accurate benchmark" is like "fair taxation" or the easter bunny. Fun to think about, but it doesn't really exist.

Next you will be telling me that Santa Clause does not exist ...

---

But "accurate benchmark" is like "fair taxation" or the easter bunny. Fun to think about, but it doesn't really exist.

Next you will be telling me that Santa Clause does not exist ...

Actually, I'm good with Santa Claus. There are times when you truly have to believe the fiction, because it's the best you have.

---

But "accurate benchmark" is like "fair taxation" or the easter bunny. Fun to think about, but it doesn't really exist.

Next you will be telling me that Santa Clause does not exist ...

Actually, I'm good with Santa Claus. There are times when you truly have to believe the fiction, because it's the best you have.

So why do you hate the Easter Bunny?

Back to serious I sent a modified RTF file to Dr. Anderson on Work Fetch see the other thread ...

---