Short deadlines BOINC seems capable of this

Message boards : Number crunching : Short deadlines BOINC seems capable of this
Message board moderation

To post messages, you must log in.

AuthorMessage
Belial

Send message
Joined: 22 Jan 02
Posts: 47
Credit: 63,100
RAC: 0
United States
Message 7323 - Posted: 13 Jul 2004, 8:09:50 UTC

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.
ID: 7323 · Report as offensive
Andrew Hingston

Send message
Joined: 3 Apr 99
Posts: 2
Credit: 0
RAC: 0
United Kingdom
Message 7343 - Posted: 13 Jul 2004, 9:41:24 UTC
Last modified: 13 Jul 2004, 9:42:30 UTC

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.
ID: 7343 · Report as offensive
Ingleside
Volunteer developer

Send message
Joined: 4 Feb 03
Posts: 1546
Credit: 15,832,022
RAC: 13
Norway
Message 7352 - Posted: 13 Jul 2004, 10:48:10 UTC

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".
ID: 7352 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 7722 - Posted: 14 Jul 2004, 14:17:12 UTC - in response to Message 7352.  

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

ID: 7722 · Report as offensive
Ingleside
Volunteer developer

Send message
Joined: 4 Feb 03
Posts: 1546
Credit: 15,832,022
RAC: 13
Norway
Message 7915 - Posted: 14 Jul 2004, 18:37:46 UTC - in response to Message 7722.  

> > 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. ;)
ID: 7915 · Report as offensive

Message boards : Number crunching : Short deadlines BOINC seems capable of this


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