Hi, 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 server. 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 into action. 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 that next. Regards, - Håvard
