| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: Work unit priority |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 5
|
|
| Author |
|
|
Low_Gap
Cruncher Joined: Aug 17, 2008 Post Count: 5 Status: Offline Project Badges: 
|
On my last upgrade of the BOINC client, I jumped from Windows version 6.6.38 to Windows version 6.10.18. I tend to wait a bit before upgrading to make sure there are no significant operational issues with the new client since some of the version changes seem to be a bit dynamic.
----------------------------------------After the upgrade I noticed what seems to be a behavior change in how the client prioritizes the crunching of work units. Prior to the upgrade, the work units appeared to be getting crunched in order of their due dates (or deadlines). Since the upgrade, the work units appear to be getting crunched on a "first in, first out" basis, irrespective of the due date. This becomes an issue when you receive a resent work unit with the shorter deadline. This is an issue if you have your work buffer set for, say, 7 days, you then run the risk on a "first in, first out" basis of the client not completing the resent work unit before the deadline expires. Of course, the easy fix for this is to set the work buffer at a lower value. Mine is set at 1 day, so the resent work units are being completed 2 to 3 days prior to the deadline. Looking back at the version history on the main BOINC site, it appeared that in the upgrade to Windows version 6.10.17 at the end of October that the developers made what was termed "improvements to the CPU/GPU scheduler". It doesn't say just what those improvements were. I am thinking that this is when the change was made. Has anyone else noticed this, or am I simply misinterpreting what I am seeing?  [Edit 1 times, last edit by Low_Gap at Jan 17, 2010 5:30:06 PM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Very basic and direct: Old 6.2 and new (not yet by WCG adopted) 6.10 client work on a FIFO basis. Have and pretty much always did at project level (WCG for sake of simplicity as a whole here called a project). The EDF (old Earliest Deadline First) only kicks in when there's scheduling panic... speak any one job under threat to overrun the deadline.
----------------------------------------About 6.6: Was never endorsed at WCG and had a very short lifespan at Berkeley too. It was build to implement GPU crunching in essence, doing little additional for the CPU side of crunching management. edit: amplification on first paragraph.
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 2 times, last edit by Sekerob at Jan 17, 2010 5:55:13 PM] |
||
|
|
Low_Gap
Cruncher Joined: Aug 17, 2008 Post Count: 5 Status: Offline Project Badges:
|
Thanks. That makes sense. The only time I run into scheduling panic is when I am letting WCG work units run out while starting the extraordinarily brief SIMAP runs and I am not being attentive.
---------------------------------------- |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
SIMAP is weird. It likes to push itself to the front of the queue and if you then buffer too much, cause WCG jobs to get shoved to the back of the queue, causing these deadline issues. I've got a small expectation some improvements to scheduling will appear for this in the next client.
----------------------------------------Remedy: Reduce queue size, or live with it.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges: 
|
Something else which has changed some months ago is that WCG repair jobs have a deadline of 4 days now (40 % of the normal deadline precisely), and with this deadline jobs are no longer triggering the high priority mode immediately when received. When these short deadlines were shorter they used to start immediately.
----------------------------------------Note that a client with a 7-day work buffer should not have problems with the deadline of repair WUs, simply because it is unlikely that it ever receives one. Should it receive one, when it gets closer to this deadline BOINC will trigger the high priority mode early enough to get it finished in time. Although it can look weird for a member computing only for WCG, the value of "Switch applications every xxxx minutes" is influencing how early the high priority mode will be triggered. Cheers. Jean. |
||
|
|
|