[RC5] Strange Mathematics ?!

Andreas Beckmann andreas.beckmann at student.uni-halle.de
Wed Jan 20 02:11:56 EST 1999


Hi,

I just realized I miscalculated my DES buffer size, and loaded twice the
amount of neccessary blocks because there seems to be a bug in the
calculation of the DES keyrate:

>From my logfile:
...
[Jan 19 20:53:33 UTC] Completed one DES block 00253681:B0000000 (4*2^28
keys)
                      0.01:02:16.25 - [574,769.79 keys/sec]
...
[Jan 19 21:55:52 UTC] Completed one DES block 0025367D:40000000 (4*2^28
keys)
                      0.01:02:19.28 - [574,304.04 keys/sec]
...

4*2^28 keys / 1:02 hours
=1073741824 keys / 3720 s
=288640 keys/s
This is only the half rate from above!
(my computer is a single P120, the client (432 win32 gui) runs only one
thread, the time measured for completion of a 2^30 keys block is correct and
all blocks were processed without a restart)

I get keyrates around 570 kkeys/s DES when benchmarking with both CLI and
GUI since version 417.

This looks very strange to me!
So I did some further calculations:
- RC5 keyrate (in the client/logfile) is OK
- The keyrate shown in my RC5 statistics as Overall Rate cannot be
recalculated as
("Total blocks checked" * 2^28) / ("Working time" * 24 *60^2)
I get a smaller value.
Could someone explain this, please?


Another Topic: Recycling of RC5 blocks
=============================
How long approximately can I keep a RC5 block before it gets recycled? I've
got some friends without internet access and I want to exchange buffer files
on disks. But I want to do this only once per week or better once in two
weeks or a month. It will get annoying otherwise. Will these blocks have
been recycled when I get them back for flushing, so the work was probably
useless?

Doing these exchanges I found a nice way to update not yet empty buffers
using checkpointfiles ("ckpoint"):
(I'm using the WIN32 client 432)
1. stop the client
2. rename buff-in.rc5 to ckpoint
3. copy the new buffer buff-in.rc5 into the client directory
4. restart the client
The remaining blocks will be "recovered" and pushed at the end of
buff-in.rc5, so they will be processed before any of the new blocks.

This might be optimized using a batchfile and the CLI client and some
command line parameters for the checkpointfile, I think.
Furthermore I use this once a week to process all the blocks in my incoming
buffer, so they won't get too old. I'm using lurking (lurkonly) and dial-up
access - this keeps the buffer usually filled and lets it never get really
empty. Because the buffers are stacks the first pushed blocks would wait
very long before being processed. After "recovering" the old buffer all old
blocks will be processed before a fetch occures.

This might be an idea for people who asked about using queues for the buffer
files on this list.
In my opinion queues will be more difficult to handle in files because when
appending/deleting at the beginning of a file you must completely rewrite it
instead of appending at the end/truncating when using a stack-file.


WOW! We got DES-III ! Congrats distributed.net!


Andreas

-----
CPU time is a terrible thing to waste!
Join the world's fastest computer - http://www.distributed.net - Team #11292

--
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