[RC5] work unit rotation
Robert A. Rosenberg
dnet at rarpsl.com
Fri Sep 7 23:27:07 EDT 2012
At 23:12 +0100 on 09/05/2012, Mike Reed wrote about Re: [RC5] work
>What is wrong with letting the client handle the buffers?
Nothing if you let the buffers flush and refresh. This will insure
that all the blocks get processed before you get new blocks. The
stated scenario however does not insure that you process all the
blocks before adding more. If newly added blocks can get processed
before ones that were there before they were added, then in theory
you can keep adding blocks that jump to the top of the queue and thus
prevent older blocks from ever getting selected. I am NOT saying that
this can occur and that the queue is not processed FIFO. My suggested
method just insures that all blocks are processed and some do not get
stalled due to newly added blocks.
>On Sep 5, 2012 8:43 PM, "Robert A. Rosenberg"
><<mailto:dnet at rarpsl.com>dnet at rarpsl.com> wrote:
>At 08:38 -0700 on 09/05/2012, jp68 wrote about [RC5] work unit rotation:
>>What I'm wondering is if there is any work unit date/age selection
>>that the oldest work units in the buff-in file would be completed before
>>newer ones were??
>While I can not answer your question, if your intent is to insure
>that old units are processed before new ones, you can do this by
>setting your running client to flush its work into a 2nd set of
>buffers as well as refresh from the 2nd set of buffers. By keeping
>the number of work units low it will periodically flush and refresh.
>The 2nd set of buffers are controlled by a 2nd client you just launch
>to do the -import (and you just copy the completed work to your flash
>drive and delete the file). This will cause the refresh to get the
>rc5 mailing list
><mailto:rc5 at lists.distributed.net>rc5 at lists.distributed.net
>rc5 mailing list
>rc5 at lists.distributed.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rc5