[Ovmsdev] Time for release 3.2.016?

[Michael Balzer]

Steve,

Am 12.02.21 um 17:31 schrieb Stephen Casner:
> On Fri, 12 Feb 2021, Michael Balzer wrote:
>> as written before, higher base memory footprint is probably OK but needs to be
>> tested on complex vehicles. So I suggest we do that before finalizing 3.2.016.
> There seemed to be no response when that test was offered on a
> separate branch.  Shall I increase the NetMan stack size now on master
> so all the cars (that have active developers) can test it?

Well, if the vehicle developers don't react, we can only release the 
test to the edge users and see if complaints come in or crash counts 
increase significantly… IOW, yes.

>> Mongoose SSL connects also are slow, speeding them up would have a broader
>> effect. But mongoose won't benefit from wolfSSL in internal RAM, as it's using
>> mbedTLS supplied by the esp-idf.
> Is mbedTLS configured to use heap instead of stack?

I have no idea. There are 74 config options for MBEDTLS, none seems to 
address heap or stack.

There seems to be only the "Memory allocation strategy", which is 
currently configured for SPIRAM as well. That seems to indicate mbedTLS 
always uses the heap or at least has no option to reduce it's stack 
footprint.

>> What do you think, is there a chance we could reduce overall memory footprint
>> _and_ gain speed for all SSL connects if we change mongoose to use wolfSSL?
> It does seem inefficient in at least the code size dimension to have
> multiple implementations of equivalent functionality, although I have
> limited that by explicitly including only those source files from
> wolfssl that are required by wolfssh.  So switching mongoose to use
> wolfSSL would require increasing that set.  I'd be happy to try that.

That would be great.

Mongoose has an SSL library abstraction layer, but there certainly will 
be dragons…

>> This comparison indicates wolfSSL is normally much more RAM efficient than
>> mbedTLS:
>> https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_tls.html#comparison-between-mbedtls-and-wolfssl
> It would be nice if that comparison stated timings as well.

I've searched hard, it seems there is no independant comparison of 
mbedTLS vs WolfSSL. The WolfSSL guys say their lib performs better, but 
don't provide any numbers.

>> Maybe discarding mbedTLS frees enough memory to put wolfSSL into internal RAM?
> I would think that we don't have mongoose SSL processing and wolfSSL
> processing happening at the same time.  If that's true, then the
> switch would not help stack usage.  Do you know?
>
>                                                          -- Steve

Do we still need the larger stack if wolfSSL can run in internal RAM 
completely?

If an ssh/scp channel is used while the module performs https requests 
(e.g. for scripts or OTA update checks) or has a connection to a V2/V3 
server using TLS, both libs will be in use simultaneously.

Regards,
Michael


-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210212/3a3aecb2/attachment.sig>