Desire new option for WU: PRIORITY in addition to SUSPEND and ABORT

Message boards : Questions and problems : Desire new option for WU: PRIORITY in addition to SUSPEND and ABORT
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile marmot
Avatar

Send message
Joined: 16 Sep 13
Posts: 82
United States
Message 60746 - Posted: 8 Mar 2015, 12:23:57 UTC
Last modified: 8 Mar 2015, 12:26:12 UTC

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?
ID: 60746 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15480
Netherlands
Message 60747 - Posted: 8 Mar 2015, 12:37:36 UTC - in response to Message 60746.  

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.
ID: 60747 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5080
United Kingdom
Message 60748 - Posted: 8 Mar 2015, 12:53:11 UTC - in response to Message 60747.  

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.
ID: 60748 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15480
Netherlands
Message 60754 - Posted: 8 Mar 2015, 14:11:27 UTC - in response to Message 60748.  

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.
ID: 60754 · Report as offensive
Profile marmot
Avatar

Send message
Joined: 16 Sep 13
Posts: 82
United States
Message 60875 - Posted: 12 Mar 2015, 6:46:36 UTC - in response to Message 60754.  
Last modified: 12 Mar 2015, 7:13:36 UTC

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.


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.
ID: 60875 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15480
Netherlands
Message 60876 - Posted: 12 Mar 2015, 8:51:15 UTC - in response to Message 60875.  
Last modified: 12 Mar 2015, 9:33:26 UTC

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.
ID: 60876 · Report as offensive
Profile marmot
Avatar

Send message
Joined: 16 Sep 13
Posts: 82
United States
Message 61101 - Posted: 20 Mar 2015, 13:50:04 UTC - in response to Message 60876.  
Last modified: 20 Mar 2015, 13:59:47 UTC

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?

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?

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.

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.


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...


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.


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.


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.
ID: 61101 · Report as offensive

Message boards : Questions and problems : Desire new option for WU: PRIORITY in addition to SUSPEND and ABORT

Copyright © 2024 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.