This does allow cherry picking. A custom client could reject all tasks
that were going to take longer than average if that was known, as in High
versus Low angle ranges on SETI. It would also grant full credit for noisy
SETI tasks (15 seconds and quit).
How about:
The client maintains an average and standard deviation. The project
maintains an average and a standard deviation. The client transmits its
average, standard deviation, and estimated FLOPS for the task. The server
then uses these with its average and standard deviation to grant credits.
I would have to think about the actual formula involved to figure out what
it would be, but it should be possible to grant more credit for longer run
times and less for shorter run times. The client should also attempt to
track FLOPS / CPU Hour (and similarly FLOPS / GPU hour) so that the same is
reported to ALL projects for that client. The projects should feedback to
the client what the project came up with for the final FLOPS estimate for
each task - if this is possible at all.
Please consider how to handle a hardware upgrade.
jm7
David Anderson
<[email protected]
ey.edu> To
Sent by: BOINC Developers Mailing List
boinc_dev-bounces <[email protected]>
@ssl.berkeley.edu cc
Subject
08/28/2009 03:45 Re: [boinc_dev] [boinc_alpha] Card
PM Gflops in BOINC 6.10
I'm coming around to the viewpoint that projects shouldn't be expected
to supply estimates of job duration or application performance.
I think it's feasible to maintain these estimates dynamically,
based on actual job runtimes.
I've sketched a set of changes that would accomplish this:
http://boinc.berkeley.edu/trac/wiki/AutoFlops
Comments welcome.
BTW, a bonus of the proposed design is that it provides
a project-independent credit-granting policy.
-- David
Richard Haselgrove wrote:
> ... if projects
> are expected to fine-tune performance metrics down to the individual
> plan_class level, then I'm sorry, but they just won't. I've had to shout
> (loudly and repeatedly) at both AQUA and GPUGrid to get them to adjust
> rsc_fpops_est to within an order of magnitude of reality (in AQUA's case,
> two orders of magnitude).
_______________________________________________
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.
_______________________________________________
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.
