> Ah I have another theory as to why many results are timing out. I'v been
> doing Einstein for about a week, since the signup invite.
>
> The client must update to get it's new settings. When it first connects it
> has no settings and uses the boinc default 100. It ends up downloading too
> much first time round. Hence whilst my clients have not downloaded many WUs
> recently, in the first couple of days of running the project, until the client
> took up the effects of the resource share preferences, too many WUs exist
> which will now time out.
That is interesting. I hadn't thought about that but it might be a factor. I don't think very many people set their preferences first. Still, when I first setup it seemed to only download a couple of work units and then downloaded more later.
As to the time, of the Einstein deadline, this is testing. The short deadline is needed to help with the development. They have said it will probably be increased when the project goes public. Longer deadlines now, would only slow the bug fixes and slow the project going public.
> That is interesting. I hadn't thought about that but it might be a factor.
> I don't think very many people set their preferences first. Still, when I
> first setup it seemed to only download a couple of work units and then
> downloaded more later.
>
> As to the time, of the Einstein deadline, this is testing. The short deadline
> is needed to help with the development. They have said it will probably be
> increased when the project goes public. Longer deadlines now, would only slow
> the bug fixes and slow the project going public.
>
Meanwhile the too short deadlines direct interfere with that bug identification process due to the timing out. I've now detached from Einstein all slower PCs as they just aren't getting there, especially if they get switched off, or crash. Indeed a Predictor problem (now fixed I beleive) with an updated application, caused many mfold crashes that just halted boinc clients, or so I found out after the weekend wondering why so many of my own WUs hadn't been returned. 1 day more and most of my timed out WUs could have been returned, within limits. As it is, many results out of time have been returned and appear accepted since other have yet to complete. However in the meantime new versions of the WU may have been issued and will now needlessly be crunched.
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?
> 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!
> 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.
Using the mean opens the door to cheating. It is easy to change the benchmarks (this only has to be done once every 5 days). The person who does this will now gain an advantage in the stats, by using the median credit request, this person gains no advantage.
Glad to be here also. Got the long waited invitation after a 2 days trip to Münich. Pleasant surprise.
Estimated CPU time of a WU is roughly 9h. For S@H it is roughly 6:15h. and these are done in some 4:15h (using HT). This means my PC will make some 6:25h. for 1 E@H WU.
This is definitely too short, knowing a lot of us are participating also in other projects. I'm still waiting to start again LHC.
My suggestion is E@H should give us some 14 days like S@H.
> As mentioned in some other threads, the project is still in testing stage.
> The deadlines are being kept intentionally short for the testing period to
> better facilitate result analysis. The project team has announced that the
> deadlines will be extended when the project goes public. Remember that you
> "volunteered for testing." That is why you go the invite.
I can agree with this.
Indeed, the shorter the deadline the quicker an adaptation can be done.
For new users, it would be nice to put some information on the home page to inform how long it takes to finish 1 WU: I will have 1 or 2 WU's that will pass the deadline. Anyway, this is still Beta and we are here for testing purpose, but still, these are WU's that could be used in a better way if they were not passed the deadline.
> For new users, it would be nice to put some information on the home page to
> inform how long it takes to finish 1 WU: I will have 1 or 2 WU's that will
> pass the deadline. Anyway, this is still Beta and we are here for testing
> purpose, but still, these are WU's that could be used in a better way if they
> were not passed the deadline.
The deadline will be extended when they go live. But I had to stop as almost all my machines are running all available projects and so, I coiuld not seem to get any work done at all.
But this is also something that should be considered as a change to the scheduler and BOINC Manager code to accomidate the project that has a need for high speed processing. At the end of last year, Predictor@Home had a similar situation for a different reason, namely, they needed to get the work done by a specific date for a conference (Or, that is what my memory says... ) .
> Ah I have another theory as
)
> Ah I have another theory as to why many results are timing out. I'v been
> doing Einstein for about a week, since the signup invite.
>
> The client must update to get it's new settings. When it first connects it
> has no settings and uses the boinc default 100. It ends up downloading too
> much first time round. Hence whilst my clients have not downloaded many WUs
> recently, in the first couple of days of running the project, until the client
> took up the effects of the resource share preferences, too many WUs exist
> which will now time out.
That is interesting. I hadn't thought about that but it might be a factor. I don't think very many people set their preferences first. Still, when I first setup it seemed to only download a couple of work units and then downloaded more later.
As to the time, of the Einstein deadline, this is testing. The short deadline is needed to help with the development. They have said it will probably be increased when the project goes public. Longer deadlines now, would only slow the bug fixes and slow the project going public.
Team MacNN - The best Macintosh team ever.
> That is interesting. I
)
> That is interesting. I hadn't thought about that but it might be a factor.
> I don't think very many people set their preferences first. Still, when I
> first setup it seemed to only download a couple of work units and then
> downloaded more later.
>
> As to the time, of the Einstein deadline, this is testing. The short deadline
> is needed to help with the development. They have said it will probably be
> increased when the project goes public. Longer deadlines now, would only slow
> the bug fixes and slow the project going public.
>
Meanwhile the too short deadlines direct interfere with that bug identification process due to the timing out. I've now detached from Einstein all slower PCs as they just aren't getting there, especially if they get switched off, or crash. Indeed a Predictor problem (now fixed I beleive) with an updated application, caused many mfold crashes that just halted boinc clients, or so I found out after the weekend wondering why so many of my own WUs hadn't been returned. 1 day more and most of my timed out WUs could have been returned, within limits. As it is, many results out of time have been returned and appear accepted since other have yet to complete. However in the meantime new versions of the WU may have been issued and will now needlessly be crunched.
Part of the issue, I think,
)
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?
> Part of the issue, I think,
)
> 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
Director, Einstein@Home
> We're > changing the credit
)
> 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
Using the mean opens the door
)
Using the mean opens the door to cheating. It is easy to change the benchmarks (this only has to be done once every 5 days). The person who does this will now gain an advantage in the stats, by using the median credit request, this person gains no advantage.
BOINC WIKI
is is definitly to short
)
is is definitly to short
my Atlon64 3.200 running at 24/7
only for Info
Greetings from Germany NRW
Ulli
[img]http://boinc.mundayweb.com/one/stats.php?userID=380 [/img]
Hello Sir Ulli and the other
)
Hello Sir Ulli and the other known people.
Glad to be here also. Got the long waited invitation after a 2 days trip to Münich. Pleasant surprise.
Estimated CPU time of a WU is roughly 9h. For S@H it is roughly 6:15h. and these are done in some 4:15h (using HT). This means my PC will make some 6:25h. for 1 E@H WU.
This is definitely too short, knowing a lot of us are participating also in other projects. I'm still waiting to start again LHC.
My suggestion is E@H should give us some 14 days like S@H.
Greetings from Belgium
Thierry
> As mentioned in some other
)
> As mentioned in some other threads, the project is still in testing stage.
> The deadlines are being kept intentionally short for the testing period to
> better facilitate result analysis. The project team has announced that the
> deadlines will be extended when the project goes public. Remember that you
> "volunteered for testing." That is why you go the invite.
I can agree with this.
Indeed, the shorter the deadline the quicker an adaptation can be done.
For new users, it would be nice to put some information on the home page to inform how long it takes to finish 1 WU: I will have 1 or 2 WU's that will pass the deadline. Anyway, this is still Beta and we are here for testing purpose, but still, these are WU's that could be used in a better way if they were not passed the deadline.
Greetings from Belgium
Thierry
> For new users, it would be
)
> For new users, it would be nice to put some information on the home page to
> inform how long it takes to finish 1 WU: I will have 1 or 2 WU's that will
> pass the deadline. Anyway, this is still Beta and we are here for testing
> purpose, but still, these are WU's that could be used in a better way if they
> were not passed the deadline.
The deadline will be extended when they go live. But I had to stop as almost all my machines are running all available projects and so, I coiuld not seem to get any work done at all.
But this is also something that should be considered as a change to the scheduler and BOINC Manager code to accomidate the project that has a need for high speed processing. At the end of last year, Predictor@Home had a similar situation for a different reason, namely, they needed to get the work done by a specific date for a conference (Or, that is what my memory says... ) .