So far I've had 23 of these bad PABLO_p53 WUs today. Think maybe they should be cancelled?

Same for me.
http://www.gpugrid.net/forum_thread.php?id=4513&nowrap=true#46692

I also had 2 bad units from this bunch.

The problem with canceling these units is that the error will stay with you forever, but if you let it run its course until it get 8 errors and becomes a "too many errors (may have a bug)" unit, it should in time disappear.

The problem with canceling these units is that the error will stay with you forever, but if you let it run its course until it get 8 errors and becomes a "too many errors (may have a bug)" unit, it should in time disappear.

Same here under Linux:

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

My main host got its daily quota of long workunits reduced to 1 because it had too many failures (caused by this bad batch).
Luckily there are short runs (and one other long run), so my main host is not completely shut off of this project.
This is really annoying.
This batch was working fine previously.

That will eliminate the work unit, but I think Beyond is saying that they should cancel the entire series until they fix it. That will save a lot of people some time, though fortunately they error out quickly.

also bad here:
for a few hours now, BOINC has not downloaded any new tasks, telling me that "the computer has finished a daily quota of 3 tasks" :-(((

This means that no new task can be downloaded before March 22, right?

also bad here:
for a few hours now, BOINC has not downloaded any new tasks, telling me that "the computer has finished a daily quota of 3 tasks" :-(((

This means that no new tasks can be downloaded before March 22, right?

This is a generic error, all long workunits failed on all of my hosts too overnight, so all of my hosts are processing short runs now, but the short queue is ran dry already.

The incident early this morning shows that the policy of the daily quota should be revisited quickly.
In the specific case, it results in total nonsense.

Since yesterday I have 10 Pablo long work units with an "unknown" error, and now I don't have any work unit to process.
Anyone has an idea of what to do? Any advice (other than process short units)?

... so all of my hosts are processing short runs now, but the short queue is ran dry already.

I've had 9 Pablos fail on me. I'm only receiving short runs now. Returning to Einstein until this is sorted.

Since yesterday I have 10 Pablo long work units with an "unknown" error, and now I don't have any work unit to process.
Anyone has an idea of what to do? Any advice (other than process short units)?

The system does not appear to be monitored to any great effect, if it was somebody would notice and cancel the WU's before this problem occured.

There is nothing you can do just wait 24hrs.

There is nothing you can do just wait 24hrs.

the bad thing on this is that the GPUGRID people most probably cannot "reset" this 24 hours-lock.
I guess quite a number of crunchers would be pleased if this was possible.

They have to cure the underlying problem first - that's the priority when something like this happens.

People who are having task requests rejected because their quota is exhausted may wish to set 'No New Tasks' until they read that the faulty tasks have been flushed, and these new tasks are running successfully.

BOINC rebuilds the quota quickly when tasks are returned successfully, but if you're restricted to one task per day, and that one turns out to be a faulty one, you're stuck for another 24 hours.

People who are having task requests rejected because their quota is exhausted may wish to set 'No New Tasks' until they read that the faulty tasks have been flushed, and these new tasks are running successfully.

BOINC rebuilds the quota quickly when tasks are returned successfully, but if you're restricted to one task per day, and that one turns out to be a faulty one, you're stuck for another 24 hours.

My main host got its daily quota of long workunits reduced to 1 because it had too many failures (caused by this bad batch).
Luckily there are short runs (and one other long run), so my main host is not completely shut off of this project.
This is really annoying.

People who are having task requests rejected because their quota is exhausted may wish to set 'No New Tasks' until they read that the faulty tasks have been flushed, and these new tasks are running successfully.

BOINC rebuilds the quota quickly when tasks are returned successfully, but if you're restricted to one task per day, and that one turns out to be a faulty one, you're stuck for another 24 hours.

Even worse is that all my linux host got coproc error which means bad batch crash drivers.So other project did fail to.

A restart is now done and might crash again if there still is task out.

for some reason, 2 of my PCs now received new tasks, one of them was a
PABLO_contact_goal_KIX_CMYB

and even this one failed after a few seconds.
Till now I thought that only PABLO_p53 tasks are affected.

Edit: Only now I realize that on others of my PCs, during the day, had same probleme with all kinds of different WUs, not only PABLO_93.

Can it be that all recent WUs, regardless of the type, were faulty?

It's ridiculous that these bad tasks weren't canceled. How many machines have been denied work because of this laziness on the admins part? I've personally received 137 of these bad WUs so far and now have 7 machines not accepting long WUs. Multiply this by how many users? This kind of thing can also happen at other projects but they cancel the the bad WUs when informed of the problem. Why not here?

And still, for hours, the junk keeps rolling out.

If we the volunteers who donate our GPUs and electrons to help in what we're to believe is real science, I would hope the people using our resources would maybe have a little better way of administering them.

They should eliminate the "daily quota" for this particular situation. and let us crunch!

Well these broken tasks will have to run their course.

The situation here still unchanged.
One of my 4 hosts luckily got a "good" WU some time last night and is crunching it.
On all other hosts BOINC still tells me

22/03/2017 05:14:41 | GPUGRID | This computer has finished a daily quota of 1 tasks

What I don't understand is why all these broken WUs cannot be removed from the queue, and why GPUGRID cannot somehow reset this daily quota junk.

By now, my frustration has reached quite a level :-(

Relax everone, we are where we are,I'm sure the admins are as frustrated as ourselves and are working to correct the situation.

On the bright side short WU's jus got a boost in computation.

short WU's jus got a boost in computation.

what does it help if they cannot be downloaded?

They can be downloaded, actually.

They can be downloaded, actually.

NOT on my machine. There comes the same notice re "daily quota of 1 task" ... :-(

They can be downloaded, actually.

NOT on my machines. There comes the same notice re "daily quota of 1 task" ... :-(

What is shown in my log is unfortunately wrong.

There is a total of 2 tasks running now. One on the slow GTX750Ti which was obviously not affacted the same way as the faster machines.
And one, to my surprise, on the GTX970.

The log, erronously shows 2 tasks on the PC with the two GTX980Ti, however, no tasks are being crunched there.

Then there is another PC with a GTX750Ti, which still shows the "quota of 1 task per day" notice.

It would of course be great if I could finally run tasks on the two GTX980ti's

Further, the log shows that a

PABLO_contact_goal_KIX_CMYB-0-4-RND2705_5

was downloaded at 10:11 hrs UTC this morning, and also errored out after a few seconds.
Can these faulty WUs indeed not be eleminated from the queue?

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

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.

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).

... 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 :-(

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 ;-)

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.

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

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

@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.

Has the problem been fixed?

Has the problem been fixed?

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.

,,,and here too
02.04.2017 01:58:39 | GPUGRID | Started download of e1s17_ubiquitin_100ns_16-ADRIA_FOLDGREED90_crystal_ss_contacts_100_ubiquitin_8-0-psf_file

SWAN : FATAL Unable to load module .mshake_kernel.cu. (999)

next WU
e1s17_ubiquitin_100ns_16-ADRIA_FOLDGREED90_crystal_ss_contacts_100_ubiquitin_8-0-2-RND0956_3

SWAN : FATAL Unable to load module .mshake_kernel.cu. (999)

During the past days, there are still WUs which fail after a few seconds.
Latest example:

e1s17_ubiquitin_100ns_16-ADRIA_FOLDGREED90_crystal_ss_contacts_100_ubiquitin_1-0-2-RND7346_8

ending after 4.38 seconds.

What I notice is that these are particularly the "...ubiquitin..." tasks.
Any explanation why this happens?

During the past days, there are still WUs which fail after a few seconds.
Latest example:

e1s17_ubiquitin_100ns_16-ADRIA_FOLDGREED90_crystal_ss_contacts_100_ubiquitin_1-0-2-RND7346_8

ending after 4.38 seconds.

What I notice is that these are particularly the "...ubiquitin..." tasks.
Any explanation why this happens?

This is still happening, just had 2 in a row