Date: Wed, 3 Apr 1996 22:50:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: hasty@rah.star-gate.com, tjeffers@nastg.gsfc.nasa.gov, hackers@FreeBSD.org Subject: Re: Freebsd Vs. Linux Message-ID: <199604040550.WAA21019@phaeton.artisoft.com> In-Reply-To: <199604040039.TAA06690@etinc.com> from "dennis" at Apr 3, 96 07:39:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604040550.WAA21019>