Another problem is problem tasks. If a task is aborted because it recycles
through the same check point, or continually crashes BOINC, sending it back
to the client is a mistake. Users would eventually get frustrated with
tasks that cannot complete that they would leave.
One possible fix for cherry picking is to limit its effectiveness. For
each task that errors or is aborted, reduce the daily quota by 1. However,
instead of doubling the daily quota add 2 ore even drop it to adding 1 per
good task. As it is at the moment, if the projects normal daily quota is
100 the client has to return one good task for every 50 rejects as it takes
51 aborted or errored tasks to have a good task not double the quota back
to normal. The limit of one good task means an increase of 1 in the daily
quota means that at least half of the tasks have to be returned correctly
to maintain your quota. The limit of one good tasks means an increase of 2
in the daily quota means that at least 1/3 of the tasks have to be returned
correctly to maintain your quota. Perhaps making the penalty for aborting
a task larger than the increase in the daily quota would be needed. In
this case, an error would still have a reduction in the daily quota of 1,
but an abort would have a reduction in the daily quota of say 4 with the
increase for a good task return being 2. If this were implemented, some
cherry picking could happen, but not as much.
jm7
john.mcl...@sybas
e.com
Sent by: To
boinc_dev-bounces David Anderson
@ssl.berkeley.edu <[email protected]>
cc
BOINC Developers Mailing List
08/31/2009 11:48 <[email protected]>,
AM [email protected]
Subject
Re: [boinc_dev] [boinc_alpha] Card
Gflops in BOINC 6.10
But, projects (at least SETI) have turned resend off as it is hard on the
DB.
jm7
David Anderson
<[email protected]
ey.edu> To
Sent by: [email protected]
boinc_dev-bounces cc
@ssl.berkeley.edu BOINC Developers Mailing List
<[email protected]>
Subject
08/31/2009 11:45 Re: [boinc_dev] [boinc_alpha] Card
AM Gflops in BOINC 6.10
There are big advantages to granting constant credit per app;
it eliminates the incentive for credit cheating,
and the need to check for it.
It should be possible to prevent cherry-picking,
e.g. by resending aborted jobs.
-- DPA
[email protected] wrote:
> 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).
>
_______________________________________________
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.
_______________________________________________
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.
