Apis,

This is just a credit issue. It looks some normalization was run on the claimed credit. It looks as though you were granted greater credit than you claimed.

We will be bringing up these extremely long running MCM1 work units with researchers as they mess with the estimated flops needed for work units. In an ideal world, the work units would be extremely easy to predict the sizes.

Also, I will be turning the assimilator on for BETA soon which should clear out some old results sitting in your Results Status page.

Thanks,
-Uplinger

Right, how poorly implemented would anyone like it to show before someone takes hammer and stick to help that crappanism out of it's misery? CEP2 credit dropped to an average of 14.6 per hour yesterday and the 7 day [smoothed] average, removing the outliers, to 16. See a correlation between runtime and credit? Then of course we're now computing all 16 jobs and not maxing out at 12 as was the case in the previous year or 2... and in a 3rd of the time.

This system was designed for steady runtimes, and 'that' is not what we have at WCG, not from job to job, not from week to week, not from batch to batch, and not when the amount of work packed to tune the 'average' run time is changed [the technician's feeder-cutter]. Picture what's potentially coming when the dynamic sizing-to-power comes and all credit is still being pooled in one science pot [Hope techs anticipated on that].

Edit: Remains that specific question, why 3 tasks of the top 2 posts that lasted 37 hours and more had a 'claim' of 112 and 2 in a quorum got that as grand too with a 3 credit per hour where the 'normal' many time that. No one thinking this is a little more than very suspect?