[plans] distributed.net .plan update

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

distributed .plan updates in the last 24 hours: 

bovine :: 06-Jul-2000 06:53 (Thursday) ::

I just thought I'd let everyone know that we're currently experimenting
with enforcing a minimum block-size for RC5.  This means that even if you
have your clients configured to request 2^28 blocks, you will likely get
a larger sized block instead.  As we are being faced with an ever increasing
amount of network traffic caused by our phenomenal growth, we would like
to explore the impact cause by allowing smaller sized blocks to be
explicitly requested by clients.

So far, we have found that an extraordinary number of people configure
their clients to request small 2^28 sized blocks, even though their
processors are more than adequately fast enough that packets are completed
frequently enough that there is no legitimate need for those specific
machines to configured to request such small blocks.  Although allowing
your client to process smaller blocks has the visual appearance of seeming
to complete work packets more rapidly, it does place an increased burden
upon the donated network resources of our servers, in addition to increasing
the daily processing overhead required by our stats server.  It additionally
contributes towards keyspace fragmentation at a greater rate than larger
blocks do.

Therefore we'd like to request that everyone evaluate their client
configurations and check whether they've configured their client to
specifically request small 2^28 sized blocks and think about whether you
really need to request blocks that small.  If your machine completes a
2^28 sized block in less than 45 minutes, than your computer is fast enough
that it really should be processing larger blocks.

The ability to request small blocks should really be reserved for unstable,
slower machines that might have greater potential of crashing before
completing an entire packet.  Additionally, those slower machines should
definitely consider enabling checkpointing, to allow blocks that are lost
in the middle of processing to be resumed.  Note that clients that use
network shared ini's and buffers need to use distinct checkpoint files,
so you should use caution if you administer machines in that manner.

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

More information about the plans mailing list