Credit raise
17 Oct 2007 14:26:51 UTC
Topic 13610
(moderation:
We're still working on getting a grip to the large runtime variation that came up with splitting up the sky in S5R3 (it was averaged out in the "all-sky" search in S5R2).
However we found that on average we were still awarding too little credit compared to other projects recently, so we decided to raise the credit by 7%.
Note that due to server-assigned credit this will only affect newly generated workunits, so it will take some time to propagate through to your statistics.
BM
BM
Credit raise
)
We are still not capable of even correctly anticipating this variation.
Personally I would rather be in favor of flattening the variation by measurements in the App than to react to the variation with deadlines and credits, but I still don't know whether this would be possible.
At a meeting that covers next week all relevant people (including the authors of the code in question) will be at one table, I hope things get sorted out then.
BM
BM
RE: I also agree that
)
We need some more information, but I doubt that it can be provided by participants. It would probably need some additional code in the Apps to write out some traces, and something on the server side to follow them. Anyway, this is something we are still working on, and we hope to make some progress next week.
BM
BM
RE: Oh yes, it would have
)
No, it's not about lying. It's about getting the relation right between certain properties of the workunit and dynamically calculated parameters in the App that affect the runtime. At the very moment, neither of these is visible to the participants, and even to us only when running under a debugger (or with an amount of debug output that would fill up your harddisk). We see the sinewave over all workunits of a given frequency band, but it's still hard to predict the phase, which would be important for a specific WU.
BM
BM