[RC5] keys stuck in a loop??

Bruce Wilson bwilson at distributed.net
Mon Sep 17 12:10:08 EDT 2001

The general guideline is "the larger the better," though there are
several legitimate reasons you may not want to request the max size.

*  A computer that crashes frequently, which raises the likelihood of
losing work.

*  Very slow platforms where even a 1*2^28 takes a long time.  (Anybody
still using a 386/16?)

*  Ensuring that at least one work unit is completed each day.

The small work units are really there only for those people who need
them (and because it would be too complicated to eliminate them this
late in the project).

Since each computer is different, we don't really have a standard
suggestion for a given CPU.  The page at
http://www.distributed.net/speeds may be helpful, but a full benchmark
is probably your best bet.  Try to arrange your computers so they only
need to check in for work a couple of times a day.

As you pointed out, your proxy is helping to minimize the network
traffic by communicating with the proxies less frequently, but working
on 1*2^28's is making those transmissions "fatter", because a 1*2^28
takes just as much room as a 32*2^28.  This means that your
communication with our servers is 32 times as big as it would be if you
worked exclusively on 32's.  That is truly network bandwidth - only the
handshaking and overhead is really "saved" by the proxy.

I think I heard once that the perproxies can consolidate adjacent work
units in some cases, but that would be dependent on the work units
adding up to a work unit that could have been handed out by the server.
E.G. you could combine parts 0 and 1 or parts 2 and 3 into a 2* unit,
but you couldn't combine 1 and 2 into a 2*, because the keyserver
wouldn't hand out work units aligned like that.  The work to be
consolidated would obviously have to be completed by the same
participant to be consolidated.  Perhaps someone else from d.net can
clarify this point.  For my example, I'm going to continue to assume
that, for one reason or another, the proxies cannot consolidate the

After the fullproxy receives it, those 32 packets must then be
transferred to the keymaster, another network bandwidth question.  The
keymaster has to mark 32 individual units finished instead of 1.  The
logs from the keymaster are then sent to the stats server (more network
bandwidth).  Only at this point is the work of each participant
summarized down to a single total for the day.

Finally, the logs from the keymaster are also burned on CDs.  With 32
times as many log entries, we would go through CD's faster with 1's than
with 32's.

Incidentally, this network traffic is also part of the reason we have
chosen to go with longer work units for OGR.  We are very comfortable
with work units that take several days to complete.  Most participating
computers are very stable, and fairly fast.  We try to set the defaults
to values that will make good use of moderately fast computers without
unduly punishing those with older hardware.

Bruce Wilson <bwilson at distributed.net>
PGP KeyID: 5430B995, http://www.toomuchblue.com/ 

"Quidquid latine dictum sit, altum viditur."
(Whatever is said in Latin sounds profound.) 

| -----Original Message-----
| From: owner-rc5 at lists.distributed.net 
| [mailto:owner-rc5 at lists.distributed.net] On Behalf Of waldo kitty
| Sent: Sunday, September 16, 2001 14:49
| To: rc5 at lists.distributed.net
| Subject: Re: [RC5] keys stuck in a loop??
| ahhhh... see? no one's ever explained it like that... i surely didn't
| get that from mike's message... he seemed to simply be berating me for
| processing small block and returning them ASAP... in all the years my
| machines been participating in the RC5 project and my carrying of and
| reading this list, the term "bandwidth" has been used and to a lot of
| us, that speaks of the pipeline that the data travels over rather than
| the computing power needed to process the data available...
| so, are there recomendations or a chart for block/unit sizes 
| that should
| be being worked on for the different available CPUs?? i've 485/50's,
| 486/66's, 5x86/133's, P200 no MMX's, P233MMX's, P266MMX's, 
| AMD K6-450's,
| and Celeron 300's... there may even be a 486/25 or two in the mix...
| Bjoern Martin wrote:
| > 
| > Hi there.
| > 
| > [...]
| > 
| > > > How utterly selfish. Never mind the excessive load
| > > > you're placing on distributed.net - as long as you have
| > > > a nice pretty graph and don't have to do any maths
| > > > yourself, that's all you care about?
| > >
| > >show some proof that i am creating any excessive load...
| > >dnet has so much traffic hitting them all the time that
| > >my stuff is miniscule at best... [...]
| > 
| > Mike's not talking about webserver load, but the nightly
| > stats update load. The master key server needs to do one
| > 'calculation' (whatever) for each package. In your case
| > it's 1 block per package. In my case it's 32 blocks per
| > package. So the load of the server you produce is 32 times
| > higher than the load I produce, regarding the same amount
| > of blocks. That's a reason why the stats take up to 12:00
| > CEST (11:00 GMT) until they are finished.
| > 
| > Bye,
| > 
| > Boris59
| > 
| > --
| > boris59 at gmx.net -> PGP mails welcome, public key on request
| > Member of RC5-64 effort by www.distributed.net - team #6941
| > 
| > --
| > To unsubscribe, send 'unsubscribe rc5' to 
| majordomo at lists.distributed.net
| > rc5-digest subscribers replace rc5 with rc5-digest
| -- 
|        _\/
|       (@@)                      Waldo Kitty, Waldo's Place USA
| __ooO_( )_Ooo_____________________ telnet://bbs.wpusa.dynip.com
| _|_____|_____|_____|_____|_____|_____ http://www.wpusa.dynip.com
| ____|_____|_____|_____|_____|_____|_____ ftp://ftp.wpusa.dynip.com
| _|_Eat_SPAM_to_email_me!_YUM!__|_____|_____ wkitty42 (at) alltel.net
| --
| 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 mailing list