| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 13
|
|
| Author |
|
|
VinceLewis
Cruncher Joined: May 13, 2020 Post Count: 7 Status: Offline |
hi,
I've seen a similar thread around this topic. Basically, I am running BOINC on a 32 core server at home. It's noisy and I turn it off at night. I notice that this project doesn't checkpoint very often, which would be fine if I left my server on all day and night, but I don't. And we both, you and I, end up losing a load of work. I did read that it does checkpoint ever 12.5% It would be really handy if there were an option (ideally through boinccmd, or have it checkpoint at poweroff, but I'll take what I can get) so that I can force a checkpoint before I shutdown. We could all then crunch more data for you and you'd get through the project quicker - up to 12.5% quicker. As a developer, this doesn't sound like a huge task to me. All the mechanism are already there, just a case of joining them up. What are the chances of getting it implemented? |
||
|
|
ca05065
Senior Cruncher Joined: Dec 4, 2007 Post Count: 328 Status: Offline Project Badges:
|
If it was possible to checkpoint more frequently it would have been implemented.
The simplest solution for you is to hibernate your PC instead of shutting down. The contents of memory are written to disk and brought back into memory on startup so you lose no processing time. |
||
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1406 Status: Offline Project Badges:
|
You could create a virtual machine on your host (ubuntu is free) and install BOINC on it.
----------------------------------------For that VM BOINC you may use a venue with only ARP1 selected. When you want to power down the host, suspend your projects in BOINC's VM with the setting "Leave non-GPU tasks in memory while suspended", but keep BOINC running. Close the Virtual Machine with the option: Save the machine state. Thereafter you can shutdown your host. [Edit 1 times, last edit by Crystal Pellet at Nov 27, 2020 10:45:56 AM] |
||
|
|
VinceLewis
Cruncher Joined: May 13, 2020 Post Count: 7 Status: Offline |
Thanks to both of you for your replies. I'll implement a hibernate solution.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Expanding on the 'If it could be...' a price to pay would be for instance every minute a 1GB save to that write count limited SDD. Bad idea. Saves are designed to take place at cycle completion points. Some of these can take place less than a minutes, others take hours (ARP1). Those are the points from which a job package can resume taking the intermediate results without getting a bit wrong and that's detrimental on quorum 2. BOINC is still default set to 'at most' every 60 seconds... dating back to the days of single core. Picture this when you have 16-32-64-128-256 threads concurrent. Think that HD light will burn out pretty fast, the SDD too, so standard I've got it at 3600 seconds.... power is very stable here.
Anyway, a utility called BOINCTasks can automate the suspending of Work units in progress at next checkpoint, precursor being that all 'ready to start' tasks have to be suspended before that. Not sure if it also can initiate a boot... that'd be a true wonder. What I do is set the ARP1 to suspend at next checkpoint and let other short checkpoint jobs fill in for when ready to boot the progress loss is minimal... I just can't be bothered to wait as it only creates more loss of computing time while cores are idling waiting on the last one to auto suspend. If the purpose is to simply give the machine a rest, then hibernation is the process of choice as it stops using power whereas 'sleep' keeps the memory hot, uses juice and will drain that laptop battery eventually. |
||
|
|
Macroman
Advanced Cruncher Joined: Jun 4, 2005 Post Count: 112 Status: Offline Project Badges:
|
More and more often Windows wants to force a reboot to install some update. Hibernation is not an option. To avoid losing time I suspend a task so that new tasks will not be dowloaded and wait for my in progress ARP units to finish. This is not a great solution.
|
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12594 Status: Offline Project Badges:
|
Macroman
In the situation that you describe, I defer the reboot until arp has completed the next check-point. That can be up to 3 hours with a machine that crunches a unit in 24 hours. However, if a check-point has only recently occurred I reboot immediately. Mike |
||
|
|
BobbyB
Veteran Cruncher Canada Joined: Apr 25, 2020 Post Count: 638 Status: Offline Project Badges:
|
I do the same: defer the reboot.
I seem to remember reading about some option which halted a WU when a checkpoint occurs or is that wishful thinking? I suspect the latter. |
||
|
|
PMH_UK
Veteran Cruncher UK Joined: Apr 26, 2007 Post Count: 786 Status: Offline Project Badges:
|
BoincTasks can suspend a task at next checkpoint.
----------------------------------------I sometimes use this to suspend seldom checkpointing tasks but leave other tasks to run so I can re-boot when ready and un-suspend held tasks. Paul.
Paul.
|
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12594 Status: Offline Project Badges:
|
Step 1 is to defer the reboot. Step 2 is to suspend any queuing arp & mip units. Step 3 is to suspend any arp & mip units being crunched as they reach the next checkpoint, leaving short duration units units to mop up the spare threads. Step 4 is to reboot once the last arp & mip has checkpointed. Step 5 is to unsuspend all suspended units on restart.
Please remember that no units will download while any unit is suspended. Mike |
||
|
|
|