From owner-freebsd-net  Fri Nov 12  8:42:24 1999
Delivered-To: freebsd-net@freebsd.org
Received: from cs.rice.edu (cs.rice.edu [128.42.1.30])
	by hub.freebsd.org (Postfix) with ESMTP
	id 13A0214D57; Fri, 12 Nov 1999 08:42:11 -0800 (PST)
	(envelope-from aron@cs.rice.edu)
Received: (from aron@localhost)
	by cs.rice.edu (8.9.0/8.9.0) id KAA29642;
	Fri, 12 Nov 1999 10:42:07 -0600 (CST)
From: Mohit Aron <aron@cs.rice.edu>
Message-Id: <199911121642.KAA29642@cs.rice.edu>
Subject: Re: FreeBSD networking problems
To: luigi@info.iet.unipi.it (Luigi Rizzo)
Date: Fri, 12 Nov 1999 10:42:07 -0600 (CST)
Cc: freebsd-net@freebsd.org, wollman@freebsd.org, jlemon@freebsd.org,
	julian@freebsd.org, bright@wintelcom.net
In-Reply-To: <199911121435.PAA05210@info.iet.unipi.it> from "Luigi Rizzo" at Nov 12, 99 03:35:00 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org



> i think the two of us already discussed this. I don't think this is a
> particularly good idea, especially:
> 

Well, 50 is too small. I needed 1000 for my WAN experiments, but the number
should be increased nevertheless. It overflows even in my regular tests with
the apache server. I think we agreed earlier that some testing might be 
needed to determine what the increment should be.


> >  It is also important for my lab tests with WAN conditions (although this is
> >  not a case for increasing it in the general FreeBSD distribution). Consider
> >  a 100Mbps link with a round-trip delay of 100ms. It can hold upto 833
> >  packets. In a lab environment, these can be queued up in the driver and thus
> 
> the RTT has nothing to do with the device driver queue.
> 

As you said, the 833 packets need to be stored somewhere and you're also 
right that the place is the socket buffer queue. But TCP can be bursty 
during its operating specially when it gets big ACKs (or closely spaced ACKs
that don't allow enough time to execute application code that can put more
data in the socket buffers - see the paper 
http://www.cs.rice.edu/~aron/papers/soft-timers.ps.gz). This means
occasionally, TCP would send a burst and there will be temporary queuing needed
in the drivers. In one of my experiments, slow-start was turned off and thus
there was a burst even in the first round-trip - driver queuing was needed
here.


> > 6) The value of SB_MAX (defined in sys/sys/socketvar.h) needs to be
> >    increased from the default of 256K. In my WAN experiments, the 
> 
> this is controlled by sysctl kern.ipc.maxsockbuf -- so easily customizable
> that you don't really need to change the source.

Well, I'm asking for the default to be increased. People who know enough
about FreeBSD can anyway tune it up. The default is useful for those who 
don't know much about FreeBSD or tuning it for networking.



- Mohit


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message