No more than 2-3 packets/sec from the ESP8266?

[tve]

I can't get more than 2-3 packets/sec or 2.8-4.2KB/s out of the ESP8266 via TCP. The bandwidth is of concern, but the latency even more for me. Basically, I can't send a packet more frequently than every ~350ms-400ms. I wrote a simple test program that accepts TCP connections and sends a small buffer containing "HELLO\n" in the sent-callback handler, i.e. as fast as allowed in the SDK 0.9.5. Here's what it looks like:

Code: Select all

$ true | nc -q 3 esp8266 23
HELLO
HELLO
HELLO
HELLO
HELLO
HELLO
HELLO
HELLO
$

So this ran for 3 seconds (-q 3) and resulted in a whopping 8 packets received. Looking at tcpdump, here's a typical round-trip:

Code: Select all

00:00:00.363428 IP 192.168.0.29.23 > 192.168.0.3.34623: Flags [P.], seq 7:13, ack 1, win 5840, length 6
        0x0000:  4500 002e 0155 0000 ff06 3904 c0a8 001d  E....U....9.....
        0x0010:  c0a8 0003 0017 873f 0000 5f76 dafd 3fd9  .......?.._v..?.
        0x0020:  5018 16d0 3246 0000 4845 4c4c 4f0a       P...2F..HELLO.
00:00:00.000027 IP 192.168.0.3.34623 > 192.168.0.29.23: Flags [.], ack 13, win 29200, length 0
00:00:00.355630 IP 192.168.0.29.23 > 192.168.0.3.34623: Flags [P.], seq 13:19, ack 1, win 5840, length 6
        0x0000:  4500 002e 0156 0000 ff06 3903 c0a8 001d  E....V....9.....
        0x0010:  c0a8 0003 0017 873f 0000 5f7c dafd 3fd9  .......?.._|..?.
        0x0020:  5018 16d0 3240 0000 4845 4c4c 4f0a       P...2@..HELLO.


The timestamps are packet inter-arrival times, e.g., it took 355ms from the ACK sent by my laptop 'til the next "HELLO" data packet. So my laptop responds in microseconds with the ACK and the ESP takes its sweet time.

Maybe my Wifi is borked? Well, the initial syn-ack came back from the ESP in ~100ms and I routinely see ACKs from the ESP in 30ms when my laptop sends data to the ESP.

If I run two connections like the above at the same time I get no more packets per second, each connection runs at half the speed of the above.

Is anyone else seeing this? Are there any work-arounds?

I put my code into a github repo: https://github.com/jeelabs/ESP8266-bandwidth, the main app being https://github.com/jeelabs/ESP8266-band ... ser_main.c

[tve]

FYI, I switched to the FreeRTOS SDK and it has none of the problems I've encountered. It's sooooo much better. The std SDK is also seriously broken when it comes to flow-control, the semantics of espconn_recv_hold are a joke. Please, please put your energy behind the rtos SDK!

[ESP_Faye]

Hi,

Sorry for the inconvenience

the problem you mentioned has been resolved in esp_iot_sdk_v0.9.6_b1 http://bbs.espressif.com/viewtopic.php?f=7&t=205

please have a try ~

[tve]

Are you sure, because I did try the new beta firmware and didn't see a difference. Also, the FreeRTOS system is so much better, how do I get the claimed fix into that? Is it in the closed-source libraries?

[ESP_Faye]

Hi,

you can just try AT bin files in \esp_iot_sdk_v0.9.6_b1\bin\at

send data in transparent transmission, refer to document "Espressif AT Command Examples".

we tested it , the speed is only limited by UART.

Thanks for your interest in ESP8266 !

[doughboy]

Hi,

you can just try AT bin files in \esp_iot_sdk_v0.9.6_b1\bin\at

send data in transparent transmission, refer to document "Espressif AT Command Examples".

we tested it , the speed is only limited by UART.

Thanks for your interest in ESP8266 !

I just tested 0.9.6b1 and it is still very slow. You need to fix normal mode as well. In server mode, CIPMUX must be 1 and mode must be normal.

I converted arduino ethernet webserver example, and to send 207 bytes takes 10 seconds. As the other poster said, this is ridiculous.

I timed my code, and the time from the last byte sent to serial to esp module to the time arduino receives SEND OK is about 200-220ms. The arduino webserver example uses 52 sends to send the 207 bytes of data and it took 52*200=about 10 seconds to complete.

You need to add api that uses numbers for command so there is no need to parse and a peek() of one byte can tell what the command is going to be and can dispatch quickly via case/switch statement. I can tell that by using human readable AT commands, the firmware is intended for human interactive use. It is not designed to be used by a program, it is too slow.

I hope the slow transmission issue can be fixed right away.

thank you.

[doughboy]

This is the timing shown in curl as client. 207 bytes in 11 seconds for a whopping 18 bytes per second transfer rate.

$ curl http://192.168.1.11/test
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 207 0 207 0 0 18 0 --:--:-- 0:00:11 --:--:-- 20<!DOCTYPE HTML>
<html>
analog input 0 is 98<br />
analog input 1 is 137<br />
analog input 2 is 159<br />
analog input 3 is 114<br />
analog input 4 is 247<br />
analog input 5 is 184<br />
</html>

[doughboy]

This is the server side (esp8266 connected to arduino)

server is at 192.168.1.11
0,CONNECT

new client
+IPD,0,80:
GET /test HTTP/1.1
User-Agent: curl/7.33.0
Host: 192.168.1.11
Accept: */*

Time to send page = 10562
client disonnected

[tve]

Hi,

you can just try AT bin files in \esp_iot_sdk_v0.9.6_b1\bin\at

send data in transparent transmission, refer to document "Espressif AT Command Examples".

we tested it , the speed is only limited by UART.

Thanks for your interest in ESP8266 !

I do not see a speed improvement. Can you make your test available? Are you testing response time or are you just testing one-way bandwidth? it's the response time that is a problem, not the bandwidth.

[doughboy]

this is still a problem even with the latest AT firmware

download/file.php?id=239

I think internally every CIPSEND adds a hardcoded delay of 200ms.

And yes, as tve says, it is not a question of how fast uart sends one packet.
Try sending 1000 packets of 1 byte each in series (loop CIPSEND 1000 times sending 1 byte each time), it will take over 3 minutes to send 1000 bytes.
This is not a problem in arduino with any other ethernet hardware, only with esp8266.

Please fix this, as this issue essentially makes esp8266 not practical to use.
thank you.