Re: Ssh.. can we please have HPN back?

From: Allan Jude <allanjude_at_freebsd.org>
Date: Fri, 19 May 2017 11:03:59 -0400
On 2017-05-19 00:01, Rodney W. Grimes wrote:
>> So after stripping out the HPN version of ssh from our product becasue
>> "it was no longer needed" we dicovered that we were premature in doing so.
>> Apparently ssh still really needs HPN to get any throughput at all when
>> there are latencies involved.
>>
>>
>> For example, with HPN we get 13MB/sec between the Azure US west
>> Data center and the Azure East data center.But the standard ssh in 10.3
>> (with HPN stripped out) can barely manage 2MB/sec transfers.
>>
>> I did ask at the time whether it was proved that the new ssh didn't 
>> require the HPN changes,
>> and was assured, "no" but it would appear that the picture isn't as clear.
>> tht seems silly to have to import the port when we have what would 
>> otherwise be a
>> perfectly good ssh as part of hte system, and it's really annoying 
>> having to specify
>> /usr/local/bin/scp  or /usr/local/bin/ssh in every script.
>>
>> So can we please have the latest version of the HPN changes back in 
>> the default system please?
>> It seem rather odd that the upstream openssh has had this problem for 
>> SO LONG and not fixed it.
> 
> Allan Jude has recently done a bunch of work on this though I do
> not know its current status of being either upstreamed (I know
> some of it well not be accepted from conversations with Allan)
> or commited to the tree.
> 

I hope to have the most important part of the patch rebased on the
latest upstream version of OpenSSH by the end of this weekend.

The versions I built and benchmarked for AsiaBSDCon were based on the
HPN patched openssh-portable from ports, but I think the change required
to actually make ssh not suck will only be a few lines, and will be
acceptable by upstream.

The big issue is in the channel_check_window()

The condition for growing the SSH window is if we have received 3 times
the max packet size. For some reason this constant small growth of the
SSH window never lets the TCP socket buffer grow.

This behaviour was added in OpenSSH 4.7 (Jun 2007), and makes sense for
interactive ssh sessions.

More detail in my paper, see the 'Broken Windows' chapter:
http://allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf

Anyway, my fix was to only allow that condition to result in moving the
SSH window forward if packet_is_interactive(). In the bulk transfer
case, it falls back to using the other (original) condition of 'half of
the local window max has been consumed'.

The other condition is a modified version of one of the HPN patches. We
do a getsockopt SO_RCVBUF to check the size of the tcp socket buffer,
and if the remaining part of the SSH window has fall below the size of
the socket buffer, we grow the SSH window by 150%, up to SSHBUF_SIZE_MAX

https://github.com/rapier1/openssh-portable/compare/master...allanjude:dynamic_window_fix.diff

I just need to rejigger it a bit so it doesn't depend on the HPN support
functions and becomes an independent patch.

Figure 3 and Figure 4 show what difference HPN makes when you add
latency, but also show without my patch, HPN only solves the recv case,
not the send case.

-- 
Allan Jude


Received on Fri May 19 2017 - 13:04:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC