Message boards :
Number crunching :
Why èarn some WUs a very low credit?
Message board moderation
Author | Message |
---|---|
Send message Joined: 14 Feb 10 Posts: 14 Credit: 110,233,511 RAC: 0 |
About 70% of my results look like this: run time | CPU time | credits 223.89 | 1,807.51 | 28.25 But the other 30% look like this: run time | CPU time | credits 224.09 | 1,863.43 | 1.41 Why are there so many results with such low credits? This happens on 2 different PCs. |
Send message Joined: 9 Aug 22 Posts: 82 Credit: 2,848,270 RAC: 6,873 |
About 70% of my results look like this: Could you give me the task ids or workunit ids? |
Send message Joined: 14 Feb 10 Posts: 14 Credit: 110,233,511 RAC: 0 |
low: https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=943784423 high: https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=943780641 |
Send message Joined: 24 Jan 11 Posts: 715 Credit: 555,431,030 RAC: 38,335 |
Tasks like this one have no usable work involved. So no or very little credit. 0.11 credits https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=943807851 If you inspect the stderr.txt output you see this kind of statement. Number of particles in bins is very small compared to total. (0 << 1). Skipping distance calculation |
Send message Joined: 14 Feb 10 Posts: 14 Credit: 110,233,511 RAC: 0 |
Tasks like this one have no usable work involved. So no or very little credit. 0.11 credits Such tasks I have not seen in my list. |
Send message Joined: 1 Jan 17 Posts: 37 Credit: 111,038,525 RAC: 35,894 |
Another factor besides what Keith Myers pointed out is that, AFAICT, CreditNew is in place. This system estimates workunit difficulty and machine performance and thus credits. Which is not easy at projects with highly variable and seemingly unpredictable workunit size, or/and machine performance depending on multithreading efficiency or inefficiency, et cetera. As you can see from the documentation, one central element of the CreditNew algorithm is the use of moving averages over time. An effect of this is that computers which never ran MilkyWay before, or even which haven't run it for a couple of weeks lately, receive rather random credit. Computers which have been running MilkyWay continuously recently (or more precisely, got numerous results validated in recent time), appear to receive more consistent credit. That is, the CreditNew algorithm converges to a more apt estimation the more results a computer got validated. Or at least, that's the goal of the algorithm, and my impression is, that it actually works rather reasonably with the kind of work which is done here at MilkyWay. (It's open for debate. Many BOINC veterans are not quite fond of CreditNew.) Another note on convergence of CreditNew: A few years ago, I actively participated at YAFU. There the workunits were so wildly different from each other, that CreditNew never was able to get to a point which could be called a convergence. I haven't been looking at YAFU lately, but I suspect it still operates this way. |
Send message Joined: 14 Feb 10 Posts: 14 Credit: 110,233,511 RAC: 0 |
[quote] one central element of the CreditNew algorithm is the use of moving averages over time. /quote] I think I know this effect from other projects. But there nearly all WUs are affected and show a bit lower credit at the beginning. In Milkyway there are only a few WUs affected and the have significantly low credit. But if this also can be explained by "new credit", I am fine with it. Last night no new low credits were seen. In the meantime I have also seen some of the "skipping" WUs, but they run only a few seconds, so the 0,x credits are OK for this short time. |
©2024 Astroinformatics Group