search

esp8266 / Arduino

ESP8266 core for Arduino
GNU Lesser General Public License v2.1
15.97k stars 13.34k forks source link

[core 2.5.0] Loop Count much lower than with 2.4.2 #5513

Closed TD-er closed 4 years ago

TD-er commented 5 years ago

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: https://github.com/esp8266/Arduino/issues/5476#issuecomment-447115849

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: image

Core 2.5.0 beta1: image

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:

Swiftnesses commented 5 years ago

Do you also get slow ping responses on SDK 3.0.0?

TD-er commented 5 years ago

@Swiftnesses Both nodes run the same hardware & config, main difference is the core lib version. These are both Sonoff POW r2 nodes.

C:\Users\gijs>ping -n 10 192.168.1.112

Pinging 192.168.1.112 with 32 bytes of data:
Reply from 192.168.1.112: bytes=32 time=2ms TTL=255
Reply from 192.168.1.112: bytes=32 time=2ms TTL=255
Reply from 192.168.1.112: bytes=32 time=2ms TTL=255
Reply from 192.168.1.112: bytes=32 time=3ms TTL=255
Reply from 192.168.1.112: bytes=32 time=4ms TTL=255
Reply from 192.168.1.112: bytes=32 time=5ms TTL=255
Reply from 192.168.1.112: bytes=32 time=2ms TTL=255
Reply from 192.168.1.112: bytes=32 time=18ms TTL=255
Reply from 192.168.1.112: bytes=32 time=3ms TTL=255
Reply from 192.168.1.112: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.112:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 18ms, Average = 4ms

C:\Users\gijs>ping -n 10 192.168.1.98

Pinging 192.168.1.98 with 32 bytes of data:
Reply from 192.168.1.98: bytes=32 time=4ms TTL=255
Reply from 192.168.1.98: bytes=32 time=1ms TTL=255
Reply from 192.168.1.98: bytes=32 time=1ms TTL=255
Reply from 192.168.1.98: bytes=32 time=3ms TTL=255
Reply from 192.168.1.98: bytes=32 time=1ms TTL=255
Reply from 192.168.1.98: bytes=32 time=3ms TTL=255
Reply from 192.168.1.98: bytes=32 time=2ms TTL=255
Reply from 192.168.1.98: bytes=32 time=1ms TTL=255
Reply from 192.168.1.98: bytes=32 time=3ms TTL=255
Reply from 192.168.1.98: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.98:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 4ms, Average = 2ms
d-a-v commented 5 years ago 
First impression:
    * core 2.4.2: 12.90% (LC=6134)
    * SDK 3.0.0: 19.20% (LC=2471)
    * SDK 2.2.1: 12.40% (LC=6902)

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).

TD-er commented 5 years ago

Is it possible to create some 'board' definition which will force it to use the SDK 2.2.1? Then we can build both and just switch between the SDK versions. This way the building of both will be tested for a longer period and users will be able to test both. Or some flag in PlatformIO definition to make it easy to define a build to use a specific SDK version.

What specific WiFi changes/patches are included in SDK 3.x, which are so useful? I know @arendst mentioned deep sleep mode a few times, are these fixes related to that?

d-a-v commented 5 years ago

Is it possible to create some 'board' definition which will force it to use the SDK 2.2.1?

A menu only for generic esp8266 board could be added. And sdk back to 2.2.1 for all other boards.

Or some flag in PlatformIO definition to make it easy to define a build to use a specific SDK version.

A flag can be added in pio.

d-a-v commented 5 years ago

5763 is ready to test.

some flag in PlatformIO definition to make it easy to define a build to use a specific SDK version.

Included (search for SDK in platformio-build.py). I am not able to test with PIO.

TD-er commented 5 years ago

Juist building based on PR #5763 results in a build with this SDK: ESP82xx Core 2.6.0-dev, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support

And by just adding this single define in the platformio.ini PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK3 I get a build with this SDK: ESP82xx Core 2.6.0-dev, NONOS SDK 3.0.0-dev(c0f7b44), LWIP: 2.1.2 PUYA support

Just like this in our platformio.ini file: build_flags = ${esp82xx_2_5_0.build_flags} -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK3

So it seems to be working and quite easy to switch. As soon as this has been merged, I will add the SDK3.0 to our nightly builds (marked as 2.6.0 alpha)

Will this merge lead to a "2.5.1" label?

d-a-v commented 5 years ago

Thanks for testing

Will this merge lead to a "2.5.1" label?

Yes I think there will be a fix release, though I can't exactly say when

dm5xx commented 5 years ago

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.

devyte commented 4 years ago

@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. I'm closing this for now. Let's revisit when we look at SDK 3.x again.