Message boards : Number crunching : What to do with tasks that are predicted to run longer than their available deadline?
Author | Message |
---|---|
Tom M Send message Joined: 20 Jun 17 Posts: 87 Credit: 15,166,437 RAC: 39,077 |
Hi, I am a Rosetta newbie but a long time BOINC user (aka: seti@home refugee). Today I found my self with a large # of Rosetta-Mini tasks with 12+ hours to go and a deadline of the middle of the local evening. I have had tasks expire under BOINC and they are aborted/deleted. Since I have other Rosetta tasks that will not expire and therefor won't waste my computers cpu cycles I went ahead and aborted the tasks that would expire before they got done processing. Is the above consistent without how Rosetta does things? Or should I have left them to "grind through" since they would not have aborted? Tom Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel..... |
Grant (SSSF) Send message Joined: 28 Mar 20 Posts: 1681 Credit: 17,854,150 RAC: 20,118 |
Is the above consistent without how Rosetta does things? Or should I have left them to "grind through" since they would not have aborted?Reduce your cache size (ideally no more than a day) & let them run so the Scheduler can work out how much work you can do in 8 hours, and then the Tasks will end up taking 8 hours and you won't get too many. If they do run over the set time (by 4 hours i think it is for 8 hour Tasks) the Watchdog timer will end the Task, and you will still get Credit for the work that was done (as long as it's not an error of course). Grant Darwin NT |
Mod.Sense Volunteer moderator Send message Joined: 22 Aug 06 Posts: 4018 Credit: 0 RAC: 0 |
Sounds like you ran in to the situation I anticipated when I wrote this item, as it says there, feel free to abort some of the excess. Default workunit preferred runtime increases to 16 hours. Shortly thereafter, they put things back to the 8hour normal runtime for the default runtime preference. Rosetta Moderator: Mod.Sense |
Brandon L. Send message Joined: 25 Jul 15 Posts: 2 Credit: 369,181 RAC: 0 |
Hello, sorry to interrupt but I'm having a similar problem. How do we reduce cache size and reduce run times? I'm barley making half my deadlines. |
Mod.Sense Volunteer moderator Send message Joined: 22 Aug 06 Posts: 4018 Credit: 0 RAC: 0 |
Hello, sorry to interrupt but I'm having a similar problem. How do we reduce cache size and reduce run times? I'm barley making half my deadlines. Abort tasks that won't make the deadline and have not yet begun. They changed the default runtime back to 8 hours, so new work should run to the normal runtime preference. You can set the runtime preference on the R@h website in the Rosetta preferences. But the reccommendation is to leave it set to the default runtime. Rosetta Moderator: Mod.Sense |
strongboes Send message Joined: 3 Mar 20 Posts: 27 Credit: 5,394,270 RAC: 0 |
A better way would be to reduce your runtime on the website to 2 hours. run update. restart boinc and any wu over the time will roll back to last completed decoy/checkpoint, upload and report. No need to abort and not get credit and save someone else re running. |
Sid Celery Send message Joined: 11 Feb 08 Posts: 2125 Credit: 41,228,659 RAC: 9,701 |
A better way would be to reduce your runtime on the website to 2 hours. run update. restart boinc and any wu over the time will roll No, this is always the absolute worst choice. All you end up to doing is getting into a permanent routine of downloading and uploading 12 times per day (times the number of cores you have) instead of 3 times, and thrashing the servers, which is a limitation the project has recently been trying to reduce with all the new users arriving. No credit is lost as those tasks haven't begun and there are currently <hundreds of thousands> of new users recently running out of any tasks to run at all (not right at this minute, but frequently recently). They'll be glad to run and complete those tasks before you'd even get round to them. Mod.Sense's suggestion would've sorted the issue once and for all. The default (8hr) runtime is the best compromise of task productivity and server hits. The project will always know this better. It should only be reduced by users if there's a problem that changing the runtime will solve, which is rare as 99% of problems are caused by something else |
Message boards :
Number crunching :
What to do with tasks that are predicted to run longer than their available deadline?
©2024 University of Washington
https://www.bakerlab.org