[RC5] Wheres the blocks?

Jim C. Nasby jim at nasby.net
Mon Jan 11 00:36:11 EST 1999


You are correct, trying to get the client to confirm a blocks status before
checking it would take up far too much bandwidth, and it would also completely
overcome the whole purpose of buffering blocks. The only solution is to keep
your DES buffers small; as small as possible. It would be better to have
clients process a few RC5 blocks durring the contest rather than download a
large amount of DES blocks that it would take a day to finish.

Moo!
dB!

jmv16 at cornell.edu wrote:

> On Fri, 8 Jan 1999, Eric Gindrup wrote:
>
> >
> >      Recycling is not a bad thing.  Suppose there were one block and a
> >      bunch of clients.  The fastest way to get that block done is to
> >      assign it to all the clients.  The first client to report it back
> >      "wins".  The same is true if there are more than one block.
> >
> >      The trouble is reassigning blocks when there are unassigned blocks
> >      left.  Then duplicated work is definitely wasted.  The dupe work
> >      would have been more profitably used to crack untouched blocks.
>
> Is there any way we can get the clients to do a "Is this block already
> completed?" check on all the blocks in the buffer every time they
> connect?  That would at least somewhat alleviate the problems caused by
> people with big input buffers having to do work that may have already
> been redistributed and completed.
>
> Unfortunately, I expect that would cause too much traffic though.  I only
> see one similar but less bandwidth-comsuming option:  to have the client
> attempt the above status-check (only if a connection is available,
> obviously) on the block it is about to begin processing.  The trouble is
> that a client which is always online should have a very small buffer to
> begin with and thus doesn't gain from the above plan.  And a machine that
> is only going to get one communication with the server to download a whole
> bunch of blocks before going offline until the next update doesn't benefit
> either, since it can't get at the server to verify the status of anything
> while offline.  So the only thing that the second plan really does is help
> people who expect intermitant connections (for example, a laptop that
> might be connected to the network all evening but in mobile use during the
> day) and don't want the hassle of increasing buffer size just before going
> offline.
>
> --
> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest

--
Jim C. Nasby (aka Decibel!)                                  /^\
jim at nasby.net                                               /___\
Freelance lighting designer and database developer         /  |  \
Member: Triangle Fraternity, Sports Car Club of America   /___|___\

Give your computer some brain-candy! http://www.distributed.net Team #1828


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