My settings are for 4 hrs run times, but these specific tasks ran 6 hrs without me touching a thing.

abinitio_norelax_homfrag_129_B_4icbA_SAVE_ALL_OUT_4626_4561_0
https://boinc.bakerlab.org/rosetta/result.php?resultid=218675744

abinitio_norelax_homfrag_129_B_5croA_SAVE_ALL_OUT_4626_4561_0
https://boinc.bakerlab.org/rosetta/result.php?resultid=218675745

abinitio_norelax_homfrag_129_B_1a8oA_SAVE_ALL_OUT_4626_4562_0
https://boinc.bakerlab.org/rosetta/result.php?resultid=218675747

And so the last model of each was "long-running".

---

Rosetta Moderator: Mod.Sense

I want to start out by saying this is entirely based on my observations over the years of Boinc and how it behaves.


I've seen the situation where within one workunit the models take quite different times to complete. So, a WU starts running. A model completes. Boinc then says "Based on the time used so far and the number of models I've completed and the time remaining, can I squeeze in another model?" If the answer is no, it decides the workunit is done, reports the results back and goes on the the next workunit. If the answer is yes, then it starts another model and then repeats the process.

However, lets say you have a 4 hours time limit. You've completed some number of models in the currently running workunit. The average time for completion for these models is 30 minutes each. You have a bit over 30 minutes left in your 4 hour time limit. So, Boinc figures it can complete another model. However, for some reason this model takes 2 hours to complete. What happens? The model runs to completion and the time for the workunit comes out to be close to 5 1/2 hours. That's way past your 4 hour run time but Boinc had no way of knowing the last model would take so long.

Also, when this happens, Boinc recalculates the run time of the other workunits in your queue. Typically from what I've observed, if it needs to raise the estimate, it raises it to the run time of the workunit that just finished. If it wants to lower it, it lowers it a bit at a time. (Actually what it is doing is recalculating a number called the duration correction factor. It also does this after each workunit completes, but usually the newly calculated runtimes are close to their previous values because the actual runtime was close to the originally estimated runtime.)

Charlie

---

-Charlie

And so the last model of each was "long-running".

mod, you can move or copy or whatever my post to the long running section if you want or later i will copy/past to there

I want to start out by saying this is entirely based on my observations over the years of Boinc and how it behaves.


I've seen the situation where within one workunit the models take quite different times to complete. So, a WU starts running. A model completes. Boinc then says "Based on the time used so far and the number of models I've completed and the time remaining, can I squeeze in another model?" If the answer is no, it decides the workunit is done, reports the results back and goes on the the next workunit. If the answer is yes, then it starts another model and then repeats the process.

However, lets say you have a 4 hours time limit. You've completed some number of models in the currently running workunit. The average time for completion for these models is 30 minutes each. You have a bit over 30 minutes left in your 4 hour time limit. So, Boinc figures it can complete another model. However, for some reason this model takes 2 hours to complete. What happens? The model runs to completion and the time for the workunit comes out to be close to 5 1/2 hours. That's way past your 4 hour run time but Boinc had no way of knowing the last model would take so long.

Also, when this happens, Boinc recalculates the run time of the other workunits in your queue. Typically from what I've observed, if it needs to raise the estimate, it raises it to the run time of the workunit that just finished. If it wants to lower it, it lowers it a bit at a time. (Actually what it is doing is recalculating a number called the duration correction factor. It also does this after each workunit completes, but usually the newly calculated runtimes are close to their previous values because the actual runtime was close to the originally estimated runtime.)

Charlie

thanks charlie, thats the best explanation I have seen about this process.