The current arrangement is unbalanced in favor of reward over punishment.
For example at s...@h where the quota is 100, it takes 99 unsuccessful tasks
in a row to reduce the quota to 1. It then takes 7 successful tasks in a
row to increase the quota to 100.
For a hypothetical project where the quota is 1000, it would take 999
unsuccessful tasks in a row to reduce the quota to 1, and just 10
successful tasks to increase it back to 1000.
I would propose a more balanced approach where the punishment is a on the
same order as the reward and have both split between the report and
validation. This approach would require that the punishment for an invalid
result be larger than the reward for a successful task. I would propose
that the two rewards when multiplied together be on the order of 2 and the
2 punishments when multiplied together be somewhat less.
I see the reward/punishment mechanism as doing several things:
1) Make cherry picking expensive. If you have a habit of cherry picking,
you are harming the project, and should have your quota cut.
2) Deal with machines that are intentionally or unintentionally returning
garbage of one sort or another (unsuccessful or invalid results).
We should have a discussion of whether computers that return 1 out of every
2 tasks as successful and valid should be slowly punished or slowly
rewarded. My thought is that these are not trustworthy computers and
should never have an unlimited quota. What ratio should be rewarded?
In both cases, getting back to full trusted status with just 7 or 8
successful valid results does not seem like much of a hardship.
This can be done with
jm7
David Anderson
<[email protected]
ey.edu> To
Sent by: BOINC Developers Mailing List
<boinc_dev-bounce <[email protected]>
[email protected] cc
u>
Subject
[boinc_dev] host punishment
05/24/2010 03:03 mechanism revisited
PM
The BOINC scheduler has a mechanism called "host punishment"
designed to deal with hosts that request an infinite sequence of jobs,
and either error out on them or never return them.
It works like this: there's a project parameter called "daily result
quota",
say 100. Every host starts off with this quota.
If it returns an error or times out, the quota is decremented down to,
but not below, 1. If it returns a valid result, the quota is doubled.
The idea is that faulty hosts are given 1 job per day
to see if they've been fixed.
Recently this mechanism was changed from per-project to per-app-version,
the idea being that a host might be erroring out on a GPU version
but not the CPU version.
However, the basic mechanism is somewhat flawed:
1) What if a fast host can do more than 100 jobs a day?
We could increase the default quota, but that would let bad hosts
trash that many more jobs.
2) It takes too long for a fixed host to ramp up its quota.
The bottom line: as long as a host is sending correct results,
it shouldn't have a daily quota at all.
---------
If anyone has ideas for how to change the host punishment mechanism,
please let me know.
I'll think about it and post a proposal at some point.
-- David
_______________________________________________
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.
