Re: [9fans] Nagle algorithm

[David Gordon Hogan <dhog@plan9.bell-labs.com>]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

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.


[-- Attachment #2: Type: message/rfc822, Size: 1835 bytes --]

From: Andrew Simmons <andrew@mbmnz.co.nz>
To: 9fans@cse.psu.edu
Subject: [9fans] Nagle algorithm
Date: Thu, 22 Nov 2001 12:20:50 +1300
Message-ID: <3.0.6.32.20011122122050.00974e88@pop3.clear.net.nz>

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).