[Ovmsdev] Time for release 3.2.016?
casner at acm.org
Fri Feb 12 15:15:25 HKT 2021
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?
More information about the OvmsDev