hmmm, well, check the swap file permissions and the size it can grow. Must be a new record setter and not even sure BOINC was ever tested to handle sizes such as here with 2GB per job.

Maybe uplinger is listening in on this

hmmm, it struck me middle of the night that 2Gb might have been the job size limit and a message maybe should have been generated to that effect and then auto-aborted? The Client_state.xml would be able to tell with a value like <max_nbytes>2097152000.000000</max_nbytes> which in BOINC speak rounds to 2.1Gb.

Go ahead and abort Diana G.

<max_nbytes> is how large a specific upload-file can become, it's not how much disk-space the task can use during running. Max disk-space is <rsc_disk_bound>, and if task isn't mis-configured, this should always be larger than <max_nbytes>, both since can be multiple upload-files per task, and since log-files and so on normally isn't uploaded, or if uploaded is part of the scheduling-server-report.

Then it comes to memory-usage, there is the <rsc_memory_bound>, but this limit has no effect in current BOINC-clients. Instead, the actual memory-usage is checked, and can lead to pausing (with or without removing from memory) if exceeds the <ram_max_used_busy_pct>. If also exceeds the highest of the *busy_pct and *idle_pct, the task will be aborted.

If a computer has example 3 GB ram, and a 90%-setting, a task using 2 GB memory won't be aborted for exceeding ram.

BTW, if DDDT is 32-bit, it's a chance the application can't address more than 2 GB memory, so even if computer has 3+ GB memory, the task can refuse to run correctly. Still, if this is the problem here, it's a bug that the application doesn't terminate with a memory-error when hitting the 2 GB-limit...

I bet none of us would object if they started over and handed out a bunch of those big hour WUs again... you know, just to make sure the problem is fixed.

To put it somewhat bluntly. This beta test went really really badly. We found a lot more issues than usual and we are working through now. We hope to be able to run another round of beta testing again (and this time we expect greater success).

As for beta tests sometimes resulting in credit not being fairly awarded? That is unfortunately part of beta testing. That is why we have it on a special part of the website where you have to take deliberate action in order to participate. We are sometimes able to take action to award the credit manually, but in this case the errors were all over the place and it would have required a decent amount of time to manually grant credit. We apologize for the loss.