client_state.xml file(s)
18 Nov 2005 23:49:40 UTC
Topic 190182
(moderation:
I just noticed that boinc is constantly updating the 3 files client_state.xml, client_state_prev.xml and client_state_next.xml. How can I control how often these updates are performed? I am running boinc manager 5.25 if that makes any difference.
client_state.xml file(s)
)
Why would you want to change the internal workings of the BOINC client?
Never mind It seems to be
)
Never mind
It seems to be controled by general prefernces value for "Write to disk at most every". For some reason this did not appear to work initially but eventually it took hold.
Pirate:
It just seems wasteful to me.
RE: Pirate: It just seems
)
I hope you didn't put it to a too high a number, like a month orso...
For when a next time your system goes haywire, you won't have an up to date backup file (prev file) of your client state file.
Naw, just 10 minutes.
)
Naw, just 10 minutes.
RE: Naw, just 10
)
One warning on setting this value "higher", even just to 10 minutes... whenever a result is "switched out" and removed from memory, for any reason, then when that result is restarted, it will restart at the last 'checkpoint'. The setting is a "no more often than", which means if the app attempts to checkpoint every 9.99 minutes on your machine, succeeds, fails because you said 10, then just before it tries again, you quit BOINC... you can lose up to 20 minutes of crunching on that result.
If apps are left in memory (another preference setting) then they won't lose time every time BOINC switches to another project, but if they are removed from memory, they can. Rosetta had a problem on very slow machines because they weren't (under an older version of the app) checkpointing within the one HOUR default switch time, and the results would get 'stuck' and never progress unless they were left in memory.
If you leave apps in memory and run BOINC 24/7, then you can safely go to 10 minutes without losing any crunching time.
Bill Thanks for the heads up,
)
Bill
Thanks for the heads up, I do in fact keep the app in memory (and run 24/7 when my DSL connection permits).
RE: If apps are left in
)
But usually, a checkpoint is written when switching without keeping the application in memory? It is regarded an error if a project does not do this, isn't it? I'm asking because I've set the write-to-disk interval to 15 minutes with a switch time of 1 hour and removing the application from memory.
Check the files Fstats.Ha and
)
Check the files Fstats.Ha and Fstats.Ha.ckp in the folder ...\\BOINC\\slots\\0\\ (or whichever subfolder of slots they are in). Those two files are updated when checkpoints are written. See if it's happening every 15 mins for you and then again at project switch time.
Cheers,
Gary.
RE: But usually, a
)
One would hope... but some (most?) simply don't. Likewise I would think that being told to quit, as in when BOINC is shut down, would checkpoint. But they don't appear to. I haven't tested it on every project, but I know at least two do not. Don't know about Einstein.
RE: RE: But usually, a
)
Most applications have limited locations where they can checkpoint, so checkpointing at an arbitrary time is not an option.
If an application checkpoints every 8 minutes on your machine, and you have write to disk at most every 10, and then 15 minutes after the last checkpoint you shutdown, or the result is removed from memory, then you will lose 15 minutes of work.
With the above numbers, the project will checkpoint every 16 minutes. After 8 minutes, it asks for a checkpoint - and BOINC refuses. 8 minutes later, it asks again, and BOINC says OK, so a checkpoint is written, and the clock starts for 10 minutes again.
Known exceptions to the above. CPDN checkpoints at fixed places in the result (every 144 time steps, I believe), and does NOT ask BOINC for permission. S@H can checkpoint every few seconds (the reason for the setting in the first place). There may be more exceptions.
BOINC WIKI