[RC5] dnet's servers won't give out big blocks
Zorba the Hutt
zorbathut at uswest.net
Tue Sep 25 00:29:09 EDT 2001
Isn't there any way to fix this? Say, have the servers keep lists of blocks
of different sizes - if the user requests a 2^33 block, send 'em one, and if
they request a 2^28 block and there aren't any, break a 2^33 block and add
all the little pieces to the 2^28 block list.
I don't know enough about how the system is coded to know how you'd do this
efficiently, but it might be worth a little CPU time just for the network
traffic drop and stats speedup.
(Alternatively, clean up a few of the old subspaces to create dedicated
blocksize subspaces, that are guaranteed to never fragment below a certain
level . . .)
----- Original Message -----
From: "Bruce Wilson" <bwilson at distributed.net>
To: <rc5 at lists.distributed.net>
Sent: Sunday, September 23, 2001 10:30 PM
Subject: RE: [RC5] dnet's servers won't give out big blocks
> It's also frustrating to us not to be able to give out those big blocks.
> This is another side effect of those people who insist on using 1*2^28
> blocks instead of a more appropriate size. Random workunits (which are
> always 1*2^28) also contribute to this problem.
> Unfortunately, the damage is done for all the blocks we've handed out in
> the past. We have talked about distributing a 32 or 64 block even if it
> had one or two 1's completed, but I don't have a clue whether that is in
> effect or still on the drawing board.
> We have also kicked around the idea of not handing out 1's anymore at
> all, answering those requests with a 2 or 4. This would help stem the
> problem, but at the expense of punishing those with older computers.
> We'd rather have participants use the proper settings, so we don't have
> to force them to do the right thing. If the problem becomes big enough,
> we'll do what we have to to make the network run as efficiently as we
> If you have configured the client to use a time-based threshold, this
> phenomenon won't affect the amount of work you retrieve. If dnetc has
> to download twice as many work units to fill the projected amount of
> time, it will.
> Bruce Wilson <bwilson at distributed.net>
> PGP KeyID: 5430B995, http://www.toomuchblue.com/
> "Quidquid latine dictum sit, altum viditur."
> (Whatever is said in Latin sounds profound.)
> | -----Original Message-----
> | With all the recent conversations about reducing server load
> | and such, I
> | thought I'd share part of my pproxy's log. It shows my
> | pproxy trying to
> | get a 64-statunit block from one of the main servers. About half the
> | time, it seems the dnet servers will give out a 64-statunit
> | block. But
> | the other half of the time I get tons of dregs. I've got most of my
> | clients so that they work on blocks between 8 and 32 statunits. If my
> | pproxy can't get a big block, it certainly can't hand a big
> | block out to
> | those clients. It's frustrating to have done everything I can to help
> | efficiency to be undermined this way.
> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5