ESP8266 Developer Zone

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

2017-11-14T22:05:52+08:00

Thank You all.

It makes the picture a bit clearer. There must be some strange idea about handshaking that has been mixed up with the TCP layer. What I notice in my experiment is that there will be no quick "SEND OK" unless something is sent back in response. If no data back the default delay seems to be near 300 ms.

To bring speed up I probably have to send a dummy response back from the server to the ESP8266 to help the sender get a "SEND OK" confirmation.

Since in my case the server is dedicated for the client it may solve the problem, but this is not the way it is supposed to work. Data is already sent - Even the reply is back before you get a "SEND OK" confirmation!

This can not be justified by buffer size. There is enough information in the TCP layer to figure out if data has been sent. There should not be any dependency on receiving incoming packages back. Those packages is another conversation. Sending should already be complete.

Sorry for "cross posting". Only to show real life scope signal images from ESP8266 strange "SEND OK" delay where the delay is demonstrated.

Statistics: Posted by Flodis — Tue Nov 14, 2017 10:05 pm

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

2016-02-28T04:40:56+08:00

Hello,

Has anything changed in the subject of speed of cipsend since last post? I have my arduino connected to wifi via esp8266 and two buttons on arduino. If i press a button it sends one byte (1 for pressed, 0 for releasing a button). But i can easily press and release faster than cipsend gets "SEND OK". And arduino, although is trying to send both - 1 and later 0, the second command is ignored by esp8266 unless i do it slowly so arduino gets "send ok" from esp. I need both client and server of my wifi so cipmux=1
Any ideas to speed it up?

Statistics: Posted by kalreg — Sun Feb 28, 2016 4:40 am

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

2015-10-27T01:34:47+08:00

Hey, I faced with the limit on sending packets on standart AT 0.5 firmware, no matter what UART baud rate is set, eps8266 cannot send more than 50 UDP packets per second.

In AT manual was mentioned that if you send data through "AT CIPSEND", esp is waiting "+++" sequence and there is pause 20ms between each packet, but for "AT CIPSEND=, datalength" there isn't any. How to solve this issue?

Statistics: Posted by rsh — Tue Oct 27, 2015 1:34 am

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

2015-07-06T02:07:51+08:00

Hi HerMajesty,

What program are you using to set the tcp server?

Thanks,

Statistics: Posted by Veeda — Mon Jul 06, 2015 2:07 am

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

2015-04-13T12:25:56+08:00

tve wrote:
Her Majesty thanks for posting your test binary. Your set-up must be different from mine, because I can't get the performance you get.

Which hardware module are you using ?

Statistics: Posted by Her Mary — Mon Apr 13, 2015 12:25 pm

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

2015-04-13T10:48:38+08:00

Hi, tve ,

Sorry for the inconvenience.

Do you still have this problem with "write_finish_callback" + "DIS_NALGE" + SDK_v1.0.1_b2 ?

Statistics: Posted by ESP_Faye — Mon Apr 13, 2015 10:48 am

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

2015-04-07T10:54:30+08:00

I tested on SDK_v1.0.0 with demo code provided here http://bbs.espressif.com/viewtopic.php?f=21&t=320

It is even faster than my old one..

Statistics: Posted by Her Mary — Tue Apr 07, 2015 10:54 am

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

2015-04-01T16:15:06+08:00

Sorry for the flurry of posts, but each time I decide to quit and go to bed I come up with another little test....

Here's a packet trace of 3 TCP connection attempts to a port on which the esp8266 app isn't listening (port 24 instead of the port 23 my app is using):

Code:

00:00:00.000000 IP 192.168.0.3.35489 > 192.168.0.29.24: Flags [S], seq 3703311375, win 29200, options [mss 1460,sackOK,TS val 1172963017 ecr 0,nop,wscale 7], length 0
00:00:00.036307 IP 192.168.0.29.24 > 192.168.0.3.35489: Flags [R.], seq 0, ack 3703311376, win 5840, length 0

00:00:14.317474 IP 192.168.0.3.35490 > 192.168.0.29.24: Flags [S], seq 2183312759, win 29200, options [mss 1460,sackOK,TS val 1172966606 ecr 0,nop,wscale 7], length 0
00:00:00.039905 IP 192.168.0.29.24 > 192.168.0.3.35490: Flags [R.], seq 0, ack 2183312760, win 5840, length 0

00:00:07.929081 IP 192.168.0.3.35492 > 192.168.0.29.24: Flags [S], seq 1929625896, win 29200, options [mss 1460,sackOK,TS val 1172968598 ecr 0,nop,wscale 7], length 0
00:00:00.066752 IP 192.168.0.29.24 > 192.168.0.3.35492: Flags [R.], seq 0, ack 1929625897, win 5840, length 0

What's interesting here is that the esp8266 responds to the initial SYN packet (correctly) with a TCP reset in 36ms, 39ms, and 66ms respectively. What this little test shows is that a round-trip from my linux box to the esp8266 lwIP TCP stack and back is possible in under 40ms. (If I ping the esp8266 I get ping times in the same ballpark, which is another confirmation.) So the problem causing >300ms reaction times to TCP ACKs is not at the wireless or device driver level. The problem is somewhere between lwIP and the "espconn" layer...

Statistics: Posted by tve — Wed Apr 01, 2015 4:15 pm

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

2015-04-01T15:52:19+08:00

Mhh, there seems to be a new bug triggered by the combination of using the write_finish callback and the NODELAY set_opt. I made a single change to my previous test program, which uses the write_finish callback: I added the ESPCONN_NODELAY option (in addition to the ESPCONN_COPY option) using two calls to espconn_set_opt to circumvent the bug that only one flag is taken into account at a time. The result is that the sending stalls after 6 packets. Here's how I initialize the connection in the connect callback:

Code:

static void ICACHE_FLASH_ATTR serverConnectCb(void *conn) {
  os_printf("Connection accepted\n");
  espconn_regist_recvcb(conn, serverRecvCb);
  espconn_regist_reconcb(conn, serverReconCb);
  espconn_regist_disconcb(conn, serverDisconCb);
  espconn_regist_write_finish(conn, serverSentCb);
  espconn_set_opt(conn, ESPCONN_NODELAY);
  espconn_set_opt(conn, ESPCONN_COPY);
  sendpacket(conn);
}

The write_finish callback simply calls espconn_sent with a 60-character string. Here's the tcpdump:

Code:

00:00:00.000000 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [S], seq 980389593, win 29200, options [mss 1460,sackOK,TS val 1172545111 ecr 0,nop,wscale 7], length 0
00:00:00.424886 IP 192.168.0.29.23 > 192.168.0.3.42707: Flags [S.], seq 6548, ack 980389594, win 5840, options [mss 1460], length 0
00:00:00.000044 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [.], ack 1, win 29200, length 0
00:00:00.025956 IP 192.168.0.29.23 > 192.168.0.3.42707: Flags [P.], seq 1:71, ack 1, win 5840, length 70
00:00:00.000034 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [.], ack 71, win 29200, length 0
00:00:00.001915 IP 192.168.0.29.23 > 192.168.0.3.42707: Flags [P.], seq 71:141, ack 1, win 5840, length 70
00:00:00.000029 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [.], ack 141, win 29200, length 0
00:00:00.002141 IP 192.168.0.29.23 > 192.168.0.3.42707: Flags [P.], seq 141:211, ack 1, win 5840, length 70
00:00:00.000030 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [.], ack 211, win 29200, length 0
00:00:00.002227 IP 192.168.0.29.23 > 192.168.0.3.42707: Flags [P.], seq 211:281, ack 1, win 5840, length 70
00:00:00.000037 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [.], ack 281, win 29200, length 0
00:00:00.002423 IP 192.168.0.29.23 > 192.168.0.3.42707: Flags [P.], seq 281:351, ack 1, win 5840, length 70
00:00:00.000030 IP 192.168.0.3.42707 > 192.168.0.29.23: Flags [.], ack 351, win 29200, length 0

After that, the connection freezes! Most likely a bug causes the write_finish callback not to be called anymore... This behavior is 100% reproducible. Try adding the ESPCONN_NODELAY to the sample you provided. For reference, my code is updated on github with the most relevant section being: https://github.com/jeelabs/ESP8266-band ... .c#L30-L71

Statistics: Posted by tve — Wed Apr 01, 2015 3:52 pm

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

2015-04-01T15:28:20+08:00

Faye, I'm afraid that the "write_finish" callback doesn't really fix the problem, it just masks it for certain use-cases. Here is a packet trace with my original program slightly modified to send 60-character packets (instead of 6-character). .3 is the linux server, .29 is the esp8266, the timestamps on the left are delta-times, e.g. the second packet below was captured 0.365888 seconds after the first packet, the third 83us after the second, etc:

Code:

00:00:00.377230 IP 192.168.0.29.23 > 192.168.0.3.42676: Flags [P.], seq 980:1050, ack 1, win 5840, length 70
00:00:00.000083 IP 192.168.0.3.42676 > 192.168.0.29.23: Flags [.], ack 1050, win 29200, length 0
00:00:00.365888 IP 192.168.0.29.23 > 192.168.0.3.42676: Flags [P.], seq 1050:1120, ack 1, win 5840, length 70
00:00:00.000083 IP 192.168.0.3.42676 > 192.168.0.29.23: Flags [.], ack 1120, win 29200, length 0
00:00:00.381337 IP 192.168.0.29.23 > 192.168.0.3.42676: Flags [P.], seq 1120:1190, ack 1, win 5840, length 70
00:00:00.000084 IP 192.168.0.3.42676 > 192.168.0.29.23: Flags [.], ack 1190, win 29200, length 0
00:00:00.662622 IP 192.168.0.29.23 > 192.168.0.3.42676: Flags [P.], seq 1120:1190, ack 1, win 5840, length 70
00:00:00.000030 IP 192.168.0.3.42676 > 192.168.0.29.23: Flags [.], ack 1190, win 29200, length 0
00:00:00.002223 IP 192.168.0.29.23 > 192.168.0.3.42676: Flags [P.], seq 1190:1260, ack 1, win 5840, length 70
00:00:00.000030 IP 192.168.0.3.42676 > 192.168.0.29.23: Flags [.], ack 1260, win 29200, length 0

You can see that the esp sends packets about every 0.3 seconds, which is consistent with all my prior tests. It seems very slow at sending the next packet once it has received an ACK. (You can see some variation in the timing above, but looking at a longer trace the typical value is between 0.3 and 0.4s.)

Here is a packet trace for the same program simply modified to use the write_finished callback instead of the sent callback:

Code:

00:00:00.405335 IP 192.168.0.29.23 > 192.168.0.3.42685: Flags [P.], seq 4380:5840, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.42685 > 192.168.0.29.23: Flags [.], ack 5840, win 52560, length 0
00:00:00.383288 IP 192.168.0.29.23 > 192.168.0.3.42685: Flags [P.], seq 5840:7300, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.42685 > 192.168.0.29.23: Flags [.], ack 7300, win 55480, length 0
00:00:00.382253 IP 192.168.0.29.23 > 192.168.0.3.42685: Flags [P.], seq 7300:8760, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.42685 > 192.168.0.29.23: Flags [.], ack 8760, win 58400, length 0
00:00:00.363807 IP 192.168.0.29.23 > 192.168.0.3.42685: Flags [P.], seq 8760:10220, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.42685 > 192.168.0.29.23: Flags [.], ack 10220, win 61320, length 0
00:00:00.385324 IP 192.168.0.29.23 > 192.168.0.3.42685: Flags [P.], seq 10220:11680, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.42685 > 192.168.0.29.23: Flags [.], ack 11680, win 64240, length 0
00:00:00.520872 IP 192.168.0.29.23 > 192.168.0.3.42685: Flags [P.], seq 11680:13140, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.42685 > 192.168.0.29.23: Flags [.], ack 13140, win 64240, length 0

Look at the timestamps: unchanged! The packet rate is still the same. Of course now the packets are 1460 bytes long thanks to buffering. So this helps bandwidth but it doesn't help round-trip times, which is the original problem I've been having. The esp still can't respond to a tcp ack in under ~0.3 seconds!

The original problem I've been having is that I can't program an Arduino via an esp8266 configured as transparent bridge because the round-trip time between avrdude and the arduino is too long due to the above TCP ack problem.

Statistics: Posted by tve — Wed Apr 01, 2015 3:28 pm

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

2015-04-01T14:58:16+08:00

Faye, thanks for the sample code. I hadn't seen the "write_finish" callback before. Looks like this is new in 1.0? Can you explain what it does? I know the docs say "callback which will be called when all sending data is completely write into write buffer or sent", but what does that imply? The fact that my previous espconn_sent data is fully placed into the buffer is irrelevant, isn't it? What would be relevant is for the buffer to have space, no? So does the "write_finish" callback really mean that there is at least 1460 bytes of free space in the send buffer? Or what does it mean?

Statistics: Posted by tve — Wed Apr 01, 2015 2:58 pm

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

2015-04-01T15:29:34+08:00

Her Majesty thanks for posting your test binary. Your set-up must be different from mine, because I can't get the performance you get. I ran the sommand you indicated:

Code:

connected with tve-home, channel 1
dhcp client start...
ip:192.168.0.29,mask:255.255.255.0,gw:192.168.0.1
:> tcp -W -i 192.168.0.3 -p 2323 -n 1 -c 500 -l 2920

The packet rate is still abysmal. The tcpdump is rather interesting, however. 192.168.0.29 is the esp8266. 192.168.0.3 is my linux box. I'm running "nc -k -l 2323" as tcp server on the linux box. Here is an excerpt from a tcpdump captured on the linux box (the timestamps on the left are delta-times, i.e. they represent the time between two packets. For example, the second packet was captured 0.832610 seconds after the first one:

Code:

00:00:00.011153 IP 192.168.0.29.20553 > 192.168.0.3.2323: Flags [P.], seq 55480:56940, ack 1, win 5840, length 1460
00:00:00.000030 IP 192.168.0.3.2323 > 192.168.0.29.20553: Flags [.], ack 56940, win 64240, length 0
00:00:00.832610 IP 192.168.0.29.20553 > 192.168.0.3.2323: Flags [.], seq 56940:58400, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.2323 > 192.168.0.29.20553: Flags [.], ack 58400, win 64240, length 0
00:00:00.011323 IP 192.168.0.29.20553 > 192.168.0.3.2323: Flags [P.], seq 58400:59860, ack 1, win 5840, length 1460
00:00:00.000029 IP 192.168.0.3.2323 > 192.168.0.29.20553: Flags [.], ack 59860, win 64240, length 0
00:00:00.805641 IP 192.168.0.29.20553 > 192.168.0.3.2323: Flags [.], seq 59860:61320, ack 1, win 5840, length 1460
00:00:00.000029 IP 192.168.0.3.2323 > 192.168.0.29.20553: Flags [.], ack 61320, win 64240, length 0
00:00:00.011554 IP 192.168.0.29.20553 > 192.168.0.3.2323: Flags [P.], seq 61320:62780, ack 1, win 5840, length 1460
00:00:00.000029 IP 192.168.0.3.2323 > 192.168.0.29.20553: Flags [.], ack 62780, win 64240, length 0
00:00:00.809691 IP 192.168.0.29.20553 > 192.168.0.3.2323: Flags [.], seq 62780:64240, ack 1, win 5840, length 1460
00:00:00.000031 IP 192.168.0.3.2323 > 192.168.0.29.20553: Flags [.], ack 64240, win 64240, length 0

What this shows is that the esp is sending two 1460-byte packets in fairly short succession (pretty consistently 11-12ms inter-arrival time) but then waits for 0.8 seconds. Sounds like nagle to me. But the 0.8s delay indicates some problem. The linux box clearly sends acks very promptly so it cannot be taking 0.8 seconds for the esp to receive the acks. Something else in the firmware must be stuffed-up.

You guys are using WPA-PSK encryption on the wifi, right?

Next up I'll try the sample provided by Espressif_Faye...

Statistics: Posted by tve — Wed Apr 01, 2015 2:39 pm

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

2015-04-01T11:34:03+08:00

Hi, tve,

Thanks for your interest in ESP8266.

Please refer to this demo http://bbs.espressif.com/viewtopic.php?f=21&t=320

Regards,
Faye

Statistics: Posted by ESP_Faye — Wed Apr 01, 2015 11:34 am

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

2015-04-01T03:34:22+08:00

I see, I will try that this evening if have a moment.

Statistics: Posted by tve — Wed Apr 01, 2015 3:34 am

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

2015-04-01T01:44:01+08:00

tve, change your test from just sending hello to something larger, like about 64 bytes long.

as you said, it is not about server not sending ack, but I think the esp is using nagle algorithm (which I think should be disabled).

on my original test, I was sending like 2 bytes at a time, and when I changed to 256 bytes at a time, it executed faster.

Statistics: Posted by doughboy — Wed Apr 01, 2015 1:44 am

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

2015-03-31T23:37:15+08:00

Thanks, that's interesting. I suppose 1Mbps / 8bits/byte / 1420 packet length = 88 packets/sec. Can you show the source code for your app or at least for the section that does the sending?

Statistics: Posted by tve — Tue Mar 31, 2015 11:37 pm

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

2015-03-31T15:54:05+08:00

Here is my test bin I'd like to share.. Simple test to get 1Mbps tx speed, er.. maybe depend on network condition..

download test bin to flash and input as below through UART, baudrate 74880 which is original ..I didn't change it...
step 1. input "op -S -o 1" from UART to set as station mode
step 2. input "ap -C -s ROUTER_SSID -p ROUTER_PASSWORD" to connect to your router
step 3. create a TCP server in your PC
step 4. input "tcp -W -i TCP_SERVER_IP -p TCP_SERVER_PORT -n 1 -c 500 -l 2920" to create a TCP connection and send data.. see the receive speed of PC TCP server.

My test result as the picture

bin_test_tx.zip

Statistics: Posted by Her Mary — Tue Mar 31, 2015 3:54 pm

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

2015-03-31T14:31:34+08:00

Actually the *proof* that the problem has nothing to do with TCP ACKs is very simple. Run two "nc esp8266 23" connections at the same time. The acks for these two connections are completely independent. The buffers are also independent. Thus the two connections should not influence one-another and the esp8266 should send packets at twice the rate as with one connection. However, observation shows the opposite: the number of packets sent by the esp8266 remains the same, each connection goes at half the speed. This would not be the case if the ACK round-trip delay was the issue! You have a bug!

Statistics: Posted by tve — Tue Mar 31, 2015 2:31 pm

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

2015-03-31T14:23:53+08:00

I'm sorry, but waiting for the TCP ACK does not explain why the esp8266 is so slow. I just recompiled my test (which is still freely available at https://github.com/jeelabs/ESP8266-bandwidth) with the 1.0 SDK and despite my server sending an ACK immediately (it gets enqueued in microseconds) the esp8266 can't send any faster than one packet every ~200ms. Look at the tcpdump snippet in the first post of this thread!

What do you mean by "if you send two packets each time"? The documentation for espconn_sent clearly states that one is not allowed to send a second packet until one receives the sent_callback. All my code does is send out "Hello" as fast as it's allowed, here's my callback handler:

Code:

static void ICACHE_FLASH_ATTR serverSentCb(void *arg) {
  sendpacket(arg);
}

where sendpacket bascillay just does

Code:

sint8 result = espconn_sent(conn, "HEllO\n", 6);

The whole program is just 78 lines. You claim that the esp8266 can do better, please try it yourself and tell us what you see (perhaps with some tcpdumps) or change the program to do better!

Statistics: Posted by tve — Tue Mar 31, 2015 2:23 pm

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

2015-03-20T10:12:03+08:00

Hi,

Thanks for your interest in ESP8266 !

ESP8266 RAM is limited, so we only have 2*2920 bytes send buffer for each TCP connection. TCP can't send further data if send buffer is full. After recv ACK, send buffer will free ACKed data, then application can send further data.

That's why we need to wait for TCP ACK, because our buffer is limited.

And yes, TCP ACK usually got in 200ms, but if you send two packets each time, TCP ACK will response immediately, then application can send further data immediately, too.

Statistics: Posted by ESP_Faye — Fri Mar 20, 2015 10:12 am

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

2015-03-20T05:33:58+08:00

there should be no delay if esp8266 is not using nagle algorithm right?

I don't think it is a question of sending one packet or two packet each time. At the application level, it is sending the packet consecutively, immediately one after another.
But it seems esp8266 waits for the ACK after each send, and hence it is esp8266 that is not sending the packets immediately because it waits for ack causing the delay.

Statistics: Posted by doughboy — Fri Mar 20, 2015 5:33 am

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

2015-03-19T11:30:19+08:00

the transmission speed depends on TCP ACK ，which usually be 200ms to get one if you send a packet.. but if you send two packets every each time，it will response TCP ACK immediately..

Anyway, I tested it in WLAN.. not bad ..

Statistics: Posted by Her Mary — Thu Mar 19, 2015 11:30 am

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

2015-03-19T00:25:58+08:00

jayc75 wrote:
the delay added by the lower level code is 20ms it is documented !

ok, I see it in documentation, But that is for CIPMUX=0 mode and for pure client mode only.

On my use, I have a tcp server that accepts connections, once a connection is received, the client is created, and that operates in CIPMUX=1 mode, hence the 20ms delay does not apply.

but yes I do agree there should be no delay added, not even 1ms.

fwiw, if delay is 20ms, then you should be able to get closer to 50 packets per second.
before I did my optimization, I was getting about 5 packets per second, so the delay I experience is more like 200ms.
what kind of delay are you experiencing on CIPMUX=0 mode? exactly 20ms?

Statistics: Posted by doughboy — Thu Mar 19, 2015 12:25 am

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

2015-03-18T18:27:12+08:00

the delay added by the lower level code is 20ms it is documented !

Statistics: Posted by jayc75 — Wed Mar 18, 2015 6:27 pm

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

2015-03-18T13:16:59+08:00

ok, I optimized my arduino code to buffer send data 256 bytes at a time.
and for the above example that sends 280 bytes of data that for split into 52 CIPSENDs that used to take 10 seconds, now use 1 CIPSEND and time is less than 1ms. So I don't think there is a hardcoded 200ms delay for each cipsend, but something in the lower level code is adding delay for consecutive cipsend with small number of bytes.

Statistics: Posted by doughboy — Wed Mar 18, 2015 1:16 pm

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

2015-03-18T02:38:48+08:00

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.

Statistics: Posted by doughboy — Wed Mar 18, 2015 2:38 am

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

2015-03-17T22:53:43+08:00

Espressif_Faye wrote:
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.

Statistics: Posted by tve — Tue Mar 17, 2015 10:53 pm

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

2015-03-05T12:13:21+08:00

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

Statistics: Posted by doughboy — Thu Mar 05, 2015 12:13 pm

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

2015-03-05T12:10:45+08:00

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

analog input 0 is 98

analog input 1 is 137

analog input 2 is 159

analog input 3 is 114

analog input 4 is 247

analog input 5 is 184

Statistics: Posted by doughboy — Thu Mar 05, 2015 12:10 pm

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

2015-03-05T11:53:49+08:00

Espressif_Faye wrote:
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.

Statistics: Posted by doughboy — Thu Mar 05, 2015 11:53 am

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

2015-02-28T11:20:32+08:00

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 !

Statistics: Posted by ESP_Faye — Sat Feb 28, 2015 11:20 am

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

2015-02-25T15:05:49+08:00

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?

Statistics: Posted by tve — Wed Feb 25, 2015 3:05 pm

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

2015-02-25T10:57:07+08:00

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 ~

Statistics: Posted by ESP_Faye — Wed Feb 25, 2015 10:57 am

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

2015-02-22T14:21:33+08:00

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!

Statistics: Posted by tve — Sun Feb 22, 2015 2:21 pm

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

2015-02-20T14:54:42+08:00

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:

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

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

Statistics: Posted by tve — Fri Feb 20, 2015 2:54 pm