From owner-freebsd-hackers Thu Apr 4 07:39:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA03962 for hackers-outgoing; Thu, 4 Apr 1996 07:39:28 -0800 (PST) Received: from etinc.com (etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA03950 for ; Thu, 4 Apr 1996 07:39:16 -0800 (PST) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.6.12/8.6.9) with SMTP id KAA08041; Thu, 4 Apr 1996 10:41:57 -0500 Date: Thu, 4 Apr 1996 10:41:57 -0500 Message-Id: <199604041541.KAA08041@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: dennis@etinc.com (dennis) Subject: Re: Freebsd Vs. Linux Cc: tjeffers@nastg.gsfc.nasa.gov, hackers@freebsd.org 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. or queueing endlessly . There are good reasons to limit queue space, and if you overflow this with a non-realistic test then you havent learned very little. These can be tuned, I believe, as well. I think IFQ_MAXLEN is 50, which is really too small for an ethernet link (note that I think it is 300 in LINUX), particularly if the traffic is largely small packets that are being pummelled onto the line. You may try tuning this value (in /usr/src/sys/net/if.h) and see what happens. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD and LINUX