Message boards : Number crunching : 5.69/5.80 Status: Running High Priority
Author | Message |
---|---|
![]() ![]() Send message Joined: 30 May 06 Posts: 5692 Credit: 5,861,865 RAC: 230 |
So now some of us are running a mix of 5.69 and 5.80 work. Why do both say they are running with high priority? Is there some other status other than high priority? Does this make RAH jobs higher than say a SETI job? Also there was some talk that BOINC manager would not download new work if there were X number of WU's that were of 'high priority' still in queue. Is this true? |
Speedy![]() Send message Joined: 25 Sep 05 Posts: 163 Credit: 811,560 RAC: 44 |
So now some of us are running a mix of 5.69 and 5.80 work. Why do both say they are running with high priority? Is there some other status other than high priority? Does this make RAH jobs higher than say a SETI job? From the way I understand it if a job is running with high priority, untill the job has finished no other jobs will run or be downloaded, the answer to your question is the RAH jobs have higher priority to the Seti jobs at the moment. I hope this helps Have a crunching good day!! |
Ingleside Send message Joined: 25 Sep 05 Posts: 107 Credit: 1,522,678 RAC: 399 |
"High Priority" isn't the best name for it, and in case anyone thinks it, it has nothing to do with some wu's being more "important" than others and so on. If manager shows "High Priority" on a Task, it's fairly similar meaning to the old "Earliest Deadline First", except it's not neccessary it's crunched in deadline-order. Also, on multi-cpu, it's possible only a single Task is marked "High Priority". Meaning, a "High Priority"-task is, for some reason in deadline-trouble, and for this reason has been put 1st. in line to be crunched. There are multiple reasons for being in deadline-trouble, some of them are: 1; Obvious one, if a wu has 36 hours left to crunch but only 37 hours until deadline. 2; If you've got 36 wu's each taking 1 hour to crunch, and all wu's should be returned by 37 hours. 3; If your preference specifies to "Connect every 38 hours", and only 37 hours until deadline, BOINC can't be sure you'll really connect earlier than 38 hours. 4; Not so obvious one for many: With v5.8.xx: If "Connect every N days" > 0.473684 * "deadline" - 0.493421 With v5.10.xx: If "Connect every N days" > 0.473684 * "deadline" - 0.019737 Meaning, with Rosetta@home's 10-days deadline, by running v5.10.xx, if your "Connect every N days" > 4.71 days, Rosetta@home will always be in deadline-trouble With v5.8.xx, the cutoff is 4.24 days. For other deadlines, see Max cache size Since adding even more work to a project there already one Task is in deadline-trouble would risk being in even larger deadline-trouble afterwards. For this reason, if a single Task in a project is "High Priority", this project won't ask for more work until not in deadline-trouble any longer. This normally means idle cpu, or completely out of work for project... If multi-project, one project being blocked due to deadline-trouble doesn't neccessary means other project can't continue download work as normal. Meaning, if "Connect every N days" > 4.71 days, Rosetta@home will only ask for more work if idle cpu or no more Rosetta@home-work on client. As for the new "Cache an additional N days of work", I'm not sure if this will also force Rosetta@home into "High Priority"-mode if "connect" + "additional" > 4.71 days, but it would atleast be easy for you to test this by decreasing "additional days" until not "High Priority" any longer... "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
Mod.Sense Volunteer moderator Send message Joined: 22 Aug 06 Posts: 4018 Credit: 0 RAC: 0 |
So, just to reinforce the point, the "running at high priority" message had nothing to do with Rosetta version. And only newer BOINC versions use that terminology. "deadline trouble" can be achieved in numerous ways. BOINC is keeping a record of how many hours out of the day your machine tends to be on, and factors that in with the resource share to the project and the deadline on the task and it tries to assure you get work done on time. If this means running Rosetta for a period of time to meet a deadline, no worries, BOINC tracks that too. It will then tend to avoid Rosetta tasks in favor of your other projects until the desired resource share is reestablished. Rosetta Moderator: Mod.Sense |
![]() ![]() Send message Joined: 30 May 06 Posts: 5692 Credit: 5,861,865 RAC: 230 |
connection time seems to be a factor as well changed from 1 or 2 days connect to .5 days and the high priority disapeared |
Mod.Sense Volunteer moderator Send message Joined: 22 Aug 06 Posts: 4018 Credit: 0 RAC: 0 |
connection time seems to be a factor as well Yes, good point. If you think about that it makes sense. If I'm told to only connect every 5 days (a more extreme example will help to picture it), and I'm looking at a task that will take an estimated 24hrs to complete, and perhaps my network hours are limited, or my best guess is that the machine will be on for 75% of the time... when do you estimate the task will be completed? ...AND REPORTED. And further if you add to that picture another project, and Rosetta has a 66% resource share. You may find yourself more or less constantly in "deadline trouble". Any of the factors may be the most constraining, network access, your share of CPU time, your allowed use of memory... etc. "Running at high priority" is just BOINC's way of adjusting things to help assure that the work is completed and reported before the deadlines. And as a task runs it may go in and out of "high priority". This could be because of changing the network access parameters as you pointed out, or it perhaps the estimated completion time has adjusted, or the machine has been left on more then expected. Or another project has been added to the machine or resource shares have been changed. BOINC scheduling is quite involved. Rosetta Moderator: Mod.Sense |
Message boards :
Number crunching :
5.69/5.80 Status: Running High Priority
©2025 University of Washington
https://www.bakerlab.org