Deadlines too short?
Anonymous
27 Jan 2005 1:56:48 UTC
Topic 10759
(moderation:
> Part of the issue, I think, is process times. New work units are projected to
> have (on my 500 mhz machine) a process time of 25 hours. Actual crunch time
> has varied between 42 and 44 hours for the three units I have complete. So in
> essence, when I download new work, I am actually downloading twice the work as
> I can actually handle. Since the downloaded work insn't getting finished
> before the deadline, subsequent work only gets further and further behind.
>
> Also, the first work unit I completed took the equivilent of 132 credits to
> complete on my machine. Now that the third version of that workunit has
> posted, I ended up getting credited for something like 27 credits? Is this
> common? That is about a third of what I am getting credit from SETI for doing
> the equivalent amount of work. (In other words, a SETI workunit takes about 13
> hours to crunch for 30+ credits. Einstein workunit takes about 42 hours for 27
> credits?) Or is this related to the coming update mentioned?
This looks like really bad luck. The machine that generated the 'canonical' result was an ancient AuthenticAMD Pentium. It has extremely low FP and Integer
benchmark numbers. So even though it took 25 hours to complete the WU, the
credit that it claimed was very small.... and that's what you got. We're changing the credit granting mechanism slightly, soon, so that the credit granted is actually a mean of the values and not the credit given to the canonical result. This should prevent such injustice in the future!
Bruce
Deadlines too short?
)
> We're
> changing the credit granting mechanism slightly, soon, so that the credit
> granted is actually a mean of the values and not the credit given to the
> canonical result. This should prevent such injustice in the future!
Let me add a few remarks to this.
Injustice cannot be avoided completely, only reduced. This is due to how the
validator works within the BOINC framework. (I will have to go into details
a bit now to make the problem clear...)
Let a workunit consist of four individual tasks (in BOINC speak, "results";
I will call them "jobs" instead, not to confuse them with result files).
These four jobs will be sent to four client machines which will return (upload)
a file each at the end of the computation.
As soon as a "quorum" is reached (currently: three result files uploaded and
marked "success"ful in the database) the validator is called to validate the
corresponding workunit. It will check the sanity of every single file, and
provided they are all sane, they will be matched against each other.
(If one of the files was insane, we'd lose the quorum, another job would be
generated, and "Redo from start".)
If there is a sufficient match (at least between two result files), we can
determine a canonical result (the one that matches best - you see why we need
three results now!) and from all results that match the canonical one (at least
two) we calculate the credit to be given (2 results -- minimum, 3+ results:
strip minimum and maximum, average the rest - that's BOINC's approach. With
the minimum of two credit requests, we first had to fix the restart-zero
credit issue.)
Now that the canonical result and credit have been defined, we can wait for
additional result files to be uploaded. These - as they are late - can only be matched against the canonical result, and if they succeed, they are granted
the canonical credit.
You see that the faster machines (and the ones with a shorter queue!) will be
favoured when defining the canonical result, and who comes in late has to take
the "leftovers". This means that if you're lucky you'll get a lot more credit
than you asked for - or if you're unlucky you get less. And if you're too late
(and missed the deadline) you might get nothing at all.
Steffen