Message boards :
Number crunching :
Too high CPU core estimation
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
![]() ![]() Send message Joined: 5 May 11 Posts: 233 Credit: 351,414,150 RAC: 0 |
Hello, 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 |
![]() ![]() Send message Joined: 5 May 11 Posts: 233 Credit: 351,414,150 RAC: 0 |
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 |
![]() Send message Joined: 2 May 11 Posts: 21 Credit: 173,527,396 RAC: 0 |
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 ![]() |