davidt at xfiles.nildram.co.uk
Mon Jul 20 01:21:52 EDT 1998
On Sun, 19 Jul 1998, Ryan Schmidt wrote:
> >I believe the real fix is to express buffer sizes in equivalent numbers
> >of 2^28 blocks, so that the total workload for a buffer of size N is
> >constant, regardless of whether the blocks are 2^31 or 2^28 or
> >something inbetween. That way, if I say "buffer 200 blocks, preferring
> >2^31 blocks", I could either get 200 2^28 blocks or 25 2^31 blocks or
> >some combination in between. You will still keep the block-size
> >preference setting so that you could place an upper bound on the
> >granularity of work attempted at any given time.
> I second this. It would make life easier to be able to exactly know how many
> keys I've gotten, rather than just knowing how many variably-sized blocks.
> It might be further useful to have the client be able to split large blocks into
> smaller blocks. This way, a client computer can put the least load on the
> distributed network while still performing a unit of work appropriate to its
> processing power.
I agree with the buffer exactly n 2^x blocks, but it doesnt matter if
there are n 2^x blocks, or n*2 2^(x-1) blocks, but I don't really see
the purpose of the preferedblocksize setting at all. Why not just
ignore it and use 31, and download whatever blocks are available.
I just don't see what the purpose of doing a 'unit of work appropriate
to its computing power' is, if you are going to download the same
amount of blocks. It makes no difference how the computer breaks them
up, it does exactly the same amount of work (except, maybe if there are
more smaller sized blocks, there is a bit more overhead processing the
I may be missing something here, but I honestly don't get the point of
having a preferedblocksize entry...
dtaylor at nildram.co.uk
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5