Either that, or keep stats for every day, and take the average of the last 30 'good' days (good being the days that the script succeeded in getting the data) and take average of that. This way there's a possibility to take the spikes out. Say: pick 30 days, take the 2 highest spikes and the 2 lowest spiks out, and devide the remainder by 26. Or something.. That's what I did way back when I created a signature only for myself, with the history available under my grid / my statistics history.


Oops, that last statement surprised me. Do I understand correctly that for GPU work, all that's available will be elapsed time, not run time? Meaning that if you set the GPU to work only 50% on Boinc, it will still report a run time of 24 hours per day instead of 12?
Then to GFL calculation. Do you know of any instance where 'our' GFLs have been compared to the real GFLs that a particular system is capable of. I suppose that the theoratical GFLs of a particular CPU can be found in some datasheet somewhere, or an application that tests and tells you the GFLs of your system. Of course Boinc has such a test if that's any good. Would be interesting to know if these values are close or way off. Perhaps that could bring us some closer to the multiplication value to settle for.

Last 30 good stat days is fine too. Taking the increase between 2 dates and divide by days passed is I think as good. No need for the scientific down to the 8th decimal... cant imagine dogfights because one has 7.256 days and the other 7.255... it's general indicative to me in good jest.

Yes, what BOINC logs is Elapsed time for GPU tasks. If this is throttled to 50% then that's reflected in the Elapsed time, don't think you'll get the ol UD agent running at 25% and still clocking 100% runtime per day. We-ll just have to wait what WCG decides on. BTW, I consider run-time and elapsed time interchangeable, a semantical variation that only slightly differs.

For credit, the official wiki page was changed by admin on July 2010 from 100 to 200 credit per Ghz, the history http://boinc.berkeley.edu/w/?title=Computatio...;diff=2818&oldid=1126 . No notes as to the motivation [widespread hyperthreading?]

Know no place other where than GFL we compute off the points/credits. Kind of not expecting a separate credit/time recording scheme for GPU, all expecting to go into a single HCC pool adding to the same badge.

--//--

David  10 Jun 2010
    - server: change credit constant from 100 to 200.
        Data from S@h beta (running for a month or so)
        suggests that this will almost exactly match the
        average credit granted by S@h's old system
        (which, in theory, is the reference for other projects)