Re: Question performnace of SSH v1 vs SSH v2

Damien Miller wrote:
> Amba Giri wrote:
>
>> Hello
>>
>> I have ported OpenSSH 3.8p1 to a LynxOS platform. Recently I heard a
>> report from the field that v2 is perceived to be significantly slower
>> than v1. Is this a known issue? Are there any configuration parameters
>> that can be modified to make v2 faster?
>
>
> Protocol 2 is slower because it includes a real per-packet MAC instead
> of a weak checksum. You can save some overhead by using a truncated MAC
> like hmac-sha1-96, but there is always going to be more work per packet.

I'm not sure if this is entirely true. If transfer rates were strictly
CPU limited then we wouldn't see the typical 'fast on the LAN, slow on
the WAN' problem. If you saw 20Mbps on the LAN then being CPU limited
wouldn't explain why it would slow down to 200Kbps on the WAN.
Additionally, if it was really CPU limited we'd expect to see throughput
increase as we started using faster machines. Instead, on any given
path, we reach a throughput plateau that is independent of the CPU
powers after a certain (relatively low) threshhold.

A closer analysis of the data reveals that the most significant cause of
the slowdown is due to the flow control mechanisms used for SSH2
channels. This flow control is similar to TCP windows such that the
maximum theoretical throughput of the connection (assuming no CPU
constraints) will be determined, in large part, by the minimum of the
tcp receive window and the SSH2 flow control buffer. If you update the
BDP equation (as outlined in Stevens TCP/IP Illustrated) and solve for
throughput we end up with

bandwidth = (MIN(tcp rwin, SSH2 FC buf))
----------------------------
RTT

Since the effective SSH2 flow control buffer is 64K (its actually
defined as 128K but only 1/2 of it is actually used) and most TCP
receive windows are now ~80k most people will see a throughput
specificially bounded by the 64K buffer. So someone on an 80ms path will
see a theoretical maximum throughput of 64K/80ms or 800KB/s (6.4Mbps).

Obviously, this assumes; 1) that you have a path between the two
locations that isn't bottlenecked by something else, 2) that you have a
reasonable processor (say a PIII).

If the SSH2 flow control buffer is increased (edit the code, recompile)
to some higher value you'll often see the throughput increase linearly
(doubling the buffer doubles the throughput). Some simple tests can
confirm this assuming that you have a fat enough network path to play with.

Right now I'm typically getting 240 to 350Mbps on a 35ms path (using
RC4). At these speeds I'm processor bound but with an unmodified version
of OpenSSH I'm running at maybe 5 or 6% cpu according to top (only
around 14 Mbps).

> I have looked at implementing AES CCM, which could be much faster,
> particularly on platforms with AES implemented in CPU instructions, but
> it doesn't fit nicely in the cipher and MAC negotiation mechanism.

That would actually be amazingly cool. Are you going to work on it at
all or would it just be too much of a hack to incorporate it at this point?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev