[RC5] Re: rc5-digest V1 #253

Jim C. Nasby jim at nasby.net
Mon Jan 11 22:01:13 EST 1999

Unless you have a pretty crappy internet connection (crappy in terms of
reliability), there's really no reason to keep a huge number of blocks in a
pproxy. All you need is enough blocks to handle any transient high traffic
periods. I would venture that 1-2 blocks per client would be sufficient.

If you do have a connection that goes down from time to time, then you'll have
to decide how long you want the pproxy to be able to supply blocks without an
external connection. This will be different for different situations. For
example, I'm on a dialup, so I tend to buffer enough for a day or two. Plus, I
sometimes run stuff offline, using 1000 block buffers. So, I finally decided on
a 2000 block RC5 buffer. I do not want stale DES blocks though, so I'm only
buffering a few hundred (less than 1/2 days worth).

So, there's no easy way for the pproxy to decide what a 'good buffer size' is.
To be honest, we generally assume that anyone who's running a pproxy wouldn't
have any problem with calculating how many blocks they want, or how long they
want their pproxy to last before running out of blocks if it loses it's

Clients are a bit of a different story. If you'll note, the current clients will
tell you how many blocks they'll do a day when you benchmark them (the Win32 CLI
will anyway...) Unfortunatly, the clients run in all kinds of different
environments as well, so it's difficult to automate buffer size selection for
them also. It is easier than for the pproxy though, so maybe that will
eventually become a feature.


Twilight wrote:

> Ok, I'm going to explain my setup which I think is pretty common (correct me
> if I'm wrong ;-) to explain why I suggest such things.
> I have two personal proxy's (v280 hehe, no crashes here) setup on two
> different LAN's supporting about 50 clients each on a full time connection
> to the internet. I use Remote cows to install them, and when new clients
> come out, copy the updates to the hard drive manually later on after
> shutting down the service (which BTW is a gruelling process.)
> I don't have spare time to analyse logs and do the math to work out how many
> RC5 and more importantly DES blocks to cache on the proxy, so I guess ;-) I
> certainly don't go around updating .ini files on all the PCs.
> I though that the RC5 rate would give the proxy _enough_ of a _guess_ of the
> computing power it's supporting to pull down  enough DES blocks to support
> it's clients without overbuffering too much. (more chance than I would have
> of guessing anyway.) We wouldn't get people buffering 10,000 des blocks then
> anyway.
> I would be all in favour of a "smarter" proxy, or even a setting for the
> clients to let distributed automatically change setting on the clients for
> things like blocks to buffer for certain competitions etc. The client
> already knows if its online all the time, or lurking etc, so we could say
> stick to what ya setting are UNLESS you are online all the time then buffer
> x.
> I saw from the DES-TEST that 1) We were recycling blocks at what appeared to
> early a stage (to many clients buffering to many blocks?) 2) slower clients
> didn't have the chance to get smaller blocks. 3)Clients were returning
> completed blocks too slowly.
> I think the above would help all these problems. I'm still new to
> distributed net, so please excuse any dumb ideas, I just feel at the end of
> the day, if you want people to play the game, don't make it harder than need
> be. Set it and forget it.
> Regards,
> Tyler
> On Mon, 11 Jan 1999, Twilight wrote:
> >
> > What I was meant was that the personal proxy should track how many RC5
> > blocks it's clients cracks a day and use that as a basis for how many
> blocks
> > it needs to grab for the DES contest.
> DES speed is not directly proportional to RC5 speed.
> > If we got really tricky we could also grab information on how long the
> > client has to process the blocks so when the client connects to the proxy
> it
> > only grabs enough blocks which is can crack in a certain time. This would
> > reduce the amount of redundant work being done and speed up the return of
> > blocks meaning we are more powerful and quicker. (if that makes sense.)
> Many people do not know in advance how long they will be off-line.
> I think it is pointless attempting to limit the number of blocks clients
> can store in their buffers - there are too many variables:
>         1. Dial Up userss.
>         2. Network Outage.
>         3. Computer being turned off.
> And I'm sure I could think of more.
> David Taylor
> E-Mail: dtaylor at nildram.co.uk.spam
> ICQ:    268004
> [Remove .spam from e-mail to reply]
> --
> 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

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