[rc5] 64-bit client oddity: solved?

Jeff Woods jeff at delta.com
Fri Oct 24 10:17:03 EDT 1997


At 03:47 PM 10/23/97 -0700, you wrote:

>Couldn't have said it better myself. Although it looks like the client
>just eats a block, it really doesn't. No need for panic, you can all go
>back inside your homes now. =)

Indeed.   This machine did NOT ever reboot, but I've trimmed the guff:

(Now I'm only worried about the OTHER apparent problem -- the blocks that
apparently get lost when the system is restarted, that some are mentioning
here.   I realize that the FAQ says that such blocks are NOT reclaimed, but
there ought to be a way for the system to "recover" and at least finish
checking the blocks it checked out -- or is that the purpose of the
ckpoint.rc5 files in the new client, which are OFF by default?   I've
turned ckpoint files on in my system, so should I assume that it won't now
lose those blocks that it would have had I restarted the client?]

[10/23/97 16:57:06 GMT] The proxy says: "The cows are invading!"
<<<<<<<<<<<<<<<<<<<<
[10/23/97 16:57:31 GMT] Retrieved 20 block(s) from server
[10/23/97 16:57:31 GMT] Block: 64B16F3C:40000000 ready for processing
[10/23/97 16:57:31 GMT] 19 Blocks remain in file D:\NT40\buff-in.rc5
[10/23/97 16:57:31 GMT] 0 Blocks are in file D:\NT40\buff-out.rc5
Child thread # 1 has been started.
[10/23/97 16:57:31 GMT] Block: 64B16F3C:20000000 ready for processing
[10/23/97 16:57:31 GMT] 18 Blocks remain in file D:\NT40\buff-in.rc5
[10/23/97 16:57:31 GMT] 0 Blocks are in file D:\NT40\buff-out.rc5
[10/23/97 17:08:23 GMT] Completed block 64B16F3C:40000000 (268435456 keys)
                        00:10:51.77 - [411851.69 keys/sec]
.
.
.
[10/23/97 20:13:42 GMT] Completed block 64B16F34:80000000 (268435456 keys)
                        00:10:54.74 - [409987.24 keys/sec]
[10/23/97 20:13:42 GMT] Block: 64B16F34:50000000 ready for processing
[10/23/97 20:13:42 GMT] 0 Blocks remain in file D:\NT40\buff-in.rc5
[10/23/97 20:13:42 GMT] 18 Blocks are in file D:\NT40\buff-out.rc5
[10/23/97 20:13:42 GMT] Total: 18 blocks 03:16:44.85 - [409309.25 keys/sec]
[10/23/97 20:24:36 GMT] Completed block 64B16F34:70000000 (268435456 keys)
                        00:10:54.63 - [410055.51 keys/sec]

[10/23/97 20:24:44 GMT] The proxy says: "Mmmmmm... Beeerths... alde.com"
<<<<<<<<<<<<<<<<<<<<
[10/23/97 20:25:04 GMT] Retrieved 20 block(s) from server

[10/23/97 20:25:05 GMT] The proxy says: "Mmmmmm... Beeerths... alde.com"
>>>>>>>>>>>>>>>>>>>
[10/23/97 20:25:25 GMT] Sent 19 block(s) to server
                        ^^^^^^^

[Hint: it is STILL processing that ONE queued block!]

[10/23/97 20:25:25 GMT] Block: 64E12ADB:00000000 ready for processing
[10/23/97 20:25:25 GMT] 19 Blocks remain in file D:\NT40\buff-in.rc5
[10/23/97 20:25:25 GMT] 0 Blocks are in file D:\NT40\buff-out.rc5
[10/23/97 20:25:25 GMT] Total: 19 blocks 03:28:27.68 - [407771.35 keys/sec]
.
.
.
[10/23/97 23:51:49 GMT] Completed block 64E12AC9:F0000000 (268435456 keys)
                        00:10:51.34 - [412123.58 keys/sec]
[10/23/97 23:51:49 GMT] Block: 64E12AC7:F0000000 ready for processing
[10/23/97 23:51:49 GMT] 0 Blocks remain in file D:\NT40\buff-in.rc5
[10/23/97 23:51:49 GMT] 19 Blocks are in file D:\NT40\buff-out.rc5
[10/23/97 23:51:49 GMT] Total: 38 blocks 06:54:51.13 - [409806.41 keys/sec]

[10/24/97 00:02:51 GMT] Completed block 64E12AC8:50000000 (268435456 keys)
                        00:11:01.10 - [406043.03 keys/sec]

[10/24/97 00:03:00 GMT] The proxy says: "It's time to move...length! "
>>>>>>>>>>>>>>>>>>>>
[10/24/97 00:03:21 GMT] Sent 20 block(s) to server

[10/24/97 00:03:23 GMT] The proxy says: "It's time to move...length! "
<<<<<<<<<<<<<<<<<<<<
[10/24/97 00:03:46 GMT] Retrieved 20 block(s) from server

{Hint: by NOW it is synchronized!]

Rinse 20 blocks.  Repeat as necessary.


>> >the client now is processing 1 block and preparing to process the
>> >next, so you started block1 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