[rc5] 64-bit client oddity?

Jeff Woods jeff at delta.com
Thu Oct 23 13:36:13 EDT 1997


At 09:15 AM 10/23/97 -0700, you wrote:

>> <<<<<<<<<<<<<<<<<<<<
>> [10/23/97 15:02:19 GMT] Retrieved 20 blocks from server
>> [10/23/97 15:02:19 GMT] Block:  6400A121:10000000 ready for processing
>> [10/23/97 15:02:19 GMT] 19 blocks remain in file C:\RC5\buff-in.rc5
>> [10/23/97 15:02:19 GMT] 0 blocks are in file C:\RC5\buff-out.rc5
>> Child thread # 1 has been started.
>> [10/23/97 15:02:19 GMT] Block:  6400A121:20000000 ready for processing
>> [10/23/97 15:02:19 GMT] 18 blocks remain in file C:\RC5\buff-in.rc5
>> [10/23/97 15:02:19 GMT] 0 blocks are in file C:\RC5\buff-out.rc5
>> .....10%.....20%...
>> 
>the client now is processing 1 block and preparing to process the next,
>so you started block 1 and staged block2 for when block1 finished...

I'm going to guess this was done so that the time spent communicating with
the proxies could also be spent testing keys in another thread?   I.e. if
the entire buff-in.rc5 file was tested, there would have been a "dead" time
in the old system while the proxy was contacted, results sent, and block
retrieved, and depending on the proxies and the buffering levle (defaulted
to five, no?), that a Pentium-166 was wasting nearly one minute of every
90, or 1% of its time, communicating with the proxies while NOT testing (a
percentage that would be WORSE the faster the CPU got!).  

So now it will begin testing the last block AND will simultaneously flush
the buffer, get more blocks, and queue the next one, saving that minor
percentage down time?   Right?   (Or is there another reason?)


----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list