Here goes Paul, tilting at windmills again ...

This Task Set (or whatever termonology UCB is using this week, had a 100% failure rate on all that attempted it ... now, one of my favorite projects pays even for failures because the failures are equally interesting to the project ...

I don't know how often this happens, but to me, this is a clear case where the project should also be paying (in my opinion) because we made the good faith effort to produce a result for a flawed task ... we can debate the pay rate ... but, my point is, it was not the fault of the people who did the work that you asked them to do something that was not possible ...

I know, I know, cobblestones are worthless ... well if they are... what is the beef with paying them?

Sorry Paul - is the "other" project which is paying for failures BOINC-based?

Well CPDN does and its BOINC based, but it depends on trickles to get there. Given GPUgrid doesn't use trickles that might present an issue (or an opportunity - you could have larger wu using trickles).

That would mean something along the lines of
"If enough people can't run a WU, there must be something wrong project-wise, so pay them at least something"?

Sounds fair enough, if it doesn't somehow lead to cheating. I.e. program your own app which
- checks other results of a WU
- if it finds an error, returns the same error and a certain runtime
- if it doesn't find a previous error generates a probable one and a certain runtime

MrS

How about awarding credits for failures only after a WU reaches the "too many failures" status?
____________
Thanks - Steve

Cheating is a concern, in fact, but also random errors due to overclocking/driver issues are IMHO. Up to now, the vast majority of the errors that we see are due to misconfigured hosts rather than WU mistakes. Incidentally, that's the reason why we can't reliably (ie automatically) figure out "erroneous" wu right away.

You posit this as an either or to the exclusion of both ...

This one instance is an example... I could also have, and probably should have pointed back to the many runs where the use of incorrect parameters or other problems caused the users signficant issues and many failed tasks ... less common for the moment ... but who knows when that might return?

The other point is that the whole reason for the issue multiple times is to detect these issues ... but a task that fails on 5 different systems is not likely a task that is failing for the reasons you posit ... I mean, I cannot chose the tasks to run, the only way I can do that is to abort lots of tasks and check each one on the off-chance I can find myself as the 5th of the group that has already failed 4 times before ... but in doing that I run my total tasks per day into the toilet as well ...

Sorry, but everyone seems to be looking for even the slimmest excuse to not think about doing something like this on the off-chance that one person somewhere some time might get something they don't deserve instead of thinking of all of those that are putting in hours of compute time for no pay, and that is a far larger group ...

Or are you saying that the vast majority of participants are cheaters? Heck, even the OC crowd is fairly small ... most of the people I know don't OC, it is not all that common because it is hard to do right, easy to do wrong (which means lots of bad results) ...