From owner-freebsd-net Sun Mar 5 14:13:49 2000 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 0A03037B853 for ; Sun, 5 Mar 2000 14:13:47 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id QAA88902; Sun, 5 Mar 2000 16:16:38 -0600 (CST) (envelope-from jlemon) Date: Sun, 5 Mar 2000 16:16:38 -0600 From: Jonathan Lemon To: =?iso-8859-1?Q?R=E9mi_Guyomarch?= Cc: freebsd-net@FreeBSD.ORG, Jonathan Lemon , jayanth Subject: Re: TCP performance problems, Linux faster than FreeBSD ? Message-ID: <20000305161638.A85421@prism.flugsvamp.com> References: <20000303165052.C23732@pingoo.ifn.fr> <20000305193317.B22005@pingoo.ifn.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000305193317.B22005@pingoo.ifn.fr> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Mar 05, 2000 at 07:33:17PM +0100, Rémi Guyomarch wrote: > So, Linux use the time of the last non-acked packet as a starting > point for the 200ms timer, but *BSD stacks use a fixed 'clock'. > This is completely different ! > > I put an ugly hack in sys/netinet/tcp_timer.c to try to fix the > problem. And now I'm getting **way** less duplicate packets. Hm, yes. That's the way it works -- BSD uses a fixed clock with a maximum delay of 200ms and a statistical average of 100ms. You may want to try upgrading to 4.0 (about to be released shortly). Not only does it change the timer behavior to a per-packet (instead of global basis) but it allows you to tweak the delayed-ACK time via sysctl. E.g.: net.inet.tcp.delacktime: 100 > It's not very clear to me why sending fewer acks eliminates the > duplicate packet problem. Maybe my 64k leased line isn't really > full-duplex (it's physically made of two wires, so it can't be really > full-duplex anyway). So sending an ack while a packet is received > cause some problems and some of my acks are lost in the process. I can't tell from the traces that I have. It seems that the server has a completely broken fast-recovery algorithm, but it's not always triggered. My guess is that it may be sensitive to the timing of the ACKs being returned, as these are used to caculate the RTO. Perhaps Linux (with less ACK `jitter') simply interacts more favorably with the server's timeouts by returning the ACKs when they are expected. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message