From owner-freebsd-hackers Tue Jan 28 20:13:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA06642 for hackers-outgoing; Tue, 28 Jan 1997 20:13:58 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06637 for ; Tue, 28 Jan 1997 20:13:54 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id GAA27096; Wed, 29 Jan 1997 06:13:49 +0200 (EET) Date: Wed, 29 Jan 1997 06:13:49 +0200 (EET) Message-Id: <199701290413.GAA27096@silver.sms.fi> From: Petri Helenius To: "Louis A. Mamakos" Cc: dg@root.com, hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-Reply-To: <199701290339.WAA00536@whizzo.transsys.com> References: <199701281936.LAA16507@root.com> <199701290339.WAA00536@whizzo.transsys.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Louis A. Mamakos writes: > > > > 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()... > You'll switch your process context between the receiving and sending process once every window. If you would be windowing, you'll doing that less often. Additionally, that gives usually better performance since you have processes to schedule if you for example have to page something in. Pete