From owner-freebsd-net Wed Jan 24 9:21:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 996AB37B400 for ; Wed, 24 Jan 2001 09:21:22 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0OHL2627523; Wed, 24 Jan 2001 11:21:02 -0600 (CST) (envelope-from jlemon) Date: Wed, 24 Jan 2001 11:21:02 -0600 (CST) From: Jonathan Lemon Message-Id: <200101241721.f0OHL2627523@prism.flugsvamp.com> To: pherman@frenchfries.net, net@freebsd.org Subject: Re: I have delayed ACK problems X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article 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