| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Discovering Dengue Drugs - Together
Thread: Points attribution for crunching |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 31
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
And?
Fast computers don't get more points. They get exactly the same amount of credit for the same amount of work. There was a discussion of this in what Sekerob likes to call "the back room" recently. The credit system has never been more fair. The techs dissected a few claims of unfair credits, and found that the claims didn't hold up, so this is more than an unsubstantiated opinion. So, if you think you are getting short changed - you aren't. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Hi RedManace,
----------------------------------------Stand by as I had a discussion with the credit guru just hours before in 'my' BR that Didactylos has likely not seen and related to code gone missing in the conversion from server version 56x to 601. ttyl [Added: Things should be recalibrate in the coming days, but more data collection is needed to ascertain if things continue to work across the board correctly or additional extraneous conditions force for more traps to be inserted into the rule book. So please be patient whilst the code experts scratch their heads]
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 1 times, last edit by Sekerob at Mar 18, 2008 10:06:14 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Sek,
Do you have an idea when this will be released? I too have some older P4's that are forever cruching with the new DDDT WU's. Thanks! oh, in future WCG will be able to mix and match devices and send them the light or heavy stuff as appropriate to further optimize performance, for the projects and for the members. Just imagine P4 pitted against P4.... that would take out all the "my fast machine is being pulled down by the slow".... if that becomes reality, this topic will go much more silent (in my dreams of course). now really --//-- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Mark Nicholson,
Not soon. The server would need a lot of coding to handle the different sizes of work units appropriately. Don't expect it this year. Lawrence |
||
|
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1684 Status: Offline Project Badges: 
|
Hi everybody,
----------------------------------------I observed also surprising attribution of credits for one of my system (the best one). The reason for my surprise is less regarding the number of granted credits than the fact that the attribution rule seems to be "curious". By WUs which are only replicated twice, the granted credits reflects mainly the average between the both claimed credits if the difference between the both claims is small (around <15%). If the difference is much bigger, the granted credits is like the smallest claim. I have no idea if my system is really claiming regularly too much or if the mechanism for attributing credits has some "singularities" ! ...  However, I noticed this recurrent behavior only with the system running XP64. Already in the past, I can remember that some members mentioned from time to time strange behavior with 64 bits operated systems. Only an accurate and consistent investigation can prove if 64bits systems are handled less fair than 32bits. Happy crunching, |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: 
|
We have been doing some investigation. Since the upgrade to the new server code, there have been an increase in complaints about the credit awarded. We dug into this and we found that there was a problem with the update and so we fixed that last Thursday. However, we have also looked deeper into some of the reported problems and found that there was a more fundamental problem with the 'two result' credit granting strategy.
The way that credit is awarded in a quorum of two is that the two claimed credits are compared and if they are within 30% of each other, then they are averaged and the average value is granted. Over 85% of workunits have the granted credit determined this way. If the two claimed credit values are further then 30% apart, then the code looks at a field in the database which stores the recent average credit granted per second for each computer. Whichever computer's claimed credit per second for the workunit is closer to their recent average credit granted per second has its claimed credit used as the credit granted for the workunit. What we found was that there were a few computers that were extremely consistent about claiming very low so they always caused the workunit to check the recent average history. Because they were consistently claiming low and it was matching their average granted credit they were being selected as the credit to use for the granted credit. We determined that these computers were claiming low by looking at the history of computers they were paired with and seeing their history - and indeed those other computers had a much lower grant when paired with one of these computers. As a result, we are going to change how the 2nd part of the process works. Instead of selecting the credit that is closest to its history, we will average the recent average history's for the two computers. We have been simulating the impact of this for the past couple of days and it turns out that in a strong majority of cases the result cpu time * host recent average credit per cpu second is actually quite consistent between different computers even if their claimed credit are further apart. This is what we had hoped to see and as a result we will start to use this policy in the near future. |
||
|
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1684 Status: Offline Project Badges:
|
Hi,
----------------------------------------I am very impressed how serious the tech-team is addressing this issue. The explanation is clear although the process is much more complicate and fair than I had hoped anyway. I suppose that systems providing accurately (and fast) a lot of results are paired very often in order to speed up the validation process. In this case, recurrent discrepancies between claimed and granted credits can occur easily because one of the both will always claim consistently low credits. In this case, I don't know if 64bit systems are really part of the root cause or only "random victims" of the attribution mechanism. Thank you for this open minded support. Cheers, |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello KerSamson,
I do not have any 64-bit systems to experiment with, but I have been told that Linux 64 systems seem to crunch work units faster than the same systems do in Linux 32. I do not know if this is true or not, but if it is true then the Linux 64 computers will consistently underclaim compared with the 32-bit systems. On the other hand, they will crunch and claim for more work units per day. So there is a lot of room for confusion. Lawrence |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Root cause is that the 64 bit BOINC system have an 'integer' benchmark component (Dhrystone) that is about twice of a 32 bit. This impacts the claim, as were it doing 64 bit computations, but in fact performing 32 bit. If a 32 bit client is run on top of a Xp64, the claims should be previously have already been close-r in any pairing. For now, I'm not sure how the system acts on averaging the 2 device RACs when 32 bit meets with 64bit (reserving my thoughts for the moment).
----------------------------------------The whole benchmarking system is under scrutiny at Berkeley. Who knows will a client in future e.g. run a 32 and 64 bit benchmark and uses the appropriate related to what the project is compiled to execute at.... optimized for 64 bit or not. ciao
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 1 times, last edit by Sekerob at Mar 20, 2008 3:53:50 AM] |
||
|
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1684 Status: Offline Project Badges:
|
Hi everybody,
----------------------------------------in my own case, I operate a 64bit boinc client on XP64. Surprising for me was that in the last time, the difference between claimed and granted credit is really significant (if you wish, I can send you per e-mail (Jean has my e-mail address) some pictures documenting this situation). The systems are not overclocked and I would expect that the systems experienced similar handling by the credit attribution process. It looks that it is not the case. The Q6600 receives more or less always what it claims and the double Xeon experienced very strong variations (+/- 4 points per core per hour). Finally, as long as boinc is running without any trouble, the situation is OK even if not optimal. Have a good day, |
||
|
|
|