I have been playing with the time target setting, and several things are apparent.

1. (as advertised) the run only ever stops at the end of a "chunk" of work, called a model in some of the posts, and (if I have not misunderstood) called a "decoy" on the results page.

2. this chunkiness means that the length of a run is nver going to be exactly the target. If you typically run 20 chunks in a single wu, then the timing will vary by around 5%. If you typically run only 3 chunks in a wu then the timing will vary by around 33%.

3. On a very slow box the work will overrun as the app never stops until it has done at least one chunk.

4. The timings are updated "on the fly" at the end of each chunk - this means that if you change your setting and manually force an update of the client while a rosetta wu in progress, then the new timing will be applied to the run that is in progress.

Health Warning: doing this plays havoc with your cache size, as the timie control is done in the app (the bit written by Rosetta) and the poor client (the bit written by BOINC) does not know what is going on.

For example: if you have a 5 day cache full of 2hour jobs, that will be a cache of 60 WU. Change the timing to 1 day each, and you still have 60 jobs, but they last 1 day each now. Also the client will not know right away that you have done this, and will take a while to spot that it should not be in earliest deadline mode.

Advice: when increasing the timing, always do it when you have a small cache only, or increase just one step at a time on the drop-down list.

5. In particular, if you reduce the time to 1 hour when the run has already passed that point, it will stop at the end of the current chunk. This effectively makes the one-hour option a friendly alternative to the abort facility, where the run will end soon but you get full credit for the work done so far.

Her is one I did earlier. You can see that the setting was set to 1 day (86400 sec) inititally, but that it was reduced to 1 hour (3600 sec) later on. The run actually ended nowhere near either of these settings - having got well past 1 hour it carried on till the end of its current chunk.

Example of useful application of this: On several of my boxes Rosetta is second priority to LHC, which only has work intermittently. I intend when I notice that LHC has got new work to use the 1 hour setting to clear out the Rosetta work to give LHC a higher share. The sequence of changes would be
- set no more work on Rosetta on the client
- set 1 hour on the Rosetta website
- update Rosetta
When LHC ran out again
- set 1 day on Rosetta website
- set allow work fetch.

This is a very useful new setting when used as designed - I suggest too that there are useful side effects that can be exploited, as I have mentioned here. As always when exploiting side effects, there is no gurantee that these will continue to work in future releases.

River~~

---