Project: 6020 (Run 0, Clone 69, Gen 110)

[AtwaterFS]

Tried to run twice on my system and I got Core_A3 error occured Windows pop-up. Never seen a problem like this until now. As soon as I deleted work flder and all the other stuff I got a 6015 which ran fine as do all the others, so i assume its a bad WU?

Thanks,

Steve

[bruce]

Yes, it's a bad WU. I'll report it so it stops getting assigned.

[AtwaterFS]

Thanks, out of curiousity is there any mechanism in place to prevent bad WU's from ruining a donor's bonus @ 80% completion?

Fortunately I caught this pretty quick, but I'd assume that if someone got a bunch of these then it could ruin their day point-wise if bad WU's counted against the 80% return bonus level

[PantherX]

... I'd assume that if someone got a bunch of these then it could ruin their day point-wise if bad WU's counted against the 80% return bonus level

It is extremely rare to get bad WUs in a row. It would mean that 2 WUs out of every 10 WUs are bad which isn't correct on normal basis. I have completed 50+ SMP WUs without any error, the only exception was when the AS went haywire and gave me a WU that gave FILE_IO_ERROR. Other than that, none so far. When I was using the Classic client, I got 2 bad WUs in a row and that was over a period of nearly 9 months. To sum up, 0 bad SMP WUs during 1 month, 2 bad Classic WUs during 9 months. Do note that using -advmethods flag will increase your probability of getting a WU that is bad as these are projects in the advanced beta stage.

[bruce]

Thanks, out of curiousity is there any mechanism in place to prevent bad WU's from ruining a donor's bonus @ 80% completion?

That's a realistic concern but I don't know any way to fix that issue.

Suppose somebody (intentionally or unintentionally) did something strange to their system that caused EUEs. How is FAH going to tell the difference between those EUEs and ones caused by bad WUs?

I certainly can't tell the difference until somebody spots a trend, and even then it's difficult to know whether it's a trend that follows the hardware or the WU. It's only with the added benefit of the ModDB that I can see that the trend follows the history of the WU on various computers.

If a project has frequent EUEs, that project never makes it out of beta testing. I don't remember any project that made it to advmethods with an error rate over a couple of percent (usually it's a lot lower than that) and that's the whole point of doing advmethods testing between beta testing and before the project being declared finished with advmethods testing. To get a series of WUs that produce a total of a 20% error rate in a single client is extremely improbable unless there's a hardware problem of some sort, and that hardware shouldn't be expecting to earn bonuses.

[Mactin]

Thanks, out of curiousity is there any mechanism in place to prevent bad WU's from ruining a donor's bonus @ 80% completion?

When I got multiple EUEs running my client with -smp 11, I did not loose qualification. So I guess that there is some sort of logic in place.
In fact, is not the 80% is not agains WU completion but WU returned. A EUE does return "stuff".

[AtwaterFS]

Mmmm. Thanks all

I will admit I rarely ever see bad WU's on SMP but on GPU (ATI specifically) I will see a bad WU every month or so that will stick and try again and again until it makes client pause for 24 hrs (I think 5x EUE's is the limit). I will know its a bad WU cause I will delete WORK folder, unitinfo, etc... and I will go back to crunching for weeks...

Anyways, just curious and since it RARELY ever happens on SMP I guess I shouldn't be too concerned.

U take the good, u take the bad - just like the Facts of life I guess