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-zoreynvrnaveecageywskcdihr" Message-Id: <20011127110045.C2A8A199D7@mail.cse.psu.edu> Date: Tue, 27 Nov 2001 11:00:41 +0000 Topicbox-Message-UUID: 2b2c9f04-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-zoreynvrnaveecageywskcdihr Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit and that's what happened even with nagle enabled? that's one reason i asked about the source of the ``vast majority'' of packets on the net. if they are as you say, then i can't see nagle being invoked by any of those applications. they already do their own buffering (i was looking at the code for them just now). ftp for instance writes in blocks of 4k (it's fairly old code) and others do better than that. that's much larger than the typical MSS (which is indeed rather smaller than 4k), so the nagle delay will do sod all. as the rfc defines it, it isn't invoked, except for the FTP requests, which are small, and then all it does is delay them pointlessly, since nothing will be added to those! there is buffering in the tcp/ip implementation, so concurrency isn't affected by the mismatch between MSS and write buffer size. (ie, ftp can dump its 4k and read the next block of the file whilst the previous ones are going out.) same for http. does apache dribble the bytes out in titchy quantities? the second point is that the MSS provided by TCP/IP, if based only on the host interface's MTU configuration, isn't sufficient anyway. path MTU discovery could be used i suppose except that it was added in retrospect, relies too much on routers, gateways and firewalls all behaving well, all the way there, and even then there are non-trivial problems with it and tcp/ip. --upas-zoreynvrnaveecageywskcdihr 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 1006857093:10:22197:9; Tue, 27 Nov 2001 10:31:33 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1022055; 27 Nov 2001 10:31 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 51A5819A68; Tue, 27 Nov 2001 05:23:39 -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 A136419A60 for <9fans@cse.psu.edu>; Tue, 27 Nov 2001 05:22:07 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 168fKR-0000Po-00 for 9fans@cse.psu.edu; Tue, 27 Nov 2001 10:19:03 +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: <87g070wwg7.fsf@becket.becket.net> Organization: University of California, Irvine Content-Type: text/plain; charset=us-ascii References: , <200111261922.OAA12040@augusta.math.psu.edu> 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: Tue, 27 Nov 2001 10:16:18 GMT cross@math.psu.edu (Dan Cross) writes: > If you wanted to buffer 200 ``a's'' before sending them, why not do that > explicitly? Because the only way to know the correct number to buffer involves knowing transport level information like the MSS and so forth. --upas-zoreynvrnaveecageywskcdihr--