[RC5] Strange Mathematics ?!
Jim C. Nasby
jim at nasby.net
Wed Jan 20 15:03:36 EST 1999
The client is reporting the keyrate correctly. Due to the design of DES and our
clients, it is very easy for us to test complimentary keypairs instead of
individual keys. This means that a 2^28 block of keys actually results in 2^28
_pairs_ of keys being tested. You could say a 2^28 block actually contains 2^29
Another point of confusion a lot of people had was about the Deep Crack listings
on the proxy info page. Those listings were 'artifacts' of setting the master
up for talking to Deep Crack. There were no actual Deep Crack proxies, and you
could safely ignore those entries on the proxy info page. Of course, all of this
is a moot point now. :)
While I'm rambling on a bit, I just want to thank all of you, our users. Without
your efforts to upgrade to new clients and participate in the two DES tests,
this win simply wouldn't have been possible. Instead, thanks to your help with
the test contests, this is the smoothest DES contest we've run yet!
Thanks, and keep crackin!
On Wed, Jan 20, 1999 at 02:11:56AM +0100, Andreas Beckmann wrote:
> 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
> 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
> 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
> 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!
> 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
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5