Message boards : Questions and problems : Desire new option for WU: PRIORITY in addition to SUSPEND and ABORT
Message board moderation
Author | Message |
---|---|
![]() ![]() Send message Joined: 16 Sep 13 Posts: 82 ![]() |
This machine is running a 17 or Bust PrimeGrid WU which is over 530 hours in with 80 estimated hours left. The only reason this WU is going to finish on time is I switched the machine out of HyperThreading mode giving the WU 100% more CPU time. The estimation and prioritization code kept delaying the WU over the last 3 months leaving it only hours of buffer when the estimation to completion was anywhere from 450 to 1200 hours the first week and even with an estimate of 1100 hours it kept delaying calculations on the WU because the deadline was 3 months away. BOINC would put absolutely no work into that WU for a week. It's been tedious suspending various other WU's and ending up with other projects downloading new work while I suspend some WU to let the PrimeGrid packet get back to work. Ended up throwing a lot of WU away before they started. All my headaches protecting the hundreds of hours of time already spent on this WU would have been gone if I could have just clicked a button called 'Priority' or 'Fast Track' so that this work unit was put straight into high proiority calculation above all other work. Can we PLEASE get that feature? |
![]() Send message Joined: 29 Aug 05 Posts: 15634 ![]() |
Really, when a task takes that much longer than its estimated fpops resource value says they should take, then you should ask the PROJECT to increase these values. A priority button is not needed when projects adjust their flops value so that BOINC can more accurately estimate how long this work takes. |
Send message Joined: 5 Oct 06 Posts: 5149 ![]() |
Unfortunately, project administrators are only human. <rsc_fpops_est> can go wrong for a number of reasons, but the two commonest ones are 1) An administrator in a hurry - especially when testing new applications/tasks - can forget to make the necessary adjustment. 2) Some tasks are non-deterministic in nature. I'm approaching the finishing line after 324 hours, on a task which was (reasonably on the basis of the average for the app) initially estimated at 5 hours. It also had a deadline of 28 February, but hey - who's in a hurry? But my resource shares are such that BOINC showed no tendency to switch away from the task once started. I think if I was trying to nurse a long task to completion, I'd use a combination of Resource Share and NNT for other projects to ensure that BOINC gave that project sufficient priority. |
![]() Send message Joined: 29 Aug 05 Posts: 15634 ![]() |
Unfortunately, project administrators are only human. Perhaps so, but you'd expect that especially on a project as old as Primegrid that there are admins there with experience in the matter. Still, it is something for the project to adjust, and so it should be reported there. |
![]() ![]() Send message Joined: 16 Sep 13 Posts: 82 ![]() |
Unfortunately, project administrators are only human. Even in an old project the admins are adjusting the deadline values and there was a notice to this effect from PrimeGrid about debate on 3 or 4 day deadline for a specific app. I did report the problem to their forum and their solution was to go into my BIOS and turn off Hyperthreading, (which I eventually, reluctantly did as it caused me many issues with responsiveness on this machine for regular use) and that I should change the estimation calculation in the configuration files. I could have solved the problem by detaching from all but two projects and not watching videos but that's unreasonable to ask users volunteering their resources. This is my daily use machine which I'm typing my response from now. So, here I am at 27 hours estimated time on the day before the deadline and even adjusting the resource share to 750 didn't help the problem this week as BOINC still refused to run the WU 24/7 and pushed it up against the deadline leaving only about 14 hour buffer on a 620 hour WU when thunder storms are possible this week and 6 to 18 hour power outages are a small probability. I really want this feature for when another situation as this occurs. What would be the problem with giving users such a control mechanism? We are the ones who control when the machines are running and maybe needed to be shut down and how much other usage the machine is getting from a human. We can easily see when the client's deadline prediction can be wrong. |
![]() Send message Joined: 29 Aug 05 Posts: 15634 ![]() |
What would be the problem with giving users such a control mechanism? It's micromanagement, goes against letting BOINC its scheduler be doing the scheduling and running of things. The user thinks he knows best. He'll then be using that option for everything from that point forward. And why? It's by the way not the client's deadline prediction, it's the task's and an estimate at that. As such, BOINC is only following what the project throws out. In the mean time, I found the thread at Primegrid, in it you've been told several times that recently a second algorithm was added to BOINC which works much better and that they've enabled this on the server side, but it won't be active on your computer until either you reset or re-attach to PrimeGrid or they release new versions of the apps. So you knowingly ran that task with old values. You can also let one or more tasks run over time, without interfering! BOINC will learn about it and next schedule such tasks earlier. I bet that's what the project admins are hoping for, as it may be easier to do than to adjust the resource estimate more correctly for all machines out there. Having done the resource flops calculations, it takes at least a thousand tasks done on one trustworthy machine to get a more accurate estimate. Want even more accurate? Several thousands more. Oh, and that's generally done before you release such tasks to the public. But since projects don't have that time, money and patience... Now then, if you still so much require such a function, there is nothing standing in your way to add it and compile your own version of BOINC for it. Source code here, outdated compiling instructions there. |
![]() ![]() Send message Joined: 16 Sep 13 Posts: 82 ![]() |
What would be the problem with giving users such a control mechanism? And so you are of the opinion that the users do not know what's best for their machine and when they need to shut the machines down for maintenance or when possible outages are on the horizon?
Incorrect. I added the serverside calculation into the configuration files and the estimate came into line. Since it was the same estimation calculation and there was already ~9% into the calculation, I went ahead with it. I also turned off Hyperthreading to allow the WU to gain some ground. (Which had the WU days ahead of schedule but the scheduling code wasted away till the WU was late. Mind you I was trying to get this WU done before thunderstorm season and expected power outages. It stormed all day on the 13th but luckily no outages.) You didn't complete reading into the next thread where we finished the discussion of how to resolve my issue: <app> <name>llrSOB</name> <max_concurrent>4</max_concurrent> <fraction_done_exact/> </app> It's understandable since you are quite busy.
SoB is a 450 to 700 hour task. The gathering of thousands of data points on a single machine for that estimate would take 51 years.
Thankyou. I will also check into the other version out there. BTW, user SekeRob2 offered a simple solution for micro managing that kind of WU. 'switch applications every nn minutes' to some ludicrous long time, like 50000 minutes Damn, I wish we had crossed paths 2 months ago. |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.