I am trying to investigate why the SSH connection time is long (about 10 seconds). So I added some wolfssl debugging configuration changes and calls in my copy of the master branch where I build for my bench v3.0 hardware unit. That configuration is drastically stripped down in order to fit into the limited RAM available; for example, Duktape can't fit. But then I repeated Craig's timing test and found the delay was only 4 seconds, which I think is about the same as it was with the original version of wolfssh code. That's why I did not notice the increase as all of my development was done on the bench unit. The final testing was done on the v3.1 unit in my car, but I guess I just overlooked the delay there. 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. I will try to dig into this further, but testing on the unit in my car is much less convenient. First I need to repeat the test there with the same configuration as on the v3.0 hardware to verify if the time is still shorter, then I will need to pare down my operational configuration towards the stripped down one one to find the significant case. Maybe I can group the features to make a sort of binary search. I've attached my stripped-down config in case that might prompt any ideas from any of you. I've also attached a diff for a change I'd like to make in can.cpp. I have no use for CAN operations on my bench unit and I observed that the CanRx task consumed 29kB even though I had unconfigured the CAN components. This change skips out of the MyCan object constructor. I have implemented it by defining a static const variable so the ugliness of the preprocessor conditional can be separate at the top of the file instead of in the midst of the code. -- Steve On Mon, 8 Feb 2021, Michael Balzer wrote:
Steve,
I can confirm that effect. Didn't notice, as the connect had been slow before.
Also, mongoose appears to be locked during the whole connect, no other network activity can take place.
Regards, Michael
Am 08.02.21 um 03:32 schrieb Stephen Casner:
On Sun, 7 Feb 2021, Michael Balzer wrote:
We've had some changes recently, but apparently no issues with these (at least none reported).
I'd say it's time for 3.2.016.
Objections? Anything in the works that should be included? Craig observed that the ssh connect time doubled from 5 seconds to 10 seconds. I noticed that connecting seemed slow but since it's never been fast I had not run a comparison test. Would that be considered a problem for release?
This slowness is disappointing considering that the new code is supposed to include access to ESP32 hardware acceleration. I think I have the configuration set correctly to include this. I will try to turn on some tracing and investigate further.
-- Steve
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26