Date: Wed, 24 Jan 2001 11:21:02 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: pherman@frenchfries.net, net@freebsd.org Subject: Re: I have delayed ACK problems Message-ID: <200101241721.f0OHL2627523@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-net/Pine.BSF.4.32.0101241334120.21262-100000@husten.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/Pine.BSF.4.32.0101241334120.21262-100000@husten.security.at12.de> you write: > >A question for the TCP stack gurus... > >We were testing a FreeBSD 4.1 client with a Solaris 7 Oracle server. >The FreeBSD client would take 10 times longer (60 sec) than a Linux >client (~6 sec.) to complete an *identical* request. Configuration, >client software and hardware problems have been ruled out. > >After comparing the tcpdump outputs, I found that the FreeBSD client >was sending quite a few ACKs exactly 100ms later. Ah, delayed acks. > > sysctl -w net.inet.tcp.delayed_ack=0 > >"solves" the problem (or reducing the delack_timeout gives a >corresponding performance win), and the FreeBSD client performs just >as well as the Linux box, but I don't like this solution. Here's an >example snippet from tcpdump where it trips up: >10:49:54.279497 16.1035 > 10.40438: . ack 19433 win 17520 (DF) >10:49:54.371025 16.1035 > 10.40438: . ack 21481 win 17520 (DF) Are you sure the trace has delayed ack turned off? The fact that the FreeBSD acks are about 100ms apart makes me think that the delayed ack mechanism is still running. >We could live with just turning off delacks (it serves data more often >than it receives), but I'd /really/ like to know what the problem is. >My gut feeling is, it's not delack's problem, but a symtom of >something else... > >This is a BIG performance hit in the default installation for FreeBSD, >and I'm sure it isn't a rare occurance (Database connections, X11, >etc. all do a little back & forth chat before a big file or pixmap is >transfered...) From the description above, it sounds like you are running into TCP's slow start effects. TCP will start slowly ramping up transmission to avoid overloading the network. Try bumping up net.inet.tcp.slowstart_flightsize, which specifies how many packets can be outstanding (unacked) at the beginning of a TCP connection. -- Jonathan 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?200101241721.f0OHL2627523>