From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Nagle algorithm From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-cxwcnjqqwlhfwibcjrobwyzxfc" Message-Id: <20011122132413.0BE83199E7@mail.cse.psu.edu> Date: Thu, 22 Nov 2001 13:24:08 +0000 Topicbox-Message-UUID: 2796b8e8-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-cxwcnjqqwlhfwibcjrobwyzxfc Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit i think it's fundamentally misconceived and should at least never be on by default. dhog's description was ``[it] attempts to buffer up multiple writes and send them as a single TCP packet -- where the writes are small''. what that actually means is that if the writes are small it typically delays sending out anything at all (subject to certain specific conditions) until a given interval has elapsed or its idea of enough data has arrived, and that interval can be large. in other words, give it a few bytes you wish to send now and it demands more, delaying if that demand is not met. it's not just RPC that's affected. i claim it's not the TCP/IP subsystem's responsibility to delay sending something so that it can buffer up writes to make larger packets. that's for stdio or bio (or local OS equivalent). (an interesting variant was in a version of the Unix streams subsystem where there was a buffering module that could be pushed onto a tcp/ip stream.) it's fine for TCP/IP to adapt to the network and adjust the rate at which bytes are shuffled in and out, and adapt retransmission efforts to apparent error rates, and since TCP/IP doesn't preserve delimiters coalesce new data (from writes large or small) into already queued data to make larger output packets. those are all within its responsibility, i think, and any delays that result are arguably inherent in the network. if applications are stuttering bytes needlessly, deal with it there. --upas-cxwcnjqqwlhfwibcjrobwyzxfc Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-1.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1006423977:10:10994:14; Thu, 22 Nov 2001 10:12:57 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1109682; 22 Nov 2001 10:12 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 48A8019AA0; Thu, 22 Nov 2001 05:12:41 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5382319A91 for <9fans@cse.psu.edu>; Thu, 22 Nov 2001 05:10:13 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 166qbm-0004QW-00 for 9fans@cse.psu.edu; Thu, 22 Nov 2001 09:57:26 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Message-ID: <87itc31syv.fsf@becket.becket.net> Organization: University of California, Irvine Content-Type: text/plain; charset=us-ascii References: <20011121233823.814D7199E7@mail.cse.psu.edu>, <3.0.6.32.20011122125948.00974e88@pop3.clear.net.nz> Subject: Re: [9fans] Nagle algorithm Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.7 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 22 Nov 2001 09:57:11 GMT andrew@mbmnz.co.nz (Andrew Simmons) writes: > That makes sense, thanks. Not a problem for my application, but it's good > to be aware of a potential problem. (It should be noted that the same thing proved true of X applications; Nagle isn't just bad for Plan 9 RPC's; it's bad for *any* RPC application.) --upas-cxwcnjqqwlhfwibcjrobwyzxfc--