So I'm starting to see these errors on the

e4s3_e1s13p0f400-ADRIA_FOLDUBQ80_crystal_ss_contacts_50_ubiquitin_1-0-1-RND1448_0

<core_client_version>7.6.22</core_client_version>
<![CDATA[
<message>
Disk usage limit exceeded
</message>

# Access violation : progress made, try to restart
called boinc_finish

Name e2s4_e1s43p0f362-ADRIA_FOLDUBQ80_crystal_ss_contacts_50_ubiquitin_0-0-1-RND8662_3

Application version Short runs (2-3 hours on fastest card) v9.18 (cuda80)

These seem to be the same sequence of workunits as we've been discussing in Bad batch of tasks?.

Speedy's workunit 12788007 has the same error on three different computers.

Most of the tasks from this batch are faulty.
See here: http://gpugrid.net/forum_thread.php?id=4632

Thanks to both you and Richard. I see now that they part of that bad batch. Ok, nothing we can do then....

Thanks to both you and Richard. I see now that they part of that bad batch. Ok, nothing we can do then....

Thank you Toni for the response and update.

It happens. Glad they can sort this out and hopefully find out what happen to allow us to process these correctly. Science is both setbacks and successes. We learn from both.

I've just received a brand-new ADRIA short run task - e46s1_e44s2p0f280-ADRIA_FOLDPG80_crystal_ss_contacts_50_proteinG_2-0-1-RND2909_0. Hoping to catch any disk usage errors before they happen, I had a look at the file sizes.

The largest single upload file (_9) is allowed to reach 328,000,000 bytes. But the workunit as a whole is only allowed to use 300,000,000 bytes of disk space (<rsc_disk_bound>). That seems a touch inconsistent...

I'll try to keep an eye on the file size as it runs, and adjust the disk bound if I need to. So far, 1,308 KB in 15 minutes. Don't forget, we may have to allow for up to 150 MB of program files (like cufft64_80.dll) in the disk usage limit.

Reached 12.3 MB and 37.5% progress after 2 hours 15 minutes - I think this one is going to make it.

Looking at long-run tasks on a different machine, they've been given a <rsc_disk_bound> of 4 billion bytes - 4,000,000,000, more than ten times as much. It may have been the difference between the short and long run queue setups, rather than the tasks themselves, which caught Adria out last time.

Also, do I mistake or they should have been long WUs?

Also, do I mistake or they should have been long WUs?

Speedy's workunit, from the previous bad batch, ran for between 32,429 seconds (GTX 1080) and 115,002 seconds (GTX 960). Yes, I think those should have been 'long queue' values.

My current task from the new batch today is on course for a 6-hour run (GTX 970) and a 33 MB final file size - I think we're going to make it :-)

The task that ran for 150,002 seconds was on a 970.