ntptime (peterhinch)

[davefes]

After running this version without any problems for >6months, I am now experience a low-success rate at getting NTPtime. Both ESP32 and ESP32 SPIRAM variants.

I have tried extending the retry time out to 70 seconds to no apparent improvement.

Just wondering if other people are having problems getting NTPtime recently.

[beetlegigg]

I have a rpi picoW board that runs the Peter Hinch NTPtime every night so that the time never drifts on its internal RTC and it appears to be still running and showing the correct time on my display screen. Checking my code I see the function that gets the NTP time can return True or False, but the calling of that function has been put in a loop to await a True response so I cant be sure that it did not loop a few times before getting the time but its not stuck in an endless loop. So its appears OK for a rpi pico at least. However the MP version on that board has been left at V1.20

[zcattacz]

Do you connect wifi on demand or maintains a live link ? If there is a network issue, resolve the network issue instead of turning it into a NTP issue ? How about logging pings to the gateway or dns test first before initiating the ntp request?

[glenn20]

@DaveFS - if you are bringing your network interface up to run settime(){as suggested by @zcattacz), could it be that you are running into this issue reported by @peterhinch : https://github.com/orgs/micropython/discussions/13688. ie, your interface may not be fully initialised when you call ntptime.

[davefes]

@zcattacz I connect on demand. Reverting to the official ntptime on a generic ESP32 works. I will consider pinging 8.8.8.8 before continuing.
@glenn20 I am calling ntptime immediately after connecting, so thanks for the heads-up. Any other suggestions, other then pinging the nameserver? Maybe, just needs a few seconds delay.

[zcattacz]

I adapted uping for async single packet ping https://github.com/zcattacz/uping_as . You can have a try if needed. It won't lock when waiting for response. Domain resolving is also kind of ping to your DNS server, it might lock, I am not sure.

[davefes]

@zcattacz thank you for that, will investigate tomorrow. I have been running a test for the last hour with Peter Hinch's version every 70 seconds with one error on generic v1.22.1

[peterhinch]

Calling an NTP server too frequently can lead to it rejecting attempts.

[davefes]

I had been using 20 second retries until reading another comment that 64 seconds was the minimum, so made it 70 seconds. I could change to one try a day and accept some small drift as these ESP32s don't go to sleep.

[davefes]

Thought I would start with uPing. I get the odd missing packet on 8.8.8.8 and also pool.ntp.org and sometimes 0 packets. So, how can I be sure if I query pool.ntp.org at any particular instance that he will respond?

I currently try accessing pool.ntp.org 5 times with 70 second wait periods, then machine.reset(). That even fails sometimes.

Maybe, a DS3231, accept +/- 1 minute/year and do a annual "time-sync".

[beetlegigg]

Just a thought. Maybe your router has an inbuilt time server. My Fritzbox router does and once I realised it (for some reason I was reading the manual) I usually used this instead of reaching out to an ntp server on the web.

[davefes]

The laptop is on a cellular modem. The ESP32 is on the HUWAEI dongle.

[davefes]

Note there are restrictions on how fast you can poll a NTP server. I often find that if it fails once then it will fail 5 times until you go away and do something else.

[davefes]

Now it is 10ms on the ESP32.

[zcattacz]

Does the ~10ms latency stick when it happens? If you can repeat the HUWAEI dongle madness on pc, maybe try reinitializing the dongle link until you have a good one.
Place it in a different direction, orientation, location? Keep the antenna away from metal structure? Look for the magic massage :-p

I understand it will block. Shots in a row, doesn't change the fact that next try needs to be paced, I just hope it might increase the chance our packet successfully reach the server, since your link is losing packets.

[davefes]

Does the ~10ms latency stick when it happens?

Not sure what you mean. There doesn't seen to be any relationship between the fails and the latency.

However ... I have two of these dongles mounted on a fibreglass pole on the roof fed by long USB cables ... so I tried pinging 8.8.8.8 with the laptop on both networks. One dongle no problem. The other dongle (the one I am having the problem with) even after 15-30 seconds gives me:

64 bytes from 8.8.8.8: icmp_seq=164 ttl=247 time=73.7 ms
From 192.168.10.1 icmp_seq=165 Destination Net Unreachable
From 192.168.10.1 icmp_seq=167 Destination Net Unreachable
From 192.168.10.1 icmp_seq=168 Destination Net Unreachable
64 bytes from 8.8.8.8: icmp_seq=169 ttl=247 time=151 ms

This dongle is slightly lower and "pointing' in a different direction than the one that seems to work better. You seem to have identified a problem I have been struggling with for several years now.

I also have another cellular modem but at 16Watts/hour I don't leave it running 24/7 (off-grid).

I think I now know what I am up against ... thank you.

[peterhinch]

Maybe your router has an inbuilt time server.

There is a lot to be said for doing this. I have a Raspberry Pi running 24/7. Among other tasks this runs one.