From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Nagle algorithm From: David Gordon Hogan MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-zbpbejngjdwtbfpshaqqkqejqg" Message-Id: <20011121233823.814D7199E7@mail.cse.psu.edu> Date: Wed, 21 Nov 2001 18:38:20 -0500 Topicbox-Message-UUID: 27450fa2-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-zbpbejngjdwtbfpshaqqkqejqg Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit It's inappropriate for RPC protocols. Nagle's algorithm attempts to buffer up multiple writes and send them as a single TCP packet -- where the writes are small. As such, it's fine for telnet conversations where you don't really want each keystroke generating a separate packet if it can be avoided. The mechansim is to delay the transmission of small packets in the hope that more data will show up. Consider 9P over TCP. Many of the messages are quite small, and will be delayed. 9P is RPC based, so latency is a big concern. The sender of the small message is typically blocked waiting for a response, so Nagle's hope that more data will be sent is (in this case) invalid. All is succeeds in doing is drastically increasing the effective round trip time. This was a big issue for drawterm. Use of the mouse in drawterm results in small Rread messages being sent, in response to reads of /dev/mouse at the other end. These were being delayed by a significant fraction of a second, resulting in really sluggish interactive performance, until we figured out that Nagle's algorithm was responsible and inserted the appropriate setsockopt call into drawterm. --upas-zbpbejngjdwtbfpshaqqkqejqg Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Nov 21 18:21:23 EST 2001 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 38E3019A5A; Wed, 21 Nov 2001 18:21:11 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from frontdoor.mbmnz.co.nz (210-55-57-168.adsl.xtra.co.nz [210.55.57.168]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 74E74199E7 for <9fans@cse.psu.edu>; Wed, 21 Nov 2001 18:20:01 -0500 (EST) Received: from MERCURY ([192.168.0.63]) by frontdoor.mbmnz.co.nz with Microsoft SMTPSVC(5.0.2195.1600); Thu, 22 Nov 2001 09:27:18 +1300 Message-Id: <3.0.6.32.20011122122050.00974e88@pop3.clear.net.nz> X-Sender: mbml/andrew@pop3.clear.net.nz X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: 9fans@cse.psu.edu From: Andrew Simmons Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 21 Nov 2001 20:27:18.0733 (UTC) FILETIME=[EA8FAFD0:01C172CA] Subject: [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 12:20:50 +1300 Slightly off-topic, but I seem to detect a certain hostility to the Nagle algorithm in this group, whereas the conventional wisdom in the Winsock world where I currently spend my days is that the Nagle algorithm should almost never be disabled. What's wrong with Nagle? (and please, no cracks about wisdom and Windows programming being mutually exclusive). --upas-zbpbejngjdwtbfpshaqqkqejqg--