[Bug 2848] New: Addition of an option to control Nagle's algorithm (enable/disable) can lead to significant speedups
bugzilla-daemon at bugzilla.mindrot.org
bugzilla-daemon at bugzilla.mindrot.org
Tue Apr 3 07:48:07 AEST 2018
https://bugzilla.mindrot.org/show_bug.cgi?id=2848
Bug ID: 2848
Summary: Addition of an option to control Nagle's algorithm
(enable/disable) can lead to significant speedups
Product: Portable OpenSSH
Version: 7.6p1
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5
Component: ssh
Assignee: unassigned-bugs at mindrot.org
Reporter: ttsiodras at gmail.com
Hello, OpenSSH guys.
As you can see here...
https://unix.stackexchange.com/questions/434825/ssh-speed-greatly-improved-via-proxycommand-but-why
...I've spent a good part of the last two days tracing a weird
performance issue with SSH. The executive summary is that I was able to
significantly increase the performance of SSH (as used by rsync and
borgbackup) by delegating the actual connection to netcat:
$ dd if=/dev/urandom bs=1M count=50 of=sample.data
50+0 records in
50+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.24135 s, 217 MB/s
$ rsync -av --progress ./sample.data user at 192.168.1.150:/dev/shm/
sending incremental file list
sample.data
52,428,800 100% 575.23kB/s 0:01:28 (xfr#1, to-chk=0/1)
sent 52,458,757 bytes received 35 bytes 543,614.42 bytes/sec
total size is 52,428,800 speedup is 1.00
$ ssh user at 192.168.1.150 'rm /dev/shm/sample.data'
$ rsync -av --progress -e 'ssh -o "ProxyCommand nc %h %p"'
./sample.data user at 192.168.1.150:/dev/shm/
sending incremental file list
sample.data
52,428,800 100% 3.40MB/s 0:00:14 (xfr#1, to-chk=0/1)
sent 52,458,757 bytes received 35 bytes 2,690,194.46 bytes/sec
total size is 52,428,800 speedup is 1.00
As you can see, this is a 5x speedup - basically, the use of nc as a
ProxyCommand
boosted the speed to the same levels reported by iperf3 for the link.
The reason behind this, ended up being the call to enable TCP_NODELAY -
which if I understood correctly, disables Nagle's algorithm to increase
the responsiveness of SSH. Which is good; SSH is supposed to be used
for interactive shells, so I understand that decision.
But since rsync and borgbackup and many others are using SSH as a
universal transport system, I believe it makes sense to provide a
generic option to enable/disable Nagle - e.g.
--nodelay (default)
--delay
...to control Nagle - so that tools using SSH for bulk transfers can
benefit from "full" packets sent on the wire, and avoid wasting
bandwidth. Especially over slow links - wifi in my case, but it can be
any kind of slow link - this will have significant benefits - as you
can see in my aforementioned (extensive) report in Unix Stack Exchange.
I hope you will consider adding this option to OpenSSH... My
understanding from the feedback I got talking about this in other
forums is that other SSH implementations did offer such an option - and
it shouldn't be too difficult to add... (we just want to control the
invocation of the related setsockopt via a run-time controlled
boolean).
Thanks for you time - I hope you will consider this.
Kind regards,
Thanassis Tsiodras, Dr.-Ing.
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list