[plans] distributed.net .plan update

plans at nodezero.distributed.net plans at nodezero.distributed.net
Thu Jul 13 21:00:02 EDT 2000

distributed .plan updates in the last 24 hours: 

bwilson :: 13-Jul-2000 01:00 (Thursday) ::

Greetings, loyal cows!

If you've read bovine's .plan
you know we're experimenting with a larger minimum block size to see if
it will improve our network performance.  Our tests so far are encouraging
(about a 30% reduction in traffic, I believe), and we're discussing the
pros and cons of applying this change more widely, as well as some alternate

In the mean time, I thought I'd point out that using larger blocks not
only reduces network traffic (yours and ours) but will boost your key
rate, especially on faster machines.  The network and buffer management
components of the client take time away from the cores, just like every
other application on your computer.  If you fetch/flush after every block,
you have 32 times less network overhead with a 2^33 as with a 2^28.  It
takes just as long to submit a completed 2^33 as a 2^28, and it takes just
as long to connect and disconnect from the key servers, no matter how many
blocks are transferred in between.  We recommend you fetch/flush only once
or twice a day.  Your stats are based on the total work you submit, not
how often you submit it.

For example, a Mac G4 at 450MHz can do a 2^28 block in about 70 seconds.
If that machine was working only on 2^28 blocks, and updated after each
one, it would connect to our network over 1200 times a day.  This example
goes beyond mere carelessness and borders on abuse.

Larger blocks also mean less data to transfer from keymaster to tally,
and less data for tally to, um, tally each day.  Again, you still get the
same credit in stats whether you do 32 separate 2^28 blocks or 1 block of
2^33.  The difference is in the bandwidth dcti uses, and the overhead on
your computer.  The network bandwidth used by distributed.net (proxies,
keymaster, tally, website and ftp and e-mail lists like the .plan mailing)
is all donated - we're guests.  If we aren't polite guests, we could be
asked to leave.  Even if we don't upset anyone, we'd like to make the most
of the bandwidth we have.

When we first started RC5-56, we decided on blocks of 2^28 keys because
the fastest personal computer money could buy was a Pentium 133.  That
CPU could only do about 114,000 keys per second, which would finish a 2^28
block in about 40 minutes.  Some older CPU's may have a hard time completing
even a single 2^28 block in a 24 hour period.  I'm sure it's hard to feel
like any work is being done when it takes so long to see anything happen.

We certainly don't want to alienate these participants by forcing them to
work on blocks so large it doesn't finish for a month.  Unfortunately,
that could eventually be the case if the people with faster machines don't
voluntarily tune up their settings.  As Moore's Law
(http://www.tuxedo.org/~esr/jargon/html/entry/Moore's-Law.html) continues
to push technology forward, it's inevitable that we'll need to raise the
ceiling beyond blocks of 2^33.

The other extreme, saving blocks up for weeks or months for a "mega-flush"
can also be harmful to the network.  The sudden high volume of work
submitted all at once can saturate the proxies and the master.  A big
enough mega-flush could theoretically take more than one day to be processed
into stats (please, don't try!).

Though our biggest concern is the central network, these factors can also
improve performance between clients and personal proxies.  I hope this
information will help you adjust your distributed.net clients in a way
that helps us all be more successful.

As always, thanks for all the cycles!

moose :: 13-Jul-2000 01:10 (Thursday) ::

The following clients have been updated/added:

- QNX [Neutrino 2.x/x86]  v2.8010.463b

- OpenBSD [Sparc/aout]  v2.8010.463

- OpenBSD [x86/aout]  v2.8010.463

- NetBSD [1.4.x/1.5/x86]  v2.8010.463

- NetBSD [m68k]  v2.8010.463

- FreeBSD [ELF/x86]  v2.8010.463

- BSD/OS [4.x/x86/ELF]  v2.8010.463

- Linux [MIPS/ELF]  v2.8010.463

- Mac OS X [MACH2]  v2.8010.463

- Mac OS X [MACH3]  v2.8010.463

- PC-DOS, MS-DOS [x86]  v2.8010.463

- Windows 95/98/NT [x86/Zipped]  v2.8010.463

- Windows 95/98/NT [Alpha]  v2.8010.463

By Date: http://www.distributed.net/download/updates.html

By Sys: http://www.distributed.net/download/clients.html

Changes.txt: http://www.distributed.net/download/changes.txt


moose :: 13-Jul-2000 20:39 (Thursday) ::

The following clients have been updated/added:

- Linux [x86/ELF]  v2.8010.463

By Date: http://www.distributed.net/download/updates.html

By Sys: http://www.distributed.net/download/clients.html

Changes.txt: http://www.distributed.net/download/changes.txt


moose :: 13-Jul-2000 22:07 (Thursday) ::

Greetings cows of the world!

Earlier this year, distributed.net began integrating the Optimal Golomb
Rules project (http://www.distributed.net/ogr/) into its network. However,
some clients were returning inordinately large node counts for completed
stubs. When sharing buffer files between certain combinations of platforms,
buffers were becoming corrupted.

New clients have been built with this bug corrected, and we are now ready
to restart the OGR project. On Friday July 13, 2000 at 0000UTC, we will
restart from the beginning of OGR-24, using smaller work units that can
be turned around more quickly. When OGR-24 is complete we will move right
on to OGR-25 and so on.

Although OGR code has been present in the dnetc clients since version
v2.8002.446, no blocks will be accepted from versions prior to v2.8009.460.
We ask that you update your clients
(http://www.distributed.net/download/clients.html) to v2.8009.460 or
higher. These clients have been available for some time now and you should
take the time to upgrade as many systems as you can.

Even if you don't plan on participating in the OGR projects, you will want
to upgrade your clients because of major network and buffer-management
improvements. Check out the changes document
(http://www.distributed.net/download/changes.txt) for a complete listof

Stats have been completed for OGR and will be processed with the RC5 stats
run on the first day of the contest. For information on changes to stats
see http://n0cgi.distributed.net/~decibel/newstats.txt

decibel :: 13-Jul-2000 23:40 (Thursday) ::

For those of you running pproxies, please make sure that you deleted your
old OGR buffers from the last OGR project, which was suspended February
22nd. The pproxy will *not* automatically dump OGR work units from the
last time OGR was running.  The old buffers will contain much larger stubs
which take a long time to process. With how fast OGR moves, it is possible
that any old blocks would end up as dupes, meaning that work would be

Sorry for any inconvenience. }:8)

To unsubscribe, send 'unsubscribe plans' to majordomo at lists.distributed.net

More information about the plans mailing list