Got a strange "Maximum Disk usage exceeded2 error. Runtime was 4 hours and Disk has 70 GB free, BOINC is allowed up to 50 GB and 99% disk usage. I guess the output file was too big or some other WU-specific settings were not correct.

http://ralph.bakerlab.org/result.php?resultid=475000

Since the credit testing has been done, what's to do ?

I'll try to clear this up quickly and succintly - running a workunit on Ralph is currently done in the lab to demonstrate that the workunit will function across a variety of platforms. During CASP typically run in the neighborhood of 100-500 workunits on Ralph to test that the workunit's input files were valid, that the tasks assigned to Rosetta by the workunit would not cause obvious problems on any platforms, and that the workunit completed in a reasonable time. We use Rosetta@Home to run multiple copies of a workunit (my largest WU total for a single job was 1.5 million!) so that we can analyze a distribution of structures produced by Rosetta.

I hope someone rectifies this soon, you should certainly not have an account deleted for posting public information. Yes hide the post by all means (if the mod was unsure and wanted to protect something until he could get hold of the Administrator/David Baker)
Bad, Bad ,Bad managment.
Especially as they're new mods, they certainly shouldn't be doing that!

I think a checkpoint is created after a modell or decoy is finished. That's according to my observation everytime your progressbar jumps to a new value.

Theirry, the "no finished file" message means the manager temporarily lost track of the daemon. The daemon (which actually controls the work) should have kept running. It's just reporting the manager (the part you see) lost contact.

tony

OK... and that's why the Calculation time drop from 32 minutes to 18 minutes?

...

I agree, if we add encryption to rosetta, we could use the internal benchmark. It's something to consider.

You'd also need to encrypt the in-memory benchmark results as well as the upload and download, also obfuscate the actual benchmark code so that people can't follow what it's doing in a debugger and modify the values on the fly. (Remember if people can use a debugger, an out-of-process routine can do the same once the memory locations are known).

The recent debugging code (map files etc) would prove extremely useful to someone trying to do this, but aren't necessary.

The new system does the job, and should do it well after the bugs are ironed out, so why mess around with insecure ways of doing the same thing?

these are very small numbers. it should even out. there will always be differences even with the same work unit because of the random nature of the runs.

You call 70% small numbers? That are definitely not small numbers! 10-20% I would call acceptable (not worth the cherry picking).

If you can easily prevent cherry picking why not do it?

4 results - that is a small number.

I have one constructive and easy proposal though . ;-) Limit the number of WU sent to a specific host to one at a time with a one hour interval between sending work.

That would also limit people that don't give a rip about credits from loading a normal 2 or 3 day cache with work. Some (especially dial up users) only connect occaisionally, and if they can't get WUs during that time, they will be idle for the next 2 or 3 days.

these are very small numbers. it should even out. there will always be differences even with the same work unit because of the random nature of the runs.

I'm extracting the archived data and will see what I can do. What do other users think about trying to backdate the credits using the new work based system?

Everyone keep in mind that the current standard boinc crediting system will still be used.

Also, minor modifications to the credit/model values will not make that much of a difference in the long run. The important thing to know is that given any credit/model value, users will be on a level playing field. I think we can all agree that this is the major drive/motivation for coming up with a new method. Making sure it closely matches the BOIINC credit values is not as important since we will still use the old system along with the new.

does anyone object to rolling this out to Rosetta@home?