[RC5] ogr percentage done - WHY impossible?
dan_oetting at uswest.net
Mon Mar 19 15:55:34 EST 2001
on 3/19/01 2:20 PM, Stephen Garrison wrote:
>On Thu, 15 Mar 2001, Dan Oetting wrote:
>> The total number of 6-stubs that are valid for OGR-24 is somewhere around
>> 50 million if I remember correctly. The difficulty of verifying each stub
>> will depend on how early the various tests cut off the recursion
>> branches. The biggest factor for stub difficulty will be the length of
>> the stub. Shorter stubs have less constraints and will take longer to
>> process. The longest stubs will hit most of the cutoffs very soon so will
>> take almost no time to process.
>Even if it isn't exact to say the percentage of work done is equal to the
>number of stubs done (a) it is our best guess and (b) it should "average
>out" of the life of the contest to be a pretty decent guess of the amount
>of work completed and amount left to be completed.
>P.S. You had another msg later on about how "you shouldn't have trusted
>your memory" concerning the number of stubs. The number in the msg I am
>responding to corresponds to OGR-24. The other one that you "corrected" it
>with was for OGR-25.
My memory was off on both counts. The only number I have is for for
OGR-25. I wouldn't trust anything d.net has to say until they stop
covering up the problems.
The distributed.net OGR code was derived from GARSP. The last ruler GARSP
ran was OGR-23 and that is all the code was good for. None of the
original developers of GARSP came along to help port the code so the
OGR-23 limits were never fixed for the d.net runs of OGR-24 and OGR-25.
The first problem to surface was an internal table was being accessed one
byte passed the end. This was first reported almost a year ago but was
soon dismissed when recompiling with different options allowed the client
to pass the internal tests. [All the clients running today are accessing
this invalid byte but they all pass the tests because the "valid" results
were also generated by the buggy code] Someone finally discovered the
fault was not a compiler error and at some point I was brought in because
I actually knew something of how the OGR code worked. It was still weeks
before this was even discussed on the coders list. I was waiting to let
d.net make the official announcement and I finally forced their hand by
posting a reference to the bug. I think this all transpired back in
Nov/Dec but don't trust my memory.
I was able to prove that even though this was a major bug the client
results were still valid. The bug was causing the client to work about
15% extra but no valid rulers were being skipped.
But then other bugs started being discussed on the coders list. The
thread safety problem was brought up where the buffer between the main
client and the core thread could get corrupted. A serious problem but if
it doesn't happen too often the invalid results can be filtered out in
the verification pass. Stubs were being truncated in checkpoints. This
only affected a few clients and cause some rulers to be retested when
restarting from the checkpoint. And then the reason we don't know how
many stubs there are is because the master stub generator was throwing
out all stubs with a total length greater than 70. This was valid for 3
mark stubs in OGR-23 but is totally wrong for 6 mark stubs in OGR-24.
I don't know what's holding up the new clients. The OGR code has been
fixed, the buffer problems could be patched with a simple handshaking,
the master stub generator needs to be rebuilt but it is essentially the
same code as in the OGR core. And somebody needs to explain to the users
why a year or two of crunching is going to be thrown out when OGR-24 and
OGR-25 are restarted.
I've tried to let the word out softly but my posts are being censored by
the d.net staff. You should switch your clients to RC5 until the new
clients are released so you don't waist more cycles. Or go hunt aliens
with Seti at home like I have been doing.
-- Dan Oetting
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5