To my surprise, the faulty / working ratio is much better than I've expected.
I did a test with my dummy host again, and only 18 of 48 workunits were faulty.
I've received some of the new (working) workunits on my alive hosts too, so the daily quota will be recovered in a couple of days.

... so the daily quota will be recovered in a couple of days.

still it's a shame that there is no other mechanism in place for cases like the present one :-(

You are likely to be suffering from a quota of one long task per day: if you allow short tasks in your preferences, it is possible (but rare) to get short tasks allocated

that's what BOINC is showing me:

22/03/2017 13:12:42 | GPUGRID | No tasks are available for Short runs (2-3 hours on fastest card)
22/03/2017 13:12:42 | GPUGRID | No tasks are available for Long runs (8-12 hours on fastest card)
22/03/2017 13:12:42 | GPUGRID | This computer has finished a daily quota of 1 tasks

So I doubt that could get short runs.
(your assumption is correct: I should be suffering on a long runs quota only, since no short runs were selected when the "accident" happened).

The short queue is empty, and the scheduler won't send you from the long queue, because of the host's decreased daily quota. You should wait for a couple of hours.

... so the daily quota will be recovered in a couple of days.

still it's a shame that there is no other mechanism in place for cases like the present one :-(

You can't prepare a system to every abnormal situation. BTW you'll receive workunits while your daily quota is lower than its maximum. The only important factor is that a host should not receive many faulty workunits in a row, because it will "blacklist" that host for a day. This is a pretty good automatism to minimize the effects of a faulty host, as such a host would exhaust the queues in a very short time if there's nothing to limit the work assigned to a faulty host. Too bad that this generic error combined with this self-defense made all of our hosts blacklisted, but there's no defense of this self-defense. I've realized that we are this "device", which could make this project running in such regrettable situations.

When this is all over there should be a publication badge for participation in faulty Pablo WUs ;-)

When this is all over there should be a publication badge for participation in faulty Pablo WUs ;-)

Indeed. This should be a special one, with special design. I think of a crashed bug. :)

The short queue is empty, and the scheduler won't send you from the long queue, because of the host's decreased daily quota. You should wait for a couple of hours.

Sometimes you get a working long task, sometimes you get a faulty long task, sometimes you get a short task - it's very much the luck of the draw at the moment. I've had all three outcomes within the last hour.

[quote]... sometimes you get a faulty long task

this leads me to repeating my question: why were/are the faulty ones not eliminated from the queue?

why were/are the faulty ones not eliminated from the queue?

My guess - and it is only a guess - is that the currently-available staff are all biochemical researchers, rather than specialist database repairers. BOINC server code provides tools for researchers to submit jobs directly, but identifying faulty (and only faulty) workunits for cancellation is a tricky business. We've had cases in the past when batches of tasks have been cancelled en bloc, including tasks in the middle of an apparently viable run. That caused even more vociferous complaints (of wasted electricity) than the current forced diversion of BOINC resources to other backup projects.

Amateur meddling in technical matters (anything outside your personal professional skill) can cause more problems than it's worth. Stefan has owned up to making a mistake in preparing the workunit parameters: he has corrected that error, but he seems to have decided - wisely, in my opinion - not to risk dabbling in areas where he doesn't feel comfortable about his own level of expertise.

@Richard: what you are saying sounds logical

Though I once posted some good numbers to the project, I've been away for awhile and lost track of how BOINC ought to work.

I still do not have new tasks after my own set of failed tasks.

Is there anything I need to do "clear my name" so that I get tasks?

I've just picked up a 4th replication from workunit e34s5_e17s62p0f449-PABLO_p53_mut_7_DIS-0-1-RND8386. From the PABLO_p53 and the _4 at the end of the task name, I assumed the worst - but it's running just fine. Don't assume that every failure - even multiple failures - comes from a faulty workunit.

As to what to do about it - just allow/encourage your computer to request work once each day. Perhaps you will be lucky and get a good one at the next attempt, or you may end up with several more days' wait. It'll work out in the end.

I've just picked up a 4th replication from workunit e34s5_e17s62p0f449-PABLO_p53_mut_7_DIS-0-1-RND8386. From the PABLO_p53 and the _4 at the end of the task name, I assumed the worst - but it's running just fine. Don't assume that every failure - even multiple failures - comes from a faulty workunit.

If there's the

ERROR: file mdioload.cpp line 81: Unable to read bincoordfile

message in many of the previous task's stderr.txt output file, then it's a faulty task.
The one you've received is failed 4 times, from 3 different reasons (but none of them is the one above):

1st & 3rd:

<message>
process exited with code 201 (0xc9, -55)
</message>
<stderr_txt>
# Unable to initialise. Check permissions on /dev/nvidia* (err=100)

</stderr_txt>

2nd (that's the most mysterious:)

<message>
process exited with code 212 (0xd4, -44)
</message>
<stderr_txt>

</stderr_txt>

4th:

<message>
(unknown error) - exit code -80 (0xffffffb0)
</message>
<stderr_txt>
...
# Access violation : progress made, try to restart
called boinc_finish

</stderr_txt>

BTW things are now back to normal (almost), some faulty workunits are still floating around.

Has the problem been fixed?

Has the problem been fixed?

Yes.
There still could be some faulty workunits in the long queue, but those are not threatening the daily quota.

These error units are starting to disappear from the tasks pages. Soon, they will be all gone, nothing more than a memory.


Good bye!!!!

Trouble is, I'm starting to ses a new bad batch, like

e1s2_ubiquitin_50ns_1-ADRIA_FOLDGREED10_crystal_ss_contacts_50_ubiquitin_1-0-1-RND7532

I've seen failures for each of contacts_20, contacts_50, and contacts_100

I just got one an hour ago, that failed after two seconds.
e1s2_ubiquitin_20ns_1-ADRIA_FOLDGREED10_crystal_ss_contacts_20_ubiquitin_6-0-1-RND9359

e1s9_ubiquitin_100ns_8-ADRIA_FOLDGREED10_crystal_ss_contacts_100_ubiquitin_4-0-2-RND2702 is running OK, so they're not all bad.

Same here, 6 broken Adria WU out of 8, in 12 hours so far. Failing immediately.