[Ovmsdev] Time for release 3.2.016?

[Stephen Casner]

Earlier I said, after observing that the SSH connection time was about
4 seconds on my bench v3.0 hardware vs. 10 seconds reported by Craig:

> So I think this means it's not a problem of crypto computation time,
> so whether or not hardware acceleration is working is not the issue.
> There must be some interaction among our network activities that is
> causing some action to wait for a timeout or a subsequent event.

Nope!  The difference is slow PSRAM vs. fast internal RAM.  The v3.0
hardware has no PSRAM so I had to pare down the configuration so I
could run SSH using internal RAM.

In addition, to avoid needing to increase the NetMan stack size I
changed the wolfssl configuration to reduce stack usage by allocating
buffers using malloc instead of on the stack.  There are three
expensive functions that do many calculations and many mallocs:

wc_ecc_make_key:  2.3 seconds, 13409 mallocs
wc_ecc_shared_secret:  2.3 seconds, 13405 mallocs
RsaPublicEncryptEx:  1.9 seconds, 4980 mallocs

The result is that on a v3.1 module where malloc comes from PSRAM the
connect time is 8-10 seconds.  On the v3.0 module, stil doing malloc
but from internal RAM, the connect time is 3.5-5 seconds.  If I
increase the NetMan stack by 2kB and switch back to stack buffers
(which are in internal RAM with no malloc overhead) then the connect
time is 2.9-3.5 seconds.

So that explains why I didn't particularly notice the longer connect
time before Craig reported it.  All of my development testing was done
with the larger stack and stack allocation of buffers.  I only made
the shift to malloc buffers as a later step to avoid the stack size
increase.  I verified that it was working, but only connected a few
times with my attention focused on checking the stack usage.

So: Can we afford to increase our base RAM usage by 2K for the benefit
of reasonable SSH connect times?

                                                        -- Steve