Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ssh, HPN extension and TCP auto-tuning

On Wed, 20 Sep 2017, Havard Eidnes wrote:
the OpenSSH in NetBSD has for quite a while had the "high- performance networking" patches applied.

I wasn't aware of this. That's good to know. I've often wondered what patch sets we apply to NetBSD's SSH implementation.

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,

What is on the other side? NetBSD or something else? From the context, I'm assuming "something else" and that the something-else has the HPN patches also.

and a tcpdump + tcptrace reveals that in this case the system's automatic tuning of the TCP window is indeed kicking into action.

This could be the result of some kind of router issue. Perhaps the side that's not working is the victim of some kind of misconfiguration. Some possibilities are:

* One of the routers/firewalls is doing some reassembly or "cleansing"
  the TCP frames and preventing something like window scaling.

* Path MTU discovery is failing because it's blocking the ICMP probes. So,
  your MTU is artificially smaller in one direction.

* The connection on one side is being proxied in such a way that doesn't
  allow the optimizations to kick in.

I'm sure there are a few I'm not thinking of, too.

send space, performance improves, but again, TCP auto-tuning does not appear to be kicking in. Am I alone in seeing this?

I have to say that I've had a lot of weird issues with auto-tuning on NetBSD but I've never been had the right case to submit a PR over it. It's just... squirrly. I can't give enough details to be helpful, but no, you aren't alone in seeing it. I've noticed similar issues, but never narrowed it down enough to blame NetBSD.


Home | Main Index | Thread Index | Old Index