From owner-freebsd-hackers Tue Jan 28 19:39:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA05021 for hackers-outgoing; Tue, 28 Jan 1997 19:39:40 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05015 for ; Tue, 28 Jan 1997 19:39:34 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id WAA00536; Tue, 28 Jan 1997 22:39:08 -0500 (EST) Message-Id: <199701290339.WAA00536@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: dg@root.com cc: Petri Helenius , hal@vailsys.com, hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: best mtu for lo0? References: <199701281936.LAA16507@root.com> In-reply-to: Your message of "Tue, 28 Jan 1997 11:36:05 PST." <199701281936.LAA16507@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 22:39:08 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Petri Helenius wrote: > > > > > > > What's your lo0 MTU? If it's the 16384 that some > > > > non-tcp-knowledgeable person put in sometime in the past > > > > I think what you are seeing is called "TCP deadlock" which appears when > > > > window size is equal or smaller than the MTU. This makes TCP to be > ... > > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > > > this be reduced to 1500? Will it affect performance of aliased IP > > > addresses, for which a static route through lo0 is usually specified? > > > >Want me to comment on this (I'm not on the hackers list any longer > >though)? > > > >The above still stands true that if you set your TCPWIN < MTU you'll > >experience TCP 'deadlock' which ends up being of horrible performance. > > Pete is likely correct that window < MTU is a problem (that's obvious, > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. Even on other systems which don't have this optimization, what's the big harm in running stop-and-wait on the loopback interface? It's not as if there are queues in the networks which you can fill and signficant propagation delays. I don't recall exactly how the queuing is done these days and how ipintr() is invoked, but I'll bet that before the loopback output function returns, there's a software interrupt invoked to process the packet just queued up for ip_input()... louie