ESP8266 Developer Zone

Re: ESP8266 strange "SEND OK" delay

2017-12-04T17:26:28+08:00

This must be the bug of the year.

As you can see in my simple test data sent has already arrived at the server and the HTTP data has been parsed and a reply as been put in the TCP response stream and even reached back to the ESP8266 and only then you start to get a "SEND OK".

Espressif have to sit down with developers and explain what is going on. This is not something users should have to report and verify over and over again without appropriate response.

"SEND OK" should NOT rely on active communication back from a remote peer. It should rely on data being SENT on the TCP level where user has no influence.

As you can clearly see - data has been sent without the ESP8266 immediately confirming it.

Would be interesting to see a principle flowchart of the ESP8266 software when sending.

Statistics: Posted by Flodis — Mon Dec 04, 2017 5:26 pm

Re: ESP8266 strange "SEND OK" delay

2017-11-29T14:23:48+08:00

Dear Flodis,

The problem is the response should not be the "ACK". There is already TCP and packages have already been ACK;ed. The user should not have to send data back to confirm what has already happened on the TCP level.

You may misunderstand my word. Yes, the user needs not to send data back to get an ACK. But if the user keeps sending data back, the ACK will be sent to the ESP8266 together with the data, so it may be quicker. That is my point.
I think the 300ms is because of the ACK delay, maybe you can capture TCP packets by wireshark to see if it costs 300ms to send an ACK back.

Statistics: Posted by Her Mary — Wed Nov 29, 2017 2:23 pm

Re: ESP8266 strange "SEND OK" delay

2017-11-29T07:48:54+08:00

Maybe sending more data will trigger the send? Is there some buffer level that can speed this up to get rid of the 300 ms time delay?

Statistics: Posted by Flodis — Wed Nov 29, 2017 7:48 am

Re: ESP8266 strange "SEND OK" delay

2017-11-14T22:30:56+08:00

Her Majesty wrote:
TCP is a reliable communication which needs ACK.
"RECV XXX bytes" means that ESP8266 got xxx bytes from UART and send it through TCP.
"SEND OK" means that ESP8266 received the TCP ACK.
I guess that if your remote peer also keep sending data to ESP8266, the ACK will be sent to the ESP8266 sooner.

Thank you for the fast reponse.

The problem is the response should not be the "ACK". There is already TCP and packages have already been ACK;ed. The user should not have to send data back to confirm what has already happened on the TCP level.

Sending data back to confirm something is typically already what you do in HTTP traffic. But the "SEND OK" should not be triggered by sending back events. As you can see after some time you get a "SEND OK" even without any response back. That is basically a "SEND OK" without ACK. The long delay is like an ACK timeout but it has no error. It is odd.

Data has already been sent. You have to check the TCP layer to confirm data has been sent. Not rely on some clear text response in packages being returned.

Then data transfers would be super fast if you, please, make the "SEND OK" trigger by TCP send completed.

Sending once every 5ms when data has been sent instead of 290ms would be a factor X 60 in transfer speed!

Who objects to that?

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

Re: ESP8266 strange "SEND OK" delay

2017-11-14T22:18:38+08:00

TCP is a reliable communication which needs ACK.
"RECV XXX bytes" means that ESP8266 got xxx bytes from UART and send it through TCP.
"SEND OK" means that ESP8266 received the TCP ACK.
I guess that if your remote peer also keep sending data to ESP8266, the ACK will be sent to the ESP8266 sooner.

Statistics: Posted by Her Mary — Tue Nov 14, 2017 10:18 pm

Re: ESP8266 strange "SEND OK" delay

2017-11-29T07:42:51+08:00

Here is another test approach:

First I send it a completely fine AT+CIPSEND=0, and while it is busy sending i just send it a ms:[] text string to see what it responds while busy.
...
Recv 79 bytes
ms:[36]
busy s...
ms:[60]
busy s...
ms:[94]
busy s...
ms:[128]
busy s...
ms:[153]
busy s...
ms:[188]
busy s...
ms:[223]
busy s...

SEND OK
ms:[248]
ERROR
...

It looks like the "SEND OK" is the actual condition to accept new messages and there is no hidden internal state where it might be ready to receive more commands - before that event. After SEND OK it is no longer busy - now my test command is treated as a command and generates an appropriate error.

The conclusion is: If you want to stream in some 32 byte chunks using AT+CIPSEND you will not be able to transfer more than 100 to 150 bytes per second.

Now. With the exact same http request having HTTP response data returned really fast from the server:

...

Recv 79 bytes
ms:[24]
busy s...

SEND OK

+IPD,0,183:HTTP/1.1 204 No Content
Content-Type: text/plain; charset=utf-8
Date: Tue, 14 Nov 2017 09:40:59 GMT
Server: X54JetStream
Connection: Keep-Alive:
Keep-Alive: timeout=15, max=1000

ms:[60]
ERROR
...

After 60 ms we got BOTH the SEND OK and the entire HTTP response back. And following the same logic. Before sending my false timestamp strings will be rejected with "busy" but after SEND OK the ESP8266 also have an opinion on the quality of the false commands and you get an ERROR.

It is all a mighty strange observation????

Forgot to mention the firmwares of some devices tested:

Code:

AT+GMR
AT version:0.40.0.0(Aug  8 2015 14:45:58)
SDK version:1.3.0
Ai-Thinker Technology Co.,Ltd.
Build:1.3.0.2 Sep 11 2015 11:48:04
OK

Code:

AT+GMR
AT version:1.1.0.0(May 11 2016 18:09:56)
SDK version:1.5.4(baaeaebb)
compile time:Mar  9 2017 19:22:12
OK

Statistics: Posted by Flodis — Tue Nov 14, 2017 6:11 pm

ESP8266 strange "SEND OK" delay

2017-11-29T07:29:25+08:00

Using CIPSEND there is a long 290ms delay between the "Recv NN bytes" and the "SEND OK" confirmation.

The delay is much shorter if there is a response from a web server or similar. As soon as data is coming back from the destination server the "SEND OK" also returns. If the response time is 20ms the SEND OK is also returned fast and comes first, with no time separation from received remote data.

The images below show sampled voltages on serial port Tx, Rx physical pins on the device - The blue signal being data sent to the ESP8266 and yellow being the response.

If server response is delayed the "SEND OK" comes by itself after 290ms.

If remote server responds in 20ms the "SEND OK" returns much faster in front of the response data.

It looks like the ESP8266 "forgets" to flush the input stream. With no remote response, flushing is finally done by an internal timer after 290ms. When a remote response returns earlier than the 290 ms, the ESP8266 is forced to send data back - starting with "SEND OK".

As the delay inhibits further sending until you have data on the receive stream it makes streaming data out in small portions extremely slow for no good reason. "SEND OK", I think, should be confirmed as soon as data is in the ESP8266 output buffer or possibly when the buffer has been sent over TCP. It would be much more effective to only rely on a "buffer full" error when you request a certain number of bytes sent in the initial CIPSEND command and the output buffer has not yet room for the number of bytes requested. It should just stream out as fast as it can an not care if anything comes back from the remote peer.

Statistics: Posted by Flodis — Tue Nov 14, 2017 9:51 am