There are lots of valuable fixes in release 3.0, some may be especially relevant for us, i.e. heap allocation and wifi. https://github.com/espressif/esp-idf/releases …and the master is already nearly 1000 commits ahead of that. I've merged the current upstream/master locally and am now running the new build on my module. So far this update has been seamless. I've kept the defaults for all new sdkconfig options, got no build issues, flashed & rebooted fine, no crashes up to now. Firmware: 3.1.005-63-g0d5cc93/ota_0/edge (build idf ovms-3.1.005-527-g9d8e44e0 May 11 2018 08:59:12) Things I've noticed so far: * Ping response times are on average much higher than before and much less consistent. I had 1-2 ms before on an idle module, now 1-120 ms with average ~50 ms. The release notes say "Refactor ICMP ping functionality", so that supposedly is no indicator of network performance, but I've also got the impression web pages now load slightly slower than before and ssh output also seems to be slightly slower. * More RAM is allocated from the 32 bit pool than before. After startup, free 32 bit memory is down to 1.5 kB (was 23.6 kB before). Right after boot it's 17.1 kB, so it's not a new system component but also applies to our allocations. According to the task monitor the new 32 bit allocations account to the NetMan task: o OVMS# mo m Free 8-bit 47860/280828, 32-bit 1572/17828, SPIRAM 4113844/4194252 o OVMS# mo t Number of Tasks = 19 Stack: Now Max Total Heap 32-bit SPIRAM 3FFAFB48 1 Blk esp_timer 388 644 4096 41220 644 24456 3FFBE340 2 Blk eventTask 444 1772 4608 0 0 0 3FFC053C 3 Blk OVMS Events 440 3960 7168 102236 0 11268 3FFC55B0 4 Blk OVMS CanRx 428 540 1024 0 0 0 3FFC9ED8 5 Blk ipc0 388 436 1024 7776 0 0 3FFCA4D8 6 Blk ipc1 388 436 1024 12 0 0 3FFCC300 9 Rdy IDLE 364 492 1024 0 0 0 3FFCC894 10 Rdy IDLE 368 496 1024 0 0 0 3FFCD628 11 Blk Tmr Svc 388 1812 3072 0 0 0 3FFCA8EC 16 Blk tiT 488 2024 3072 1780 0 9872 3FFD87C0 17 Blk OVMS SIMCOM 460 2492 4096 3992 0 0 3FFDA8AC 18 Blk wifi 424 2312 4096 1792 0 5204 3FFDE6D8 19 Blk OVMS Vehicle 452 2004 4096 0 0 0 3FFE20A4 20 Blk OVMS COrx 464 592 4096 0 0 0 3FFE3254 21 Blk OVMS COwrk 544 544 3072 0 0 0 3FFE8934 22 Blk OVMS Console 560 1728 6144 20 0 0 3FFEA828 23 Blk OVMS NetMan 1060 5828 7168 16492 *15488* 18056 3FFEBD50 24 Blk mdns 412 1732 4096 108 0 4 3FFF2CD8 43 Rdy mo t 696 1928 5120 0 0 72 * Sadly, the SD filesystem is as slow as before. Anything I should test / investigate? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Update: Am 11.05.2018 um 09:52 schrieb Michael Balzer:
According to the task monitor the new 32 bit allocations account to the NetMan task:
Nope, the 32 bit usage of the NetMan task is the same as before. So the additional usage is outside the scope of our memory tracking, so must be a system component -- correct, Steve? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
There are two possibilities: 1) The size of the 32-bit heap region may have been reduced because there is more code stored in RAM (perhaps for flash manipulation). 2) If the extra 32-bit RAM has been allocated from the heap, then "module memory" would show it under "no task". -- Steve On Fri, 11 May 2018, Michael Balzer wrote:
Update:
Am 11.05.2018 um 09:52 schrieb Michael Balzer:
According to the task monitor the new 32 bit allocations account to the NetMan task:
Nope, the 32 bit usage of the NetMan task is the same as before. So the additional usage is outside the scope of our memory tracking, so must be a system component -- correct, Steve?
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
"module memory" doesn't show the allocation under "no task". Up to now there have been no issues resulting from the low 32 bit RAM, the module has been running all day long, with all com channels and on multiple test drives & charges without a single crash or other problem. Looks really good. I think I'll roll out the build on my server to get some field results. Regards, Michael Am 11.05.2018 um 17:13 schrieb Stephen Casner:
There are two possibilities:
1) The size of the 32-bit heap region may have been reduced because there is more code stored in RAM (perhaps for flash manipulation).
2) If the extra 32-bit RAM has been allocated from the heap, then "module memory" would show it under "no task".
-- Steve
On Fri, 11 May 2018, Michael Balzer wrote:
Update:
Am 11.05.2018 um 09:52 schrieb Michael Balzer:
According to the task monitor the new 32 bit allocations account to the NetMan task: Nope, the 32 bit usage of the NetMan task is the same as before. So the additional usage is outside the scope of our memory tracking, so must be a system component -- correct, Steve?
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
If no "module memory" or "module tasks" command has been executed then the 32-bit RAM allocation that you see under NetMan task won't have been allocated, so for typical users there should still be plenty of free 32-bit RAM in case the system decides it needs some at a later time for some infrequent operation. If a memory diagnostic command is issued at a time when 32-bit RAM has been used for something else, the allocation will back off to 8-bit RAM which should work fine on v3.1 hardware. We developers might see a problem if memory diagnostics have been used and then some infrequent event needing 32-bit memory occurs. I implemented the 32-bit memory allocation for the v3.0 hardware since I couldn't afford to use all the 8-bit memory for diagnostics and I could make my code tolerate the lack of 8-bit access. I could make my code try SPIRAM first so that the 32-bit memory would be kept free on v3.1 hardware. That is, unless we consider the 32-bit memory otherwise wasted and want to keep as much SPIRAM available as we can. -- Steve On Fri, 11 May 2018, Michael Balzer wrote:
"module memory" doesn't show the allocation under "no task".
Up to now there have been no issues resulting from the low 32 bit RAM, the module has been running all day long, with all com channels and on multiple test drives & charges without a single crash or other problem. Looks really good.
I think I'll roll out the build on my server to get some field results.
Regards, Michael
Am 11.05.2018 um 17:13 schrieb Stephen Casner:
There are two possibilities:
1) The size of the 32-bit heap region may have been reduced because there is more code stored in RAM (perhaps for flash manipulation).
2) If the extra 32-bit RAM has been allocated from the heap, then "module memory" would show it under "no task".
-- Steve
On Fri, 11 May 2018, Michael Balzer wrote:
Update:
Am 11.05.2018 um 09:52 schrieb Michael Balzer:
According to the task monitor the new 32 bit allocations account to the NetMan task: Nope, the 32 bit usage of the NetMan task is the same as before. So the additional usage is outside the scope of our memory tracking, so must be a system component -- correct, Steve?
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Since my rollout of the build with the current esp-idf master yesterday, 8 users have installed the new release. So far, no issues have been reported. Crashes still occur, I just again had the one in mbuf_insert() (issue #120). But I don't think the new release has a RAM issue that needs to be solved. Regards, Michael Am 11.05.2018 um 21:39 schrieb Stephen Casner:
If no "module memory" or "module tasks" command has been executed then the 32-bit RAM allocation that you see under NetMan task won't have been allocated, so for typical users there should still be plenty of free 32-bit RAM in case the system decides it needs some at a later time for some infrequent operation. If a memory diagnostic command is issued at a time when 32-bit RAM has been used for something else, the allocation will back off to 8-bit RAM which should work fine on v3.1 hardware. We developers might see a problem if memory diagnostics have been used and then some infrequent event needing 32-bit memory occurs.
I implemented the 32-bit memory allocation for the v3.0 hardware since I couldn't afford to use all the 8-bit memory for diagnostics and I could make my code tolerate the lack of 8-bit access. I could make my code try SPIRAM first so that the 32-bit memory would be kept free on v3.1 hardware. That is, unless we consider the 32-bit memory otherwise wasted and want to keep as much SPIRAM available as we can.
-- Steve
On Fri, 11 May 2018, Michael Balzer wrote:
"module memory" doesn't show the allocation under "no task".
Up to now there have been no issues resulting from the low 32 bit RAM, the module has been running all day long, with all com channels and on multiple test drives & charges without a single crash or other problem. Looks really good.
I think I'll roll out the build on my server to get some field results.
Regards, Michael
Am 11.05.2018 um 17:13 schrieb Stephen Casner:
There are two possibilities:
1) The size of the 32-bit heap region may have been reduced because there is more code stored in RAM (perhaps for flash manipulation).
2) If the extra 32-bit RAM has been allocated from the heap, then "module memory" would show it under "no task".
-- Steve
On Fri, 11 May 2018, Michael Balzer wrote:
Update:
Am 11.05.2018 um 09:52 schrieb Michael Balzer:
According to the task monitor the new 32 bit allocations account to the NetMan task: Nope, the 32 bit usage of the NetMan task is the same as before. So the additional usage is outside the scope of our memory tracking, so must be a system component -- correct, Steve?
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (2)
-
Michael Balzer -
Stephen Casner