darcs

Issue 1170 Darcs transfer-mode disables Nagle

Title Darcs transfer-mode disables Nagle
Priority bug Status wont-fix
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, ertai, galbolle, jch, kowey, thorkilnaur, twb
Assigned To
Topics Performance, SSH

Created on 2008-10-25.10:22:37 by jch, last changed 2020-08-01.14:24:04 by bfrk.

Messages
msg6450 (view) Author: jch Date: 2008-10-25.10:22:36
After discussion with Nicolas and Florent, we've found a few issues with
the ``darcs transfer-mode'' protocol.  I'm filing separate bugs for each
issue.

3. The underlying TCP stream has Nagle's algorithm disabled

Nagle's algorithm is disabled (SO_NODELAY socket option).  This is actually
a bug in ssh, I don't know if there's an ssh option to disable it.

                                        Juliusz
msg7202 (view) Author: twb Date: 2009-01-26.03:56:00
Hi Juliusz,

On Fri, Oct 24, 2008 at 11:22:36PM +0000, Juliusz Chroboczek wrote:
> [Regarding darcs transfer-mode,] the underlying TCP stream has
> Nagle's algorithm disabled (SO_NODELAY socket option).  This is
> actually a bug in ssh, I don't know if there's an ssh option to
> disable it.

What are the steps to resolve this issue?  Do we need to get more
information from the openssh developers?
msg8229 (view) Author: kowey Date: 2009-08-18.08:40:41
Sounds like we need somebody to get in touch with some OpenSSH developers and
ask them about this.

The following is just curiosity/trying to understand:

Incidentally, I wonder what makes darcs transfer-mode a particularly good
candidate for enabling Nagle's algorithm.  Wikipedia says:

  Nagle's document, Congestion Control in IP/TCP Internetworks (RFC896)
  describes what he called the 'small packet problem', where an application
  repeatedly emits data in small chunks, frequently only 1 byte in size. Since
  TCP packets have a 40 byte header (20 bytes for TCP, 20 bytes for IPv4), this 
  results in a 41 byte packet for 1 byte of useful information, a huge
  overhead. This situation often occurs in Telnet sessions, where most
  keypresses generate a single byte of data which is transmitted immediately.
  Worse, over slow links, many such packets can be in transit at the same time, 
  potentially leading to congestion collapse.

Is this related to our many-little-files problem?  If so, if we implemented
something like packs (issue1535) or pipelining of darcs transfer-mode
(issue1168), does this become less relevant?

My guess is that Juliusz pointed this out as the sort of thing we should do
because it's easy, almost free and could benefit us.  (Thanks for splitting this
up by the way!)

Taking the liberty of adding Nicolas and Florent.
msg9236 (view) Author: jch Date: 2009-11-11.20:53:49
Background: TCP is more efficient if you send large packets.

There are three ways of achieving that:

1. perform large writes, so that the TCP/IP stack can segment into MTU-sized
segments;
2. perform small writes, but tell the TCP stack to only flush when you tell it
to.  This can be done using the Linux-specific TCP_CORK.
3. perform small writes, but tell the TCP stack to delay sending the packets
unless it can send a full-sized segment.

Nagle's algorithm is an absolutely brilliant way of achieving (3) (look, Ma, no
timers).  Since it interacts badly with delacks (don't ask, they're silly) when
an application performs small pipelined writes, it can be disabled using
TCP_NODELAY.  Ssh disables Nagle by default, with no way I can see of reenabling it.

I think this needs adding an option to ssh.

--Juliusz
msg9237 (view) Author: jch Date: 2009-11-11.20:59:18
Just to make it clear -- enabling Nagle does not mean you're welcome to perform
small writes, large writes are still preferable, due to the issue with delacks.

(If I had a blog, I'd write an entry called « Delacks considered harmful. »)

--Juliusz
msg14512 (view) Author: galbolle Date: 2011-06-10.11:36:41
Is this still necessary now that we have packs?
msg22360 (view) Author: bfrk Date: 2020-08-01.14:24:00
Nice idea but doesn't work. I followed

  https://blog.mmmonk.net/2010/10/nagle-in-openssh.html

adding

  Host hub.darcs.net
    ProxyCommand /usr/bin/socat - TCP:%h:%p,cork

in my .ssh/config. The results are disappointing: cloning with this option consistently takes 
almost twice as long as without.

with the option:

ben@home[1]:~/scratch>time darcs clone bf@hub.darcs.net:kowey/rambling-robot --no-cache
Directory or file '/home/ben/scratch/rambling-robot' already exists, creating repository as 
'/home/ben/scratch/rambling-robot_4'
Done fetching and unpacking basic pack.
Copying patches, to get lazy repository hit ctrl-C...
Finished cloning.
15,78s 28M

without the option

ben@home[1]:~/scratch>time darcs clone bf@hub.darcs.net:kowey/rambling-robot --no-cache
Directory or file '/home/ben/scratch/rambling-robot' already exists, creating repository as 
'/home/ben/scratch/rambling-robot_5'
Done fetching and unpacking basic pack.
Copying patches, to get lazy repository hit ctrl-C...
Finished cloning.
7,78s 28M
History
Date User Action Args
2008-10-25 10:22:37jchcreate
2008-10-25 21:02:22koweysetpriority: bug
nosy: jch, kowey, dagit, simon, thorkilnaur, dmitry.kurochkin
topic: + SSH, Performance
2008-10-27 15:58:57thorkilnaurlinkissue1169 superseder
2009-01-26 03:56:03twbsetstatus: unread -> unknown
nosy: + twb
messages: + msg7202
2009-08-10 23:49:20adminsetnosy: - dagit
2009-08-18 08:40:47koweysetstatus: unknown -> needs-reproduction
nosy: + galbolle, ertai
messages: + msg8229
2009-08-25 17:32:21adminsetnosy: + darcs-devel, - simon
2009-08-27 10:31:49koweysetnosy: jch, kowey, darcs-devel, twb, thorkilnaur, ertai, dmitry.kurochkin, galbolle
2009-08-27 14:26:00adminsetnosy: jch, kowey, darcs-devel, twb, thorkilnaur, ertai, dmitry.kurochkin, galbolle
2009-10-23 22:40:59adminsetnosy: + nicolas.pouillard, - ertai
2009-10-24 00:06:04adminsetnosy: + ertai, - nicolas.pouillard
2009-11-11 20:53:55jchsetmessages: + msg9236
2009-11-11 20:59:23jchsetmessages: + msg9237
2011-06-10 11:36:41galbollesetmessages: + msg14512
2020-08-01 14:24:04bfrksetstatus: needs-reproduction -> wont-fix
messages: + msg22360