devicehive / esp8266-firmware

DeviceHive esp8266 firmware. Control hardware via clouds with DeviceHive!
MIT License
165 stars 48 forks source link

Lag without TX/RX connected #32

Closed rawdr closed 6 years ago

rawdr commented 7 years ago

I've flashed 0.6 release devicehive.bin on an old 512KB (4Mb) ESP8266 board. It works great and is very responsive while serial terminal is connected. So far I'm just trying to use it directly by turning GPIO on/off via curl. curl -i -H 'Authorization: Bearer ABCDEFetcAccessTokenHere' http://192.168.6.80/api/gpio/write -d '{"2":0}' Works great and is very fast. After moving board and booting without TX/RX connected, pings start increasing linearly from power-on, even up past 20+ seconds. Sometimes pings will be low, until I send curl command and it spikes up past 5 seconds awhile - repeated commands in a minute will increase this until the curl commands begin to fail from timeout.

Is this from deep sleep? Do I need to give it some sort of NOP loop so it doesn't sleep, or limits the sleep to <1 second so it will stay responsive?

Thanks for your help.

-Dave

64 bytes from 192.168.6.80: icmp_seq=626 ttl=128 time=29.9 ms 64 bytes from 192.168.6.80: icmp_seq=627 ttl=128 time=39.7 ms 64 bytes from 192.168.6.80: icmp_seq=628 ttl=128 time=24.7 ms 64 bytes from 192.168.6.80: icmp_seq=629 ttl=128 time=2283 ms 64 bytes from 192.168.6.80: icmp_seq=630 ttl=128 time=3954 ms 64 bytes from 192.168.6.80: icmp_seq=631 ttl=128 time=6004 ms 64 bytes from 192.168.6.80: icmp_seq=632 ttl=128 time=6073 ms 64 bytes from 192.168.6.80: icmp_seq=633 ttl=128 time=9187 ms 64 bytes from 192.168.6.80: icmp_seq=634 ttl=128 time=9845 ms 64 bytes from 192.168.6.80: icmp_seq=635 ttl=128 time=9334 ms 64 bytes from 192.168.6.80: icmp_seq=636 ttl=128 time=11742 ms 64 bytes from 192.168.6.80: icmp_seq=637 ttl=128 time=13603 ms 64 bytes from 192.168.6.80: icmp_seq=638 ttl=128 time=14939 ms

Nikolay-Kha commented 7 years ago

Hi Dave, Theoretically UART connection shouldn't affect network latency. There is no deep sleep mode in standard firmware. I checked this issue with old ESP-201 module. I ran simultaneously 'ping' command and this test - https://github.com/devicehive/esp8266-firmware/blob/develop/firmware-tests/localapi-stress.html with such commands:

  commands.push({"command":"gpio/write", "parameters":{"0":0}});
  commands.push({"command":"gpio/write", "parameters":{"0":1}});
  commands.push({"command":"gpio/write", "parameters":{"1":0}});
  commands.push({"command":"gpio/write", "parameters":{"1":1}});
  commands.push({"command":"gpio/write", "parameters":{"2":0}});
  commands.push({"command":"gpio/write", "parameters":{"2":1}});
  commands.push({"command":"gpio/write", "parameters":{"3":0}});
  commands.push({"command":"gpio/write", "parameters":{"3":1}});

Test sends one of commands above randomly, i.e. test switch on/off pins 0,1,2,3 randomly. Overall it had been working for ~40 minutes and test sent 131510 commands. Ping statistic is below:

2438 packets transmitted, 2437 received, 0% packet loss, time 2442238ms
rtt min/avg/max/mdev = 0.701/7.979/68.628/6.122 ms

Maximum latency is 68ms.... so I wasn't able to reproduce this issue. Try to change your esp8266 and wifi access point.

rawdr commented 7 years ago

Flashed on another device, here are ping statistics while constantly sending GPIO command:

62 packets transmitted, 62 received, 0% packet loss, time 61046ms rtt min/avg/max/mdev = 46.704/3861.853/7117.308/2326.047 ms, pipe 8

Back on first device, shown a different way - 'start.sh' command sends same GPIO request with curl. Time gets longer when sending command over and over... at the end, I pause for 20 seconds and the next send happens fast.

rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m0.863s user 0m0.008s sys 0m0.004s rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m3.397s user 0m0.008s sys 0m0.004s rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m4.879s user 0m0.008s sys 0m0.004s rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m7.784s user 0m0.012s sys 0m0.004s rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m7.835s user 0m0.012s sys 0m0.000s rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m7.272s user 0m0.012s sys 0m0.004s rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m8.704s user 0m0.008s sys 0m0.004s You have new mail in /var/mail/rawdr rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m8.223s user 0m0.012s sys 0m0.000s rawdr@rawserver:/opt/plexWatch$ sleep 20 rawdr@rawserver:/opt/plexWatch$ time ./start.sh HTTP/1.0 204 No content Access-Control-Allow-Origin: * Content-Length: 0

real 0m0.867s user 0m0.004s sys 0m0.008s

But now the behavior is the same even when terminal is connected..... terminal never lags, just response over wifi. Honestly, the way the behavior keeps changing has me less sure it is just software related. Hard to debug when the issue is not isolated. So maybe there is some electrical issue but I don't know what would cause latency this way on two different boards.

Thanks.

Nikolay-Kha commented 7 years ago

Dave, check if your boards overheats and you power supply module(It should be able to give at least 300 mA) operates normally. Also, try to use another Wi-Fi Access Point.