In production, devices that constantly error out on the same science are put on a 1 per day drip for that science until actioned/investigated/reported by the volunteer to either work to resolve the problem or opt-out. This science IS an explicit opt-in at that, the ratings now known where WCG will schedule an investigation and endeavor to find a solution... Some of the sciences are now on version 6.17-6.19... revealing enough for me

Interesting point, which doesn't seem to apply here. The RC=0x4 causes devices to almost constantly get an inconclusive, followed by invalid, status. I'm assuming this doesn't count as an "error", as a device can do 2 such WUs per day for weeks without ever being throttled back to 1/day.

Aborts and Errors and Invalids go towards the demerit for all I know and if latter does not, it's something to consider... but why speculate, here's the first line of the logic notes from knreed:

"It is updated for each valid or invalid result as shown below:"

The number will go down to 1, no matter how slow the return is. It's not like you're building credit for unused quota. Then, if you're happy to return invalid results, there's these period reports and the hand wrench to force the attention. It's not like WCG is happy to continue to receive invalid tasks from zombies. The old UD client in that was better. There would be an actual pop up, and on that to end this item, the 6.12 client is getting a notification function.

edit: Just don't know if your OS will support it. Maverick Meerkat Linux 10.10 is not going to support any CPU below a 686 either.

I seem to be the lucky owner of a computer that almost always produces valid results. I have had a few problems with HPF2 (endless loop) and I was caught a few years back by some project code that ran on Intel CPUs but not on AMD CPUs. But I remember the incredible frustration I felt as a working programmer trying to track down bugs that would only occur on certain computers. I once tracked such a problem down to a program running in the background that needed updating, but that was on my own computer, which was loaded for all sorts of software environments. In general the problem would occur on somebody else's computer and I would not have access to it. Usually I would just have to mutter and shrug. Add a note to the program log documenting the error and drink another cup of coffee. You need to be able to stand a lot of frustration or you burn out early.

The WCG projects are running on computers all over the world with an incredible number of software environments. I doubt that any large program will run without any errors caused by conflicts. So I am not surprised to hear that the WCG staff only concentrate on fixing errors that are having a substantial effect on the results. That is good software management.

I understand why Kremmen feels so frustrated that his computer has a conflict with one of the project programs. But frustration of that sort is endemic in the software profession. Taking it out on other people is unprofessional. But we all of us are occasionally guilty of letting our personal frustration show. Other people have pointed this out to Kremmen. Now we should let the subject drop, instead of piling up on Kremmen like an over-enthusiastic high school football team.

Lawrence

Yes, this seems to be an accurate description of the new per-application quota-system... But, I've not seen any indication WCG has upgraded their scheduling-server resently, so until WCG upgrades, they're using the old quota-code, and this doesn't decrease the quota for validation-errors. Also, the biggest weakness of the old code is that someone that runs a mix of WCG-projects, can happily continue trashing many tasks in a single project, but will continue getting a full quota since the tasks in the other WCG-projects keeps the quota high.