[core 2.5.0] Loop Count much lower than with 2.4.2 #5513
Comments
|
What's strange to me is
because it is Arduino IDE's option "lwIP-v2 (lower memory) (no features)", which has the same/default settings as in release 2.4.2 (although upstream lwIP has changed from 2.0 to 2.1.2 in between). Do you have the same results with PIO_FRAMEWORK_ARDUINO_LWIP2_LOW_MEMORY (which is current default Arduino IDE configuration)? You can also try to use previous lwIP version in core 2.5: and replace Next step would be to try the same SDK version as we had in 2.4.2. |
d-a-v
added
the
waiting for feedback
I already found why that was in my (new installed) core 2.4.2 node.
Isn't that the same or do I need some more coffee? |
Get more coffee :) (edit: dash / underscore) |
|
Running with
I will now test with previous LWIP in core 2.5.0 (just finished my coffee ;) ) |
|
Hmm, I cannot run |
|
Then is it already downloaded in |
|
No it is not empty |
|
Ah this is platformio, You can also take already compiled binaries from 2.4.2 release (liblwip2.a - sorry in fact there is no dash/underscore, I'll get some coffee too) In any case you need to add this line in |
|
I have downloaded the binary, added it to the ld.h file and also changed this line
But the resulting binary does not boot. |
I tried myself, and indeed it is not as simple as it seems. I will find some time to provide a lwIP-2.0.3 binary compatible with core 2.5.0 if the other leads are not conclusive. Can you point to the source code of these |
These are my own functions and they take about the same time on both cores.
In short:
A controller is something which sends data to a remote computer, formatted for a specific use case (e.g. Domoticz MQTT, OpenHAB, Http, UDP, ESPeasy-p2p, etc.) |
|
About the impact of those functions: In a loop() it is mainly a call for the scheduler. By the way, these functions should be in the standard core lib: long timeDiff(unsigned long prev, unsigned long next);
long timePassedSince(unsigned long timestamp);
boolean timeOutReached(unsigned long timer);
long usecPassedSince(unsigned long timestamp);
boolean usecTimeOutReached(unsigned long timer); |
|
As a test, I have changed the flash frequency to 80 MHz
Same node running same config @ core 2.5.0 |
No, |
|
Can you instrument separately in |
|
Adding timers you mean, so we can compare those parts? |
|
Yes |
|
I added a bit more (commit will be pushed in a minute)
As can be seen, the backgroundTasks() and handle_schedule() function are taking quite a bit longer. |
As requested here: esp8266/Arduino#5513 (comment)
|
Running for about 10 minutes: Core 2.5.0:
Core 2.4.2:
|
|
And the same nodes, running for 24'447 sec:
Some counters probably have had some overflow, since the average value displayed is lower than the minimum. |
|
Just a note, the graphic image posts are much harder to use than the text ones you started with. Can't dump it into a .ODS or .XLS and compare automatically. That said, since you know your code better than we do, do you have one specific section that's egregious and can be isolated? I know your app is reporting fewer loops/s, but doing perf analysis at that level from the outside is not a fast process. If there's some small, isolated thing (i.e. this routine X takes 100 numbers, averages them, and sends to a MQTT endpoint) where it's more approachable we'd stand a better chance. Especially if it's something you can hack out into a separate sketch (even if the input and out data its sending is garbage), that means it can be repro'd and instrumented at the low-level needed to identify what's up and if it's in the core, a lib, of the SDK. The smaller the code bit and fewer libs needed, the better, for this kind of thing. |
|
I understand.
Those String operations can do a lot of memory allocations too, which could also explain the difference when sending data to a controller, since it is then placed in some buffer. So my 2 main suspects right now are:
I think for both a fairly small test could be written. |
|
To make it clear, code was always in flash. I introduced a bug in the -noexceptions option where instead of placing those std:: functions in flash it ate up IRAM. IRAM is 16KB total, ~10KB taken by the hidden SDK functions, and the rest is used for interrupt-safe routines, certain library routines that may be called from the WiFi stack, etc. Today the code is all landing in flash unless you say "place in IRAM" which is the correct behavior, and matches prior releases. Memory management lives in SPIFFS can be very variable and slow in my experience. I didn't dig into it, but it seems to have very high variability in response time even on the same hardware (so it's not flash speed related). The git log's ( Would love to get a test that can be used for isolated A/B comparisons, because I think it's elsewhere... |
|
@earlephilhower could something be hitting the SDK exception handler for reading unaligned addresses? |
|
Might be worth disabling unaligned access handler, at least in debug builds? |
|
@devyte, if @TD-er's running the same code on both builds then the code would crash hard on the older version, so I think it's probably not too likely. @igrr's point about disabling in debug builds might be good, but @TD-er's app most likely can't even build in debug mode (umm_malloc grows a lot w/heap checking and there are many IRAM/IRQ user routines in his build). |
|
I measured loop itself (time between end of loop and beginning of next loop and it is unchanged, around 5.8us, with 2.4.2 and 2.5.0beta). Then the cause is not the firmware update. It is somewhere inside our core library. @TD-er can you isolate one single relevant test or function call for us to reproduce and dig into ? |
|
@d-a-v |
|
Will you be able to try with #5763 ? |
|
So I just build with a define for |
|
I tried building it several times (PlatformIO staged, so it should use your master branch), but I keep getting this as a build: So can you give me some hints on what I need to do to make it building a NONOS SDK 2.2.1? |
|
include and library paths must be updated
check for patches to platform.txt and tools/pio.py files
…--
on mobile
Le 17 février 2019 13:54:46 Gijs Noorlander <notifications@github.com> a
écrit :
I tried building it several times (PlatformIO staged, so it should use your
master branch), but I keep getting this as a build: ESP82xx Core 2.6.0-dev,
NONOS SDK 3.0.0-dev(c0f7b44), LWIP: 2.1.2 PUYA support
N.B. The "Core 2.5.0-dev" is something I add in the build.
I added the NONOSDK221 as a define in the build.
I also tried to add board_build.sdk = NONOSDK221 to the platform.ini
section for this build, but it keeps reporting the NONOS SDK 3.0.0-dev.
So can you give me some hints on what I need to do to make it building a
NONOS SDK 2.2.1?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Not sure why, but the files I get when using PlatformIO feature/stage is not having the latest changes you have in that PR. Sometimes I just feel a bit lost in all abstractions made for PlatformIO to make it all "easier" to work with. |
|
Ah, now I get it, it wasn't merged yet. |
|
OK, I did a checkout of your PR and built it. |
|
With platformio, edit: maybe by using boards.txt.py like for arduino ide |
|
That worked :)
I will let it run for a few minutes to see what the loop-count is and get you an Excel sheet with before- and after timings of that node. Edit:
|
|
And here the comparison of the 3 versions I already mentioned in the previous post. |
|
Do you also get slow ping responses on SDK 3.0.0? |
|
@Swiftnesses
|
Per #5736, this thread, my personal experience with esp8266Audio (with which performance difference can be heard), I think we should revert. However current sdk-v3 brings some wifi fixes especially noticed by tasmota project @ascillato . If we had to revert, it could be with #5763 (default: sdk2.2.1, allowing to use sdk-pre-3.0.0 when needed). |
|
Is it possible to create some 'board' definition which will force it to use the SDK 2.2.1? What specific WiFi changes/patches are included in SDK 3.x, which are so useful? |
A menu only for generic esp8266 board could be added. And sdk back to 2.2.1 for all other boards.
A flag can be added in pio. |
|
#5763 is ready to test.
Included (search for SDK in platformio-build.py). I am not able to test with PIO. |
|
Juist building based on PR #5763 results in a build with this SDK: And by just adding this single define in the platformio.ini Just like this in our platformio.ini file: So it seems to be working and quite easy to switch. Will this merge lead to a "2.5.1" label? |
|
Thanks for testing
Yes I think there will be a fix release, though I can't exactly say when |
…eneric board only (#5763) This commit allows switching SDK firmware: nonos-sdk-pre-v3 shipped with release 2.5.0 has issues: * Some boards show erratic behavior (radio connection is quickly lost), with an unknown cause. These boards work well with previous nonos-sdk-2.2.1 firmware (#5736) * Overall performances seem to have decreased (#5513) This PR restores sdk2.2.1 (as in core-2.4.2). SDK-pre-3.0 - which has brought long awaited fixes (WiFi sleep modes) - is still available through a menu option available only with generic board. BREAKING * new define `-DNONOSDK221=1` or `-DNONOSDK3V0=1` * for external build systems: new library directory: `tools/sdk/lib/<version>/lib` * PIO: variable `PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK3` is needed for sdk-pre-v3. Fix #5736
|
Hi guys. I tried to change to 2.5.0 today and realized the same thing. 2.4.1 all was fast, switching to 2.5.0, wemos d1 mini was slooooow and with high latency. mike. |
|
@TD-er this issue doesn't apply to our current builds due to our using SDK 2.2.x . It would apply if we were to switch to SDK 3.x, but I rather cross that bridge when we get to it. |
Basic Infos
Platform
Settings in IDE
Problem Description
Loop Count in loops per sec. is much lower than with core 2.4.2. It was also mentioned here: #5476 (comment)
I have several test setups running core 2.4.2 and core 2.5.0 (see latest nightly builds of ESPeasy)
For example 2 Sonoff POW r2 nodes running the exact same configuration, the loopcount (per sec) of both differs quite a lot:
Core 2.4.2:
Core 2.5.0 beta1:
N.B. Not sure yet why in the node running 2.4.2 less things are being shown.
In general (among my test nodes) the loop-count is:
As can be seen from both Sonoff POW r2 nodes, the loop-count is:
The text was updated successfully, but these errors were encountered: