| 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 |
|
|
Mizet
Cruncher Joined: Feb 9, 2008 Post Count: 6 Status: Offline |
Hi all,
Ireally don't understand how points are attribuated. Can someone look at WU dddt(0401m0747 100013 and explain me Thanks for all |
|||
|
||||
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Hi, if you go to the Result Status page, click on the Work Unit name of that sample and copy the quorum detail into your post we´ll give it a try.
----------------------------------------(we´re not permitted to look into the result details except our own) ttyl
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Mizet,
Here are some helpful Start-Here threads explaining the Results Status page and quorums: http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=6105 http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=17303 Lawrence |
||
|
|
Mizet
Cruncher Joined: Feb 9, 2008 Post Count: 6 Status: Offline |
Sekerob here is the quorum detail (I think)
Project Name: Discovering Dengue Drugs - Together Created: 05/03/2008 02:11:13 Name: dddt0401m0747_100013 Minimum Quorum: 2 Initial Replication: 2 dddt0401m0747_ 100013_ 0-- Valide 08/03/2008 18:24:21 09/03/2008 12:00:03 7,59 54,6 / 54,6 dddt0401m0747_ 100013_ 1-- Valide 08/03/2008 18:17:24 09/03/2008 19:41:06 16,37 104,5 / 54,6 What i don't understand is the reason why 7,59Hours give 54.6 like 104.5. Sometimes they give (54.6+104.5)/2 -> 79.55 sometimes 54.6 like here. Not very important but i want to understand. Thx for your help in every case |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Basically the ratio of hours and claim is way outside the expected. Here's why:
----------------------------------------- Top claim is 54.6 / 7.59 = 7.2 per hour of computing. - Bottom claim is 104.5 / 16.37 = 6.38 per hour of computing. What really should have been in the 'normal' is that the bottom client should have been computing like 7.2/6.38 * 7.59 = around 8.6 - 9 hours. When both clients produce a claim within statistical variation, the average credit is computed. If there is though a big deviation like this one of near 100%, the system looks at who was closest to the historical claim history in the device database and gives that value to both. The question now is, why the machine claiming 104.5 took 16.37 hours where its performance benchmark suggests it should be able to do it in say 9. Is your machine running hot? Can you check with CPU-Z what the actual CPU speed is versus what it should run at. Sometimes computer reduce the CPU speed, but that does not change the benchmark resulting in an overclaim / job running much longer. Can tell you though for sure, there is an extreme hi improbability of a 54.6 over 104.5 being averaged. Very sometimes a fast machine had a poor benchmark moment when very busy with something else, which could in fact have the claim going towards the 104.5 for both.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Mizet
Cruncher Joined: Feb 9, 2008 Post Count: 6 Status: Offline |
One time again Seke thx for your explainations, i understand.
In fact the real probleme is to know how is calculated the claim credit for a job, if it is a function of the crunching time we are going round. But doesn't matter, my little Pentium 4 PC never crunched so fast. Was just to understand, i do. Regards |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Find in your log the Whetstone+Dhrystone. Add these up and divide by 480 and you have the approximate hourly claim. If the benchmark is run at say 3ghz, but the real computing happens at 1.5 ghz, the hours and claim double. You will though be claiming hours as-if the machine was computing at 3ghz.
----------------------------------------There are a number of cases why it can go wrong..... like a client testing at 64bit but processing at 32bit. Suspect with someone mentioning RMclock that another potential case is looming. Anyway, it's a long long topic and many hot pages have been spend on this. --//--
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
jal2
Senior Cruncher USA Joined: Apr 28, 2007 Post Count: 422 Status: Offline Project Badges: 
|
Very interesting discussion Sek. It explains some of the 'how did they calculate the points' questions I've had.
----------------------------------------Playing the devil's advocate, your equations relies on the faster computer being correct, and doesn't handle the case when it had an unusually fast WU. I would hope a given computers average, or expected, baseline performance values would be taken into account. Am I correct that a single baseline credits per hour is calculated for a given machine? Given that different projects stress the machine in different ways, it would be more accurate to have a different cph value for each project. Also, since it would be trivial to calculate the expected credit request for the above set of numbers, would it be better to use an average of the calculated averages instead of just throwing the slow computers number away? paraphrasing and expanding your discussion: - Top claim is 54.6 credits / 7.59 hours = 7.2 credits per hour of computing. - Bottom claim is 104.5 credits / 16.37 hours = 6.38 credits per hour of computing. As the expected time for bottom claim is 7.2/6.38 * 7.59 = around 8.5 hours, it is out of range for the actual time and the claimed credits are discarded. An alternate bottom claimed credits value could be calculated using the above ratio and the accepted valid claimed credits: (7.2/6.38) * 54.6 = 61.6 credits. I'm sure there are many variations to this theme, and most have probably been tried and discarded for various reasons. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Hi jal2,
----------------------------------------thanks for sharing your thoughts. Indeed many an approach has been considered, but from the below list, I'd say all is pretty well in tune.... some win some loose. If you visit the Supplemental Graphs post in Start Here forum you can see how well DDDT & HCC track only confirming that the best workable is in place. With looking at details there are 2 wild ones with substantial long hours, but 'just not' being outliers, thus still the average being used. What will be interesting to see is how the single distribution will translate into claim v credit. I'm sure WCG is building a dataset this very minute to arrive at some good reference data and with graphs on hand not hard to miss if it would work out to be inequitable.... 75-76 cph I'd expect it to stay unless the late UD converters jump on where I'd expect a larger than average number of slower devices pulling down the number. dddt0401l0687_ 100286_ 0-- 361642 Valid 03/05/2008 22:58:06 03/11/2008 10:36:46 4.78 73.0 / 77.5 dddt0401l0687_ 100272_ 1-- 361642 Valid 03/05/2008 22:55:53 03/11/2008 09:08:07 4.92 75.2 / 72.3 dddt0401l0687_ 100170_ 0-- 361642 Valid 03/05/2008 22:54:40 03/11/2008 08:17:54 4.87 74.4 / 73.5 dddt0401l0687_ 100073_ 1-- 361642 Valid 03/05/2008 22:54:40 03/11/2008 06:12:22 5.10 78.1 / 71.4 dddt0401l0687_ 100252_ 1-- 361642 Valid 03/05/2008 22:53:20 03/11/2008 05:27:49 4.92 75.3 / 85.4 dddt0401l0686_ 100361_ 1-- 361642 Valid 03/05/2008 21:19:59 03/11/2008 03:52:16 4.76 72.7 / 80.7 dddt0401l0686_ 100182_ 0-- 361642 Valid 03/05/2008 21:05:45 03/11/2008 03:05:54 4.99 76.2 / 72.6 dddt0401l0685_ 100379_ 0-- 361642 Valid 03/05/2008 20:54:32 03/11/2008 00:48:17 4.66 71.2 / 71.9 dddt0401l0684_ 100162_ 1-- 361642 Valid 03/05/2008 19:43:11 03/11/2008 00:09:57 5.23 79.9 / 81.0 dddt0401l0683_ 100132_ 1-- 361642 Valid 03/05/2008 18:38:46 03/10/2008 22:49:01 4.79 73.3 / 70.7 dddt0401l0716_ 100285_ 1-- 95711 Valid 03/07/2008 09:43:23 03/10/2008 21:44:12 7.81 82.5 / 78.8 dddt0401l0683_ 100168_ 0-- 361642 Valid 03/05/2008 17:22:54 03/10/2008 18:36:14 4.58 70.0 / 75.3 dddt0401l0682_ 100067_ 0-- 361642 Valid 03/05/2008 16:21:33 03/10/2008 17:39:36 4.66 71.3 / 76.9 dddt0401l0712_ 100458_ 0-- 95711 Valid 03/07/2008 05:32:52 03/10/2008 17:04:58 8.25 87.1 / 88.2 dddt0401l0681_ 100031_ 0-- 361642 Valid 03/05/2008 16:02:16 03/10/2008 16:44:28 4.61 70.5 / 78.7 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 --//--
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
RedMenace
Cruncher Canada, eh! Joined: Nov 19, 2007 Post Count: 28 Status: Offline Project Badges: 
|
Well I've been really getting hamemred on the points the last few days. Here's one example of getting dinged 30 some points for my fast processor: E6750 humming at 3.2ghz.
----------------------------------------dddt0501b0120_ 100392_ 0-- Valid 03/17/2008 09:27:00 03/18/2008 11:32:40 5.75 45.2 / 45.2 dddt0501b0120_ 100392_ 1-- Valid 03/17/2008 09:23:47 03/18/2008 12:04:08 2.68 77.2 / 45.2 I'm allowing some non-wcgs in to protest ;)
"If you want to go fast, go alone. If you want to go far, go together!" -- African Proverb
|
||
|
|
|