Re: What's the best configuration for this setup?

On Sat, 23 Nov 1996, Duane Wessels wrote:

> I think this brings up the most important point. Assuming some kind
> of rate-limiting feature is added to the code, it MUST implemented in
> a manner flexible enough to meet everyone's needs. If we hardcode
> "neighbours don't count towards this number" then two days after the
> release three people will want just the opposite (only neighbors count).

Definitely.
 
> Whoever started this thread (sorry I forgot!) claimed that a single
> (FTP?) transfer seemed to consume the entire link bandwidth. TCP is
> supposed to have this nice load-sharing algorithm, so its not clear to
> me how this could happen.

Well, a Netscape client will open 4 connections at once, so it could
cause burstiness and degradation of telnet quality.
 
> I think the first thing to try would be lowering the TCP receive buffer
> size ('tcp_recv_bufsize', squid-1.1).

I think the discussion on the Freebsd-hackers list started off with "I've
just reduced tcp_recv_bufsize to try to reduce the available b/w to this
program; why doesn't it work??".

The conclusion was that if the limiter is application, rather than kernel
or router, based, then the application must make a point of not reading
more than n bytes/sec, on average. The simple example cited was just for
a single-threaded program which can sleep(). Squid can't sleep(), so I
think that the way to do this would be to schedule the next read()
according to the number of bytes just read. A granularity of 1 sec is
probably a bit coarse, but gettimeofday() will return the time of day in
secs and msecs, so a granularity of 0.1 sec should be achievable with
reasonable accuracy, which will smooth out the reads and make the actual
read b/w closer to the configured b/w.

One thing I'm not sure about is how to limit the aggregate b/w of all
connections opened by a single client, other than have a table of clients
for the b/w timers, rather than remembering stuff for the current connection.

Danny
Received on Sat Nov 23 1996 - 22:20:47 MST