| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 14
|
|
| Author |
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
I don't want to see you change the points per hour and base that on WU length. Where have you read that in Kevin's post? |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
astrolab,
We will not be entering into these changes lightly. I have talked with David Anderson at length about what it will take to make it work correctly as well as we are working with Dr. Michela Taufer on a simulator of BOINC (server side) to model how this will operate and test different implementations. There is no intent to change the points granted per cpu time. This is about allowing us to load differently sized workunits on the grid so that people who have powerful machines that are on all the time get longer running workunits so that they send/receive fewer workunits and so that people with machines that aren't on very much can still contribute effectively. A quick overview of what may be the design looks at the estimated duration of the workunits that are currently in the schedulers shared memory and segments them into groups (exact number of groups still to be determined) of longer, average and shorter. The scheduler would also have statistics on the distribution of the effective computing power of the volunteers machine (power of the machine * % time running BOINC * % of the time running WCG projects) and also categorize a machine requesting work as faster, average, slower. And then assign work to the computer for a workunit that matches its rating. The user selection option would of course influence that (for example a user of 'faster' machine who wanted to shorter workunits would then be assigned workunits from the 'average' class instead of from the 'longer' class). It would be up to us to create workunits that have a broader range of durations then the 3 classes. Thus if a bunch of a 'slower' machines request workunits, the definition of what longer/average/shorter workunits are would shift. All though this means that the next set of 'slower' computers requesting work would be getting longer workunits than the previous set of 'slower' computers, they would not be getting the 'longer' workunits and overall computers should be getting more appropriately sized workunits. There are certainly some potential pitfalls here and simulation is very important to make sure that we minimize the impact of these. However, having this ability will really help in many regards - in particular making good use of the less powerful (or simply not on very often) computers. I should emphasize though that there is a lot of work to do between here and there so we will not be releasing something like this in the near future. thanks, Kevin |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks you for insight. If it helps the output of valid results, then the work will be well worth the effort.
|
||
|
|
Papa3
Senior Cruncher Joined: Apr 23, 2006 Post Count: 360 Status: Offline Project Badges:
|
A quick overview of what may be the design looks at the estimated duration of the workunits that are currently in the schedulers shared memory and segments them into groups (exact number of groups still to be determined) of longer, average and shorter. The scheduler would also have statistics on the distribution of the effective computing power of the volunteers machine (power of the machine * % time running BOINC * % of the time running WCG projects) and also categorize a machine requesting work as faster, average, slower. And then assign work to the computer for a workunit that matches its rating. The user selection option would of course influence that (for example a user of 'faster' machine who wanted to shorter workunits would then be assigned workunits from the 'average' class instead of from the 'longer' class). [...] I should emphasize though that there is a lot of work to do between here and there so we will not be releasing something like this in the near future. When it comes, I will say "Hooray!!!" as I gleefully request the LONG work units on my 24/7 systems!!! With FaaH per-work-unit network overhead a constant regardless of job length, this will cut BOINC's network usage by a large percentage, with no reduction in work completed, thus greatly reducing BOINC's cost to users. Yay!!! ![]() |
||
|
|
|