ESP8266 Community Forum

- Sun Jul 05, 2020 6:10 pm #87779 I'm using an ESP12 to monitor the LED pulses from an electricity meter, sending GET requests to PHP running on a Raspberry Pi, using the WiFiClient.
It works fine, sending data as expected, except, occasionally the "round trip time" (time from sending to receiving the reply from the RPi), which is usually around 10 to 50 milliseconds, will have throw up a value of 2K to 3K milliseconds, ie up to 3 SECONDS.
I put a counter in the "reply wait loop" to make sure it was actually waiting, and the ESP hadn't meandered off somewhere.... all good, so looked at the response times from the webserver/PHP end,..... again all good, so Wiresharked the "conversations", and it appears the delay is at the ESP12 end.
Normally from the initial SYN from ESP (start of conversation) to the FIN (end) packets is real quick, then I get these odd pauses....
I can add all sorts of supporting info, code, stats, etc if this grabs anyone's interest, but hopefully the Wireshark capture image should demonstrate the problem.
Anybody got any ideas as to what's going on there? I've tried adding setNoDelay(true) and/or setSync(true) but nothing I did would get rid of these excessive times, sometimes around 5% of the transmissions.

Attachments

Wireshark capture - line 760

- Tue Jul 07, 2020 1:59 am #87794 setNoDelay should have no real effect other than a few milliseconds. It controls the internal "Nagle" algorithm of TCP which buffers many small packets into one single send to reduce overhead. I don't know what the exact value is that the controls the time "window", but it is very small compered wiht you issue.

Without seeing your code, anyhting else is guesswork.

- Wed Jul 08, 2020 5:39 am #87809 I guess the Wireshark screengrab, tells the story, but the relevant section of code is below.

Referring to the WS screengrab, the [SYN], [SYN ACK], [ACK] frames are the wifiClnt.connect statement, then [PSH ACK] (on the wire 2.7 seconds later) is the wifiClnt.print (also tried wifiClnt.write just in case), then the code sits in a loop awaiting a reply from the server. 99+ times out of 100, this is all over in a flash, occasionally it isn't. I'm sure the code is OK (but you can never tell) as it works for the vast majority of the transmissions, and was beginning to think maybe a library issue, or a huge network congestion at the point of attempting the send.

I'm convinced that there's little I could do in code which would cause such a delay as seen on the wire, but grateful for any advice.

Code: Select all   
    timeVar1 = millis();                                            //  Start time
    ok = 1;
   
    if (wifiClnt.connect(phpServer,80)) {                           //  Connect to server
      wifiClnt.print(getData);                                               //  Send GET request
      //wifiClnt.write(getData, gdPtr -1);
      yield();
     
      timeVar = millis();                                                     //  Wait for reply start time
     
      while(wifiClnt.available() == 0) {                             //  Spin here until reply received or timed out
        msNow = millis();                                                   //  Millis now
        delayTime = msNow - timeVar1;                           //  How long so far
        if (delayTime > maxDelay) {                                   //  Been too long?
          ok = 0;                                                                    //  Yes, quit
        } else if (!wifiClnt.connected()) {                            //  If the server has disconnected
          delay(5);                                                                 //  Wait for X ms
          if (wifiClnt.available() == 0) {
            ok = 0;                                                                  //  If still no data, quit
            delayTime = 999;                                                 //  Indicate server disconnection but no data response
          }
        }
        if (ok) {
            yield();                                                          //  WDT
          } 
        } else {
          nwData.timeoutCount++;                               //    increment timed out request counter
          break;                                                              //    and quit waiting
        }
      }



- Wed Jul 08, 2020 9:47 am #87817 When I said "see your code" I meant all of it. It is impossible to diagnose possible timing issues without seeing everything that is going on in the code. There may be nothing wrong with the small amount of code you posted. Plus if i wanted to run it on my own system to try to replicate the problem...only the entire program will do.