Seconds, not minutes! A day has 86,400. IF you are on client 6.6. you have to multiply the 18000 with the number of concurrent threads running. On an I7 + HT in fact multiplied by 8. In client 6.2 there was some logic left, 18000 seconds per concurrent job.

Very off topic, sorry, but you're still doing better for WCG given that the time between fetch and cashing points for you is less than my system.

DOH!!!! I know that!!! I just haven't had enough Coffee (usually two pots to wake me up)


That's an interesting aspect I didn't know.. thanks for the enlightenment

oh well.. BTW, all the systems I build are sitting behind some BIG UPS systems. Ok Ok, the monitor goes dark but I don't care. This system will continue on for about 16 Hrs before the UPS gives up the ghost and the system will tumble to the ground.

We have:

1. FAQ for work-file sizes
2. FAQ for checkpoint frequencies.

You can set it to 30 seconds, but if the science is internally not doing one but every 20 minutes, usually when a seed/docking/position/attempt is complete, it wont do it more often. If the work file is large at checkpoint time, you'll notice, particularly on a busy system that's tight on RAM. For HCMD though, smaller than small?

Default is 60 seconds, thus effective 240 seconds for a quad under 6.6. I wanted to achieve an at most of 5 minutes, so it's 75 seconds. For 6.2.28 that value would have to be 300. But what is wisdom here?

Other than adding an xml code function request to the link for easy export of the total RS content, not copy/paste per 15 results, unaware of anything better. I'm content with BOINCview for listing and filtering on project andrun time hours and averages.

Hi Barney!
Your changing the write-to-disk interval just "when you need" does not work, unfortunately, and you could check it if you had set your cc_config.xml file to have chechpoints logged in your messages.
Applications query the Boinc client about this parameter only once when they start or restart. Then they use this value till the end of the run (completion or shutdown).

A few other comments on your topic.
I usually work with a short queue (0.15 day currently, and crunching HCMD2 only) and thus I have many WUs in PV status too. But on average I seldom have more than one day of work in PV, i.e. 6 days of runtime since I have six WUs active at a time. Last time I made a snapshot of my Result Status pages the PV tasks were totalling 6.5 days of runtime. And when there are more it is when the estimated complexity of jobs is far from reality like when HCMD2 started recently, and in this case having a dedicated feeder for fast returners would be defeated too.

Over the duration of a project the time WUs stay in PV status has no noticeable influence on the duration of the project: we are talking of some more days of delay for each WU versus several months or years for the project. Practically if the average PV time is increased by one or two weeks the total project will finish one or two weeks later, that's all.

I think your suggestion is interesting, particularly for reducing the number of entries in the database at a given time, but I am not sure that the added complexity makes it really practical. Also the techs have other simpler means to reduce the number of open WUs in their database if they need, for example by increasing the average duration of WUs.

But that does not forbid discussing about it, obviously. Jean.