Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By Tekken
#90952 According to an article:

Code: Select allTiming and delays

millis() and micros() return the number of milliseconds and microseconds elapsed after reset, respectively.

delay(ms) pauses the sketch for a given number of milliseconds and allows WiFi and TCP/IP tasks to run. delayMicroseconds(us) pauses for a given number of microseconds.

Remember that there is a lot of code that needs to run on the chip besides the sketch to keep an existing WiFi connection alive. WiFi and TCP/IP libraries get a chance to handle any pending events each time the loop() function completes, OR when delay() is called. If you have a loop somewhere in your sketch that takes a lot of time (>50ms) without calling delay(), you might consider adding a call to delay function to keep the WiFi stack running smoothly.

There is also a yield() function which is equivalent to delay(0). The delayMicroseconds function, on the other hand, does not yield to other tasks, so using it for delays more than 20 milliseconds is not recommended.


I have a HTTP server code running on an ESP8266 with a huge delay(1000) in the middle of the main loop. Now I understand why is it required however I still believe that this is slowing down my code and also the TCP/IP stack does not operate efficiently.

For example here is an average ping from the ESP being right next to the access point:

Code: Select all64 bytes from 192.168.1.104: seq=2568 ttl=255 time=104.947 ms
64 bytes from 192.168.1.104: seq=2570 ttl=255 time=51.506 ms
64 bytes from 192.168.1.104: seq=2572 ttl=255 time=107.570 ms
64 bytes from 192.168.1.104: seq=2574 ttl=255 time=44.578 ms
64 bytes from 192.168.1.104: seq=2576 ttl=255 time=94.083 ms
64 bytes from 192.168.1.104: seq=2578 ttl=255 time=37.497 ms
64 bytes from 192.168.1.104: seq=2580 ttl=255 time=87.996 ms
64 bytes from 192.168.1.104: seq=2582 ttl=255 time=36.203 ms
64 bytes from 192.168.1.104: seq=2584 ttl=255 time=80.566 ms
64 bytes from 192.168.1.104: seq=2586 ttl=255 time=14.936 ms
64 bytes from 192.168.1.104: seq=2588 ttl=255 time=66.418 ms
64 bytes from 192.168.1.104: seq=2590 ttl=255 time=14.558 ms
64 bytes from 192.168.1.104: seq=2592 ttl=255 time=60.157 ms
64 bytes from 192.168.1.104: seq=2594 ttl=255 time=110.632 ms
64 bytes from 192.168.1.104: seq=2596 ttl=255 time=58.076 ms
64 bytes from 192.168.1.104: seq=2598 ttl=255 time=110.749 ms
64 bytes from 192.168.1.104: seq=2600 ttl=255 time=61.434 ms
64 bytes from 192.168.1.104: seq=2604 ttl=255 time=46.181 ms
64 bytes from 192.168.1.104: seq=2606 ttl=255 time=107.223 ms
64 bytes from 192.168.1.104: seq=2608 ttl=255 time=6.172 ms
64 bytes from 192.168.1.104: seq=2610 ttl=255 time=79.259 ms
64 bytes from 192.168.1.104: seq=2612 ttl=255 time=31.355 ms
64 bytes from 192.168.1.104: seq=2614 ttl=255 time=74.469 ms
64 bytes from 192.168.1.104: seq=2616 ttl=255 time=42.742 ms
64 bytes from 192.168.1.104: seq=2618 ttl=255 time=81.456 ms
64 bytes from 192.168.1.104: seq=2620 ttl=255 time=15.986 ms
64 bytes from 192.168.1.104: seq=2622 ttl=255 time=67.207 ms
64 bytes from 192.168.1.104: seq=2624 ttl=255 time=14.543 ms
64 bytes from 192.168.1.104: seq=2626 ttl=255 time=58.151 ms
64 bytes from 192.168.1.104: seq=2627 ttl=255 time=1116.019 ms
64 bytes from 192.168.1.104: seq=2628 ttl=255 time=122.666 ms

--- 192.168.1.104 ping statistics ---
2629 packets transmitted, 1248 packets received, 52% packet loss
round-trip min/avg/max = 1.714/134.133/2966.534 ms


As it shows there are huge lag spikes and packet loss.
I have also tried to put in yields() in different parts of the code, it does not change much. As I understand this is essentially a delay(0).

Isn't there another proper way to do this? Like call whatever function to take care of the ESPs networking needs whether that takes 10mS 20mS or 500mS then return to the main loop to work on the main code?

Thanks! :)
User avatar
By jankop
#90983 My HTTP server is also a client and sends data to another HTTP server too. Can't you put a program here?
You're making a mistake somewhere. You can watch my ping here:
Code: Select allC:\Users\Pavel>ping -n 20 192.168.1.11
Pinging 192.168.1.11 with 32 bytes of data:
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=3ms TTL=255
Reply from 192.168.1.11: bytes=32 time=1ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=9ms TTL=255
Reply from 192.168.1.11: bytes=32 time=18ms TTL=255
Reply from 192.168.1.11: bytes=32 time=1ms TTL=255
Reply from 192.168.1.11: bytes=32 time=10ms TTL=255
Reply from 192.168.1.11: bytes=32 time=11ms TTL=255
Reply from 192.168.1.11: bytes=32 time=1ms TTL=255
Reply from 192.168.1.11: bytes=32 time=36ms TTL=255
Reply from 192.168.1.11: bytes=32 time=1ms TTL=255
Reply from 192.168.1.11: bytes=32 time=3ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=3ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=3ms TTL=255
Reply from 192.168.1.11: bytes=32 time=3ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=1ms TTL=255

Ping statistics for 192.168.1.11:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 36ms, Average = 5ms

You can find my sketch here:https://www.fancon.cz/esp8266-humi-server-klient/arduino-humi-server-client.html#download¨
I use the function delay () only for flashing of LEDs, not in the main loop of the program.
User avatar
By Tekken
#90993
Pablo2048 wrote:Hi,
using delay() in the loop is the bad thing - try to avoid it. Anyway the ping deviation came probably from modem sleep (power save). Did you try to disable wifi power saving by using WiFi.setSleepMode(WIFI_NONE_SLEEP); ?


Thanks this is somewhat helps. With this the ping replies are more stabilized but I still have a large packet loss.

Code: Select all64 bytes from 192.168.1.104: seq=510 ttl=255 time=12.435 ms
64 bytes from 192.168.1.104: seq=512 ttl=255 time=6.186 ms
64 bytes from 192.168.1.104: seq=515 ttl=255 time=5.821 ms
64 bytes from 192.168.1.104: seq=518 ttl=255 time=4.704 ms
64 bytes from 192.168.1.104: seq=520 ttl=255 time=3.426 ms
64 bytes from 192.168.1.104: seq=523 ttl=255 time=3.223 ms
64 bytes from 192.168.1.104: seq=526 ttl=255 time=15.415 ms
64 bytes from 192.168.1.104: seq=528 ttl=255 time=5.352 ms
64 bytes from 192.168.1.104: seq=531 ttl=255 time=3.697 ms
64 bytes from 192.168.1.104: seq=533 ttl=255 time=6.170 ms
64 bytes from 192.168.1.104: seq=534 ttl=255 time=8.219 ms
64 bytes from 192.168.1.104: seq=536 ttl=255 time=5.222 ms
64 bytes from 192.168.1.104: seq=539 ttl=255 time=3.931 ms
64 bytes from 192.168.1.104: seq=542 ttl=255 time=52.076 ms

--- 192.168.1.104 ping statistics ---
545 packets transmitted, 231 packets received, 57% packet loss
round-trip min/avg/max = 3.223/37.771/445.012 ms


I have to have a delay() with at least the value of 500 in the middle of the main loop otherwise the results worsen to the point that if I don't put in delay then the server is unreachable. I now understand that while you do delays() the ESP can run the network functions, so I assume that my code is blocking it to do that too long before reaching the end of the main loop.