Date: Fri, 12 Nov 1999 15:35:00 +0100 (CET) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: aron@cs.rice.edu (Mohit Aron) Cc: freebsd-net@FreeBSD.ORG, wollman@FreeBSD.ORG, jlemon@FreeBSD.ORG, julian@FreeBSD.ORG, ee@FreeBSD.ORG, bright@wintelcom.net Subject: Re: FreeBSD networking problems Message-ID: <199911121435.PAA05210@info.iet.unipi.it> In-Reply-To: <199911102211.QAA12891@cs.rice.edu> from Mohit Aron at "Nov 10, 1999 4:11:49 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
To respond to some interesting points: > I've noticed several problems in networking performance in FreeBSD wrt > WAN conditions in the course of my experiments. I mailed them to Alfred ... > Problems with WAN emulation in lab environments: > > 1) FreeBSD tries to determine the max size of socket buffers from cached related issue -- kern.ipc.maxsockbuf can also be a source of problem. It bounds the gross amount of buffer space used by a socket -- this means if you allocate a 2KB cluster and only use it to hold a small packet (e.g. 512 bytes) your gross amount of buffer space is charged the full 2KB and the kern.ipc.maxsockbuf limit might hit before net.inet.tcp.sendspace (or however you override it with the setsockopt() calls) > 5) The interface queues need to be increased from the default of 50 packets > (defined as IFQ_MAXLEN in sys/net/if.h). I normally increase this value to > 1000. A busy webserver can easily overflow the default of 50. i think the two of us already discussed this. I don't think this is a particularly good idea, especially: > 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. If a packet is held in the device driver queue, it means that the device is temporarily unable to transmit for some time, this is a local problem, and the driver itself should immediately report a failure upstream (e.g. in ip_output(), i think this is already implemented by checking IF_QFULL The 833 pkts you mention do need to be stored somewhere, but this is in the socket buffer, not on the device queue. > change to the fxp driver (in sys/pci/if_fxp.c) where it ignores the > IFQ_MAXLEN setting for the output driver queue and instead sets it to the > number of its own transmit buffers (127 by default). I think this feature > should be removed - the older FreeBSD-2.2.x used to only put more pkts (> agreed -- probably, at least if you want to use ALTQ or other forms of active queue management, this is an annoying feature. > 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. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911121435.PAA05210>