Sorry, forgot to include everyone
---------- Forwarded message ---------- From: Eric J Korpela <[email protected]> Date: Mon, Aug 31, 2009 at 12:56 PM Subject: Re: [boinc_dev] [boinc_alpha] Card Gflops in BOINC 6.10 To: David Anderson <[email protected]> Hi David, A couple comments before you get too far into the minefield. Your method is really similar to what the credit multiplier does. I'd suggest using median rather than an average. Averages are very susceptible to a single bad data point. Just try finding the average memory of machines running s...@home... The first time you try, you'll get NaN. If you exclude NaNs you'll get Inf. If you only allow finite values you'll get a few petabytes rather than the correct value of a couple GB. Medians are harder to calculate, but they tend to stay reasonable when given a few bad values. If you don't want to calculate the median of all of the results you can use a exponential average of the median of the last N results. On Mon, Aug 31, 2009 at 8:45 AM, David Anderson<[email protected]> wrote: > There are big advantages to granting constant credit per app; > it eliminates the incentive for credit cheating, I assume you mean per result. It doesn't eliminate the incentive for all credit cheating, just the cheating you get by adjusting your benchmarks. Short circuiting will probably become a more favored method, especially on projects with little or no validity checking. > It should be possible to prevent cherry-picking, > e.g. by resending aborted jobs. The other problems I see are 1) projects where job durations cannot be estimated or vary by orders of magnitude. This could be fixed by allowing project apps to continue to call boinc_ops_cumulative() or boinc_set_credit_claim() and using the value returned as a scaling factor. So rather than "flops_avg" you would have flops_per_claimed_credit_median. If no credit claim is made, then treat it as if boinc_set_credit_claim() had been called with a value of 1. (Or a project defined value). That leads to the same behavior you are proposing. That would allow projected to have multi length workunits with credits that represented the amount of work done, as well as preserving the value of apps that already use boinc_ops_cumulative() or boinc_set_credit_claim(). 2) Estimated GPU FLOPs can be wrong by several orders of magnitide depending upon the application. (CPU estimated FLOPs might only be off by 1/2 to 1 order of magnitude for typical applications.) For projects that have both CPU and GPU apps that do the same thing, the scaling will just drop out by enforcing equal credit for equal work. For GPU only, or apps that do different work under GPUs and CPUs, I don't know what to do short of requesting that projects run one or more results under CUDA emulation in order to arrive at a scaling factor for that app. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
