[RC5] ogr percentage done - WHY impossible?

Dan Oetting 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 mailing list