[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 . . .)

-Zorba

----- 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
> can.
>
> 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 mailing list