From owner-freebsd-hackers Wed Apr 3 21:56:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA29420 for hackers-outgoing; Wed, 3 Apr 1996 21:56:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA29415 for ; Wed, 3 Apr 1996 21:56:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA21019; Wed, 3 Apr 1996 22:50:22 -0700 From: Terry Lambert Message-Id: <199604040550.WAA21019@phaeton.artisoft.com> Subject: Re: Freebsd Vs. Linux To: dennis@etinc.com (dennis) Date: Wed, 3 Apr 1996 22:50:22 -0700 (MST) Cc: hasty@rah.star-gate.com, tjeffers@nastg.gsfc.nasa.gov, hackers@FreeBSD.org In-Reply-To: <199604040039.TAA06690@etinc.com> from "dennis" at Apr 3, 96 07:39:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> We are in the midst of a development project which uses alot of UDP > >> and serial communications. > >> > >> Although our preference had been to use FreeBSD, the UDP > >> performance was terrible (200 Kbps over Ethernet), and we > >> kept getting ENOBUF errors which makes FreeBSD an unacceptable choice. > >> Our previous posts for possible parameters to tune didn't > >> turn up anything helpful, and messages to freebsd.org haven't been > >> answered yet. > >> > >> The TCP performance was the same for both Linux and FreeBSD, and UDP > >> testing on all other platforms in our facility proved okay for Solaris, > >> SunOS, & SCO. > >> > >> Is there anything we can do to improve the UDP performance of FreeBSD? > >> Why does it care about buffering for UDP? Please respond via email > >> to tjeffers@nastg.gsfc.nasa.gov. Thanks. I think this was answered already by one of the networking guru's, but in case you missed it... You can increase the buffer space to get rid of the ENOBUF errors, but they are really "backoff and retransmit warnings". The other OS's you tested are probably silenty dropping the packets. Since it's a warning, you can ignore it (there ought to be an option to cause it to silently drop packets like other OS's, settable via sysctl). This is actually a necessary thing for implementing Frame Relay and ATM source quench up to the application layer. As more systems support these transports (and IPv6), applications will be required to handle backoff, or kernels will be required to backoff in a protocol dependent handler in the kernel itself... probably by delaying return from the sending system call. This is only a stopgap soloution, since threaded applications could reenter the kernel -- eventually application will have to Deal With It(tm). Are these broadcasts? If you are broadcasting on a SIMPLEX interface, you have to do extra work because the card can't see its own broadcasts. If your TCP performance were that bad, I would suggest that the card was misconfigured; since it's only the UDP, I question the validity of the figures on the other systems based on silent drops. Have you compared detailed netstat's yet? Since you don't go into detail on your network topology, you may or may not benefit by disabling the RFC 1323 and RFC 1644 extensions. You can do this by changing: tcp_extensions=YES to tcp_extensions=NO in the file /etc/sysconfig, and rebooting your machine. This will also help PPP header compression because of the transation timestamp being included as a "header change" when calculating compressability. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.