Too high CPU core estimation

\n studio-striking\n

Message boards : Number crunching : Too high CPU core estimation
Message board moderation

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
Profile Zydor
Avatar

Send message
Joined: 5 May 11
Posts: 233
Credit: 351,414,150
RAC: 0
Message 682 - Posted: 22 Jun 2011, 15:14:19 UTC - in response to Message 681.  

Hello,
Somethings went wrong here ........ my manager has now put the work units i have into high priority for no reason and is picking whichever it feels like instead of going from top to bottom ( completion date )

how do i get rid of the priority mode so the manager can get back to crunching the work with the lowest completion date ?
the first of these is due to be be crunched and sent by the 25th so no reason for it thinking its running out of time

dont know if this has anything to do with the new 0.05 cpu usage which seems to have happened overnight but the 4 full core usage on the cpu has not changed


No its not the 0.05 useage, the change to that was pretty well instant after changing on the server - it would happen if the queue ran dry and refilled, or the BOINC Manager was stopped and restarted - the latter in particular triggered picking up the 0.05 change for most people.

It will kick into high priority mode whenever it switches to EDF (earliest deadline first). Thelatter happens if the calculation set inside the BOINC Client Client for EDF believes life is getting short. Whilst we humans "know" there is only a few minutes for a four GPU setup to run, and three days to doit - it doesnt. The EDF calculation takes into account a myriad of circumstances stretching from processor speed, through "connect every XXX" setting, to ..... geez the list is as long as your arm.

There was also a bug to do with length of name, downloaded time, downloaded order that didnt help. Other factors include the schedular itself which had a number of issues - dozens - as will always happen in todays fast moving hardware world. The CPU GPU schedular priority mix and how that is now handled has ungone a lot of revision.

BOINC Client Full Changelog 6.10.58 to 6.12.26

If strict EDF is forced as a norm, then there willbe issues with long lead WUs, some of which have dates up to a year or more ahead. Those will likely never get a look in as short run ones always get in first, later when they get a chance, too late because not enough processing time left. Equally FIFO (First in Last out) has similar nightmare if enforced uniquely. Frankly its way way best to let BOINC get on with it based around its main priority of FIFO, and let it kick into EDF due to perceived time issues (even if a little early), and also take into account schedualr issues - its a circular route to the nuthouse otherwise :)

All that is a long way of saying ..... and you probably not going to like this, dont shoot the messanger rofl .... change to 6.12.26 (even latest Alpha 6.12.33 which at the moment is looking ok). Whilst any schedular system will have issues on a beast as complex as BOINC is, the current system aka 6.12.26 and on has had very substantial revision since the last Public Release 6.10.58, and works much better, if not always perfectly logically. There's no silver bullet on this one, its far too complex, whatever the vision looks like on the surface.

Regards
Zy
ID: 682 · Rating: 0 · rate: Rate + / Rate - Report as offensive
Profile Zydor
Avatar

Send message
Joined: 5 May 11
Posts: 233
Credit: 351,414,150
RAC: 0
Message 683 - Posted: 22 Jun 2011, 17:08:07 UTC

A thought that may help the dilema for you - try reducing the queue from its current three days, to two days. That will reduce work to be completed, and probably bring down the EDF times. I've run the queue here up to 1.5 days and EDF didnt kick in. One slight problem is I run 6.12.33 which runs it differently to 6.10.58, but it may well resolve it as a workaround for you.

Regards
Zy
ID: 683 · Rating: 0 · rate: Rate + / Rate - Report as offensive
scottishwebcamslive.com
Avatar

Send message
Joined: 2 May 11
Posts: 21
Credit: 173,527,396
RAC: 0
Message 684 - Posted: 22 Jun 2011, 19:06:44 UTC
Last modified: 22 Jun 2011, 19:11:05 UTC

Hi,

I changed the pref's to not download any more work and after most of the day missing out every 2nd or third work unit it got to the bottom of the list
then started at the top again and working on the work units in order
plus the priority mode has gone too
so i let it download its quota again and everything seems to be fine

i think you may have a point about what you say i just got round it in another way
if it happens again i may lower the cashe to lessen the chances of it happening again

i also spotted that a work unit had jammed for 46,000 seconds ( 12 hours ) which knocked off around 300,000 credits yesterday which was not funny
lets hope that doesnt happen again as it severely dented my RAC's rise :(

best regards
Ian
----> Please Join team Scotland HERE
ID: 684 · Rating: 0 · rate: Rate + / Rate - Report as offensive
Previous · 1 · 2

Message boards : Number crunching : Too high CPU core estimation


 
Copyright © 2011-2024 Moo! Wrapper Project