Message boards :
Number crunching :
Short deadlines BOINC seems capable of this
Message board moderation
Author | Message |
---|---|
Belial Send message Joined: 22 Jan 02 Posts: 47 Credit: 63,100 RAC: 0 |
Running predictor I've gotten wu's with deadlines of 1 or 2 days. Amazing to see wu's with such a short deadline get crunched first and then as soon as they are finished they get sent back to the server and dissapear off the crunched list. Most of their wu's have longer deadlines but I guess they are up trying to keep a schedule with the shorter deadlined ones. Running seti deadlines don't seem very important except maybe for how long people wait to cash in the credits. Seti doesn't seem to be very deadline oriented but other projects do and it appears BOINC is capable of this. BOINC can run a tight ship if need be. I hope future revisions of BOINC capitalize on this and make it even better. |
Andrew Hingston Send message Joined: 3 Apr 99 Posts: 2 Credit: 0 RAC: 0 |
This raises a number of interesting issues. It is true that WUs with the shortest deadline are taken from the cache first. Provided that project sharing is working properly, though, this should not give any advantage to the project setting the short deadlines, as the client should then spend the appropriate time on the others before going back for more. But there are problems with project scheduling, as we know, so there is a risk that projects might be tempted to set artificially short ones in order to grab an advantage. Against that, there are several counter-arguments. 1. Not all projects can set short deadlines, as some WUs take longer than others. 2. Short deadlines are unfair on those with dial-up and slower machines. Discourage them, and you lose participants. 3. The shorter the deadlines, the more that will be missed, and the more WUs that have to be sent out again. Server bandwidth is one of the more expensive aspects of DC. My own view is that frustrating as it may be for those awaiting credits, generous deadlines are best all round. |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
The scheduler uses active_frac & project-share then handing out work, so if a project needs example 12 hours to crunch a wu and set the deadline at 13 hours very many machines will not even download the wu since they're "too slow". |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
> The scheduler uses active_frac & project-share then handing out work, so > if a project needs example 12 hours to crunch a wu and set the deadline at 13 > hours very many machines will not even download the wu since they're "too > slow". > Should read active_frac and CPU speed to determine whether a computer can complete the WU by the deadline. Project share is used to determine which project to contact for work. |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
> > The scheduler uses active_frac & project-share then handing out work, > so > > if a project needs example 12 hours to crunch a wu and set the deadline > at 13 > > hours very many machines will not even download the wu since they're > "too > > slow". > > > Should read active_frac and CPU speed to determine whether a computer can > complete the WU by the deadline. > > Project share is used to determine which project to contact for work. Uhm, I'm no C-programmer, but even I understand atleast the 2 comments in this code-block: (sched_send.c, line 142) // estimate the amount of real time for this WU based on active_frac // and resource_share_fraction inline double estimate_wallclock_duration( WORKUNIT& wu, HOST& host, double resource_share_fraction ) { return estimate_cpu_duration(wu, host) / max(HOST_ACTIVE_FRAC_MIN, host,active_frac * resource_share_fraction) ; } // return false if the WU can't be executed on the host // because of insufficient memory, CPU speed, or resource share // The only note has on this is that this change was made resently, and unsure if the current seti@home-servers is using this now. So maybe we're both right. ;) |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.