[rc5] 64-bit client oddity?

Tim Charron tcharron at interlog.com
Thu Oct 23 22:07:21 EDT 1997


> >> <<<<<<<<<<<<<<<<<<<<
> >> [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?)

Exactly correct.

-- Tim
 
Tim Charron
tcharron at interlog.com
tcharron at ctfinance.com
http://www.interlog.com/~tcharron/

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



More information about the rc5 mailing list