I started to put this in the bug thread since I know that thread gets read but since this is not a bug report but a concern I'll post here and hope someone notices. BAF5__BOINC_SYMM_FOLD_AND_DOCK_RELAX_ONLY-BAF5_-lowres_dock_-dock_2983__3222_1 took over 26 hours to complete a single model. I opened the graphics window every now and then to take note of the step # and make sure it was making progress and when it looked like it might not be done in 24 hours (4x my runtime pref of 6 hours) I increased my runtime preference to 8 hours and updated in hopes of actually completing a model. Not something one could expect to happen on Rosetta. I know my older mac takes a good bit longer than most but I was also under the impression that most folks have a shorter runtime preference. The concerns then are one, folks looking but not looking closely enough may abort tasks they mistakenly think are stuck and two, if most folks can't complete a single model after many hours of crunching they are also unable to contribute to the science. I would think this would be frustrating both for them and the project and a great waste of resources. Even if they manage to complete a model by going way over their runtime pref they may be in danger of missing the deadline, especially if they run other projects. Not detrimental to the science perhaps but inefficient.
When these tasks are sent out by the main project does the scheduler limit them to faster computers with certain minimum runtimes or is it the luck of the draw? If not would an increase in the default and minimum selectable runtimes be in order? I realize most tasks probably aren't hurt by one or two hour runtimes but what are the cons if they are made to run longer?

I realize my perception may be warped by my older Mac machine and by lack of data and thus may not be worth two cents but, hey, I'm offering it for free:)

Snags

Additional question on devs according to run time preferences: here at RALPH, is it better to prefer testing larger number of workunits (producing less decoys for each one, 1-5), or rather somewhat more decoys (5-15-...) from each WU, at the expense of the number of tested WUs?

Or does it really not matter?

Peter

Additional question on devs according to run time preferences: here at RALPH, is it better to prefer testing larger number of workunits (producing less decoys for each one, 1-5), or rather somewhat more decoys (5-15-...) from each WU, at the expense of the number of tested WUs?

Or does it really not matter?

Peter

I don't know. Here I leave the run time at "not selected". I figure that way the developers can change the time if needed.

---

BOINC WIKI

BOINCing since 2002/12/8

...run time preferences: larger number of workunits or more decoys?

I don't know. Here I leave the run time at "not selected". I figure that way the developers can change the time if needed.

The prefs page says: "Target CPU run time (not selected defaults to 1 hour)" and I was thinking of enlarging my target time from 2 hours :-)


Good that you wrote "that way the developers can change the time if needed", I was looking around for the exact meaning and found dekim's comment:

We would prefer lower run times so that results are returned quicker.

So I'll rather stick to my 2 hours (trade-off between still somewhat faster turn-around and not just one decoy).

Peter

So I'll rather stick to my 2 hours (trade-off between still somewhat faster turn-around and not just one decoy).

I thought the idea of RALPH was to test the program rather than produce decoys. Therefore just one decoy per work unit is sufficient. If it runs ok then the theory works. I have had a few envtest62 runs which vary wildly from over 1 hour to over 3 hours. Having several more decoys per work unit won't prove the point any better.

If it is really true, that just the applications are tested, not also the data, then you i]might[/i] be true.

But still just might, because you have to test the apps' behavior with some (real) data and the more data you feed the apps with, the better they are tested.

I had the impression on one occasion that a second model actually took less time than the first model but I didn't jot down any numbers at the time and I might have well have been mistaken. If not it might point to why the project would like to see more than one model completed for each wu here on ralph. Only someone from the project can say for certain if there is any value in running more than one model.

What prompted this thread though was the observation that more of the wus are taking longer to complete that first model. Once it goes past your runtime preferences BOINC no longer has any idea how long it will take and and the "time to completion" will no longer update. At which point the wu appears stuck. I've noticed a good many reports both here and on rosetta@home of runs ended by the watchdog and of folks aborting stuck wus. In some cases the folks have given enough information to indicate that they are giving up on the wu before the watchdog would have. Which seems a waste both here and on r@h.

Snags

...is it better to prefer testing larger number of workunits (producing less decoys for each one, 1-5), or rather somewhat more decoys (5-15-...) from each WU, at the expense of the number of tested WUs?

There could indeed be a reason to also test single WUs for a longer time.
feet1st wrote:

This one mini_abinitio-1bk2_-test_2008-2-6_3310_73_0 shows peak memory of 867MB! It's 17hrs in to a 24hr runtime preference on WinXP.

Memory does not seem to be growing without bounds (i.e. no memory leak), just seems to use a lot, then free it again at various times as it runs.

Peter

I've found, more then once, bugs that only turned up when you ran WUs for the maximum time. Outfiles growing beyond their max size, etc. Not that we should all do it, but, someone should test that upper limit on runtime.

---