Delays, delays

[kjm]

Any fans of Marvin-the-Martian on this forum? Like Marvin I'm haunted by delays.

Looking to save some battery & impatient with the long, useless, waits for some _urequests OSErrors, I opted for a

wdt=machine.WDT(timeout=9*1000)

9s timeout for GETS & POSTS. My GPY/server logs quickly revealed that some uploads from the GPY were taking 11+ seconds to get to the server. eg: GET sent 23:57:57, received at the server 23:58:08 I can't figure this out! This battery powered setup has no retrys or other subtleties, it just wakes up from deepsleep, does a GET &/or POST via _urequests & deepsleeps. The deepsleep is either immediate or after the 9s wdt timeout.

My question is this. If I power down on a 9s timeout for an apparently failed GET/POST at 23:58:06 how can the GET/POST arrive at the server 2s after that at 23:08:08?

[gt1]

@kjm have you tried mqtt or websockets?
I have played with taking a reading sending via mqtt and going to sleep. Seemed to work very well. Websockets are much faster then get / post from what I have seen.

[crumble]

@kjm

Do they have the same time? ;)
Is there any load on the server?
How much of something is between your server and the device?

[jcaron]

@kjm Are you doing direct requests from your GPy to the server, or is there something else in between?

Do they have the same time?

Is your server timestamp the time the request has been received, or the time it has finished processing? If the latter, does it take time to process all of it?

We're probably missing a bit of context on your setup.

[kjm]

@jcaron Direct from the GPY via CAT-M1 to the server. The server reports data received time & subsequent processing time (usually sub 100ms). We resync the GPY RTC each wakeup so the server/GPY times should agree.

[jcaron]

@kjm A few things to try:

• Check that the GPy actually got the time correctly sync'd. Maybe the GPy doesn't actually get its time right.
• Try to confirm things visually: set the GPy to change the LED colour at the right times to see what happens, and tail -f the logs on the server at the same time, and see if things match.
• You mentions POSTs. Are those large? Is the server timestamp at the beginning of the request (when the TCP connection is established or the POST line is sent, or when the full headers have been received) or when the full request (including all POST data) has been received?
• Is the received POST complete?
• Does this happen on GETs as well?
• You may want to check what tcpdump or Wireshark say (on the server) to see what actually is received (and sent) by the server.

Note that some network providers do have weird stuff like (supposedly transparent) proxies between devices and the rest of the Internet. I believe it's pretty rare nowadays, but IIRC I got bit by something similar recently.