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: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20011127053153.5D9E2199E8@mail.cse.psu.edu> Date: Tue, 27 Nov 2001 00:31:51 -0500 Topicbox-Message-UUID: 2ae7999a-eaca-11e9-9e20-41e7f4b1d025 > > 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.) Sorry to quibble... technically, the X protocol isn't an RPC protocol. Events and errors are asynchronous; many of the requests do not require a response. There are some so-called ``round trip requests'' which is where the RPC behaviour comes in. One such request is the one that fetches a property from a window; this accounts for the often excrutiatingly slow startup times for X applications, which have to communicate with the window manager through a whole slew of XGetProperty requests and their ilk. Motif is particularly bad in this regard: the ICCCM wasn't complex enough for them, they added more properties, which basically only MWM knows about. But, anyway, X was deliberately engineered to be as insensitive to round trip delays as the designers thought possible, by the liberal use of its asynchronous model. Plan 9 achieves much the same effect by allowing multiple draw(3) requests to be sent in a single write. They are buffered up by the draw library. I run rio and acme over my cpu or drawterm connection from home; they are quite snappy.