Message boards :
Questions and problems :
What's wrong with the way deadlines work using BOINC?
Message board moderation
Author | Message |
---|---|
Send message Joined: 15 Jun 18 Posts: 12 |
Hi, This is an extract from a message broads by a moderator, not BOINC. Can someone from BOINC validate this, please? What's wrong with the way deadlines work Thanks |
Send message Joined: 15 Jun 18 Posts: 12 |
My questions are, ... a) Is it possible for a project under BOINC to send a WU that requires far more time to complete the computation (Ex. 80 days) on a given host and the deadline is far less (Ex. 20 days) while the host CAN ONLY complete the computation beyond the deadline (the 20 days)? b) Isn't one of the attributes of a WU is to estimate the average number of floating-point operations required to complete the computation and also estimate how long the computation will take on a given host.(the rsc_fpops_est)? If so, ... c) Then when a project under BOINC is found to do so, doesn't this constitute an abuse of participant hosts in accordance to CREATING BOINC PROJECTS? Intentional abuse of participant hosts by projects Thanks, O&O |
Send message Joined: 5 Oct 06 Posts: 5082 |
It is certainly possible for the project administrators, scientists, or researchers - the people, not the abstract project - to make a mistake and create tasks with a longer runtime than the assigned deadline (we were talking to one of them just the other day). If your client receives such a task, it will do its best to complete the work as quickly is possible, running that task in 'Earliest Deadline First' mode and postponing other jobs. The client will automatically abort a task which has been cached, and work hasn't even started on it by the time the deadline is reached. If work has already started on it, but is unfinished by the time the deadline is reached, a warning will be printed in the Event Log at startup (these scenarios typically apply if the user switches the machine off and takes a holiday). I thought that project servers (schedulers) wouldn't send tasks if it was 'infeasible' (the word used) for the client to finish it before the deadline. But different projects have schedulers from different revisions, and I don't know the age of the Primegrid scheduler. |
Send message Joined: 15 Jun 18 Posts: 12 |
It is certainly possible for the project administrators, scientists, or researchers - the people, not the abstract project - to make a mistake and create tasks with a longer runtime than the assigned deadline (we were talking to one of them just the other day). Thank you. To many "mistakes" which I don't have the time or inclination to prove, ... resulting on frequent waste of CPU resources. Last Question please, .... What is really then the use of "Store At Least x days of work" and "Store up to an additional y days of work"? Mine was x=0.26 days and y=0.5 days ,... never and ever more. Regards, O&O |
Send message Joined: 5 Oct 06 Posts: 5082 |
In the early days of the internet, when CPUs were slow and GPUs didn't exist, 10 days wasn't much work to cache, and people working away from home or on the road might be away from communications for days at a time. Even now, some trades - submarine crew come to mind - may be unable to make personal use of the internet for months. |
Send message Joined: 6 Jul 18 Posts: 49 |
To many "mistakes" which I don't have the time or inclination to prove, ... resulting on frequent waste of CPU resources. #MeToo.BOINC What is really then the use of "Store At Least x days of work" and "Store up to an additional y days of work"? It's a fudge factor. Use it to your benefit or don't. Nobody cares if you do; nobody cares if you don't. Mine was x=0.26 days and y=0.5 days ,... never and ever more. Nobody cares what yours was set to. If your settings aren't working out for you then change them. Or don't change them, whatever. |
Send message Joined: 5 Mar 08 Posts: 272 |
The “store at least” in current clients is the cache low-water mark. The “store up to” becomes the high-water mark. So in your example you have 0.5 low-water and 0.76 as high-water days of work the client tries to keep cached. Current server code stores estimates by app version after a machine has done at least 11 task for each app version. The older method was to store a single DCF (duration correction factor) value on the client but it gets confused with different app versions so estimates vary wildly. Which is used depends on the server software and a lot of projects are still running older versions. I run multiple projects, but only one active at a time. I have a small cache setting and I toggle which one by setting no new tasks on the project tab in the manager. Some projects play nice together and others not. The ones that play nice usually have similar run times. MarkJ |
Send message Joined: 7 Sep 05 Posts: 130 |
... you have 0.5 low-water and 0.76 as high-water days of work the client tries to keep cached. That's actually a 0.26 low-water. It's the 'extra days' that is 0.5. The other thing to point out is that the cached work isn't always 0.76. My understanding is that when the low mark is reached, the client 'fills up' to the high and doesn't keep topping up but allows the cache to drain until the low is again reached. You will have a work supply that oscillates between 0.26 and 0.76 (in theory). If you were using the cache as a protection against temporary failures in work supply, you'd probably be better off putting the full amount of 'protection' into the first setting only. Cheers, Gary. |
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.