[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
ssh, HPN extension and TCP auto-tuning
the OpenSSH in NetBSD has for quite a while had the "high-
performance networking" patches applied.
However, despite this, we are observing rather low performance
when copying files over a distance, e.g. we have a pair of hosts
running netbsd-7 code, placed some 14-15ms apart, where scp'ing a
file only manages to give around 2.6MB/s.
Doing a tcpdump and an analysis using tcptrace + looking at the
result with xplot reveals that the TCP window never climbs above
the default 32KB size.
This is when the scp client is pushing the file to the remote
However, when you copy "in the other direction", i.e. when the
remote sshd is the one which is pushing the file across the
network, we get an average of 8.4MB/s when copying a 143MB large
file, and a tcpdump + tcptrace reveals that in this case the
system's automatic tuning of the TCP window is indeed kicking
The same behaviour can be observed with the scp client from
8.0_BETA: pushing with scp is slow, pulling with scp from the
remote server is quite a bit faster. I'm going to guess that
"pushing with scp" is the most often used mode, as you may get
file name completion in that case...
If, on the other hand, I bump the recvspace and sendspace on the
two involved hosts, so that the scp client has a larger default
send space, performance improves, but again, TCP auto-tuning does
not appear to be kicking in.
Am I alone in seeing this?
I must say I'm puzzled by the result.
The configuration on both systems are pretty much "stock", and
the network is not the bottleneck in my case.
Admittedly, the OpenSSH in netbsd-7 is quite old, and the HPN
patches are probably of the same vintage, and I've not checked if
a newer combination on that front will improve matters; I may do
Main Index |
Thread Index |