Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
World Community Grid Forums
Category: Completed Research Forum: GO Fight Against Malaria Thread: Dramatic runtime increase. |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 23
|
Author |
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The essence of the query by KerSamson can be paraphrased as: Why is KerSamson's case getting 8minutes between checkpoints despite the checkpoint setting set to every minute. In case anyone else is getting confused, there is no "checkpoint setting set to every minute". The relevant profile setting is "Write to disk at most every: nn seconds" with a default of 60 seconds (or via BOINC Manager Preferences disk usage setting "Tasks checkpoint to disk at most every nn seconds"); it's designed to prevent over-frequent writes to disk. So if an algorithm ends up writing a checkpoint to disk every 8 minutes, there is no conflict with a setting of "Write to disk at most every 60 seconds".Note from the Checkpoint FAQ: "GO Fight Against Malaria (GFAM). A checkpoint is written to disk if the client settings permit at the end of each job included in the work unit. The time for an included job can last from less than a minute to half an hour depending on speed of device". So the GFAM jobs that triggered KerSamson's query were presumably lasting 8 minutes long. To repeat the point another way: there is no profile or preferences setting that can speed up the occurrence of checkpoints. All you can do is cut out checkpoints that would violate your "Write to disk at most every nn seconds" setting. HTH, |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Guys,
Plz refer to the beta testing forum on checkpoint writing for GFAM/DSFL. The setting in BOINC for "at most" is not being adhered to ATM. Currently, no matter the setting if GFAM/DSFL want to checkpoint with 30 second intervals or 30 minute intervals they'll do it, regardless. When the new version will be released in early 2012, we'll be getting compliance, with a note that we cant tell the sciences to write one. The science apps *ask* the client one time at [re]start of task what frequency is permitted *at most*, if they are allowed to write one to disk. Changing the setting does not take effect until next [re]start. Wishing y'all a good Capo D'Anno and all crunching success for 2012. --//-- |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
So if an algorithm ends up writing a checkpoint to disk every 8 minutes, there is no conflict with a setting of "Write to disk at most every 60 seconds". In case anyone else is getting confused about the essence of KerSamson's query, a "Write to disk at most every: nn seconds" setting goes by a common-man's term "checkpoint setting"; and that a minute is equal to 60 seconds. Thus: if an algorithm ends up writing a checkpoint to disk every 61 seconds, that too is not in conflict with a checkpoint setting of 1 minute, or for that matter, strictly technically speaking, even 100 years. The thing is, it is not so much about the checkpoint mechanism that needs to be explained or the time it takes for that mechanism to do a checkpoint, but rather the deviation of the reality produced by that mechanism -- against the expected outcome from the checkpoint setting. 8-minutes is a large deviation from 1-minute: 8x to be exact. Enough, in my mind, to justify looking into the matter that causes the said deviation.And Sekerob's [Dec 30, 2011 10:06:22 AM] post snip, ... The setting in BOINC for "at most" is not being adhered to ATM. ... does answer the essence of KerSamson's query. P.S. I apologize for taking the topic off-topic. It's just that there are situations where a topic has so many dimensions/areas that are in most cases inextricably intertwined that an off-topic pushes itself in to the topic. Not to offer an excuse but the matter of checkpoints is a matter of relevance to what crunchers do. In any case... Happy New Year 2012 everyone! ; |
||
|
|