tralala - the aim is to avoid and abandom always and ever ill-numbered benchmarks.
(or at least I hope and pray).

You can simply choose CPU type, divide it with CPU frequency - or golden machine, as tony suggested. I know it's not perfert, RAM speed takes place etc.
But you should fit in acceptable +- 10%, not something like 500% with benchmarks.

Just try to maintain inter-project parity, that will do...

Rom tells me it is waiting for the watchdog to finish for debugging.

Here is his response:

"When I added code .... to wait until
the thread is finished, it stalls for up to 30 minutes waiting until
watchdog makes its next check."

I think the watchdog can take up to 2x the cpu run time pref, which may explain the longer stalls.

EDIT: Can't you make a watchdog to activate the WU again, after it has been idle for, let's say 3 minutes? Or 5 minutes? Not crunching my computer goes into sleepmode after 15 minutes.

While a progress of an unit reached 100% on my BOINC client, strangely it continues to work, and % of completed on the graphic keeps less than 100%, approximately 57%.
(here you can see a screen shot of it.) And I continue to work on the unit several minutes, but it remains at the same percentage.

Is this bug or not? thanks,

I think this is related to the phenomenon Mike Gelvin was reporting that some WU remain dormant after showing 100%. Perhaps you can check the task manager for the next WU.

Instant failure, no graphics displayed but two preempted WU from Rosetta in mem:
http://ralph.bakerlab.org/result.php?resultid=145667

Have two more of those WU, will watch them closely.

How can I turn debug-information on?

While a progress of an unit reached 100% on my BOINC client, strangely it continues to work, and % of completed on the graphic keeps less than 100%, approximately 57%.
(here you can see a screen shot of it.) And I continue to work on the unit several minutes, but it remains at the same percentage.

Is this bug or not? thanks,

As you may be aware RALPH is a test project. The purpose of the User of the Day on RALPH is to test the tolerance of the user community for consistancy in this area of the homepage....

I would think for the daily quota 2 would be the minimum and the max 4 or 8. You would want to have a chance at getting multiple tasks running on multi-CPU hosts.

As for keeping work on ralph, we haven't quite got that figured out. We'd like to have jobs go out instantly to clients when we post the new app or test a new scientific mode on ralph, so that we get feedback ASAP. The problem is that if we've flooded the clients with jobs with the previous app or previous jobs, there's typically a wait for those clients to free up again.

Back to possible bugs:

Rosetta 5.06

using 161 MB of memory, 542 MB of virtuel memory

The box is a very old one, the WU has run 11 hours now, sitting with 1,04 %

I guess, it will never finish :-(

Oh, my setting for RALPH Target CPU time is 4 hours ...

This is the box: http://ralph.bakerlab.org/show_host_detail.php?hostid=1911

This is the result: http://ralph.bakerlab.org/result.php?resultid=98748

Abort or stay a little bit longer ?

At least with the current BOINC system, I can't seem to set the max WU sent to a client per day. Can you post here which project allowed you to set that as a preference?

Thanks for all the advice. I think we've largely killed the watchdog timer problem and are ready to release. (Feet1st, you noticed how bad the problem was with 5.05; has your client tried any 5.06?) We haven't seen any evidence for jobs being aborted prematurely by the watchdog, except for the tests where we forced an infinite loop.

A few quick replies:

I'll bring the debate about shorter/longer deadlines (or a mix) to the attention of the other project scientists.

I really do like Feet1st's idea to ask ralph users to lower the fraction of time their client spends on ralph. That will distribute the jobs to as many different cpus as possible. I can make a note of it on the news page next time we release.