ntptime.settime() does not work correctly (Raspberry Pico W)

[devicplan]

In one application, I have the time updated once a day via NTP. After a few days the program crashes. I found out that the call ntptime.settime() is the cause. If I synchronize the time in a loop every two seconds, I get an overflow after a few minutes.

Test program:

import time, ntptime
z = 0
while(True):
ntptime.settime()
time.sleep(2)
z=z+1
print(str("ok"), z)

Error output:
ok 114
ok 115
ok 116
ok 117
Traceback (most recent call last):
File "", line 4, in
File "ntptime.py", line 1, in settime
OverflowError: overflow converting long int to machine word

Is it possible that there is an error in the called function?

Translated with www.DeepL.com/Translator (free version)

[davefes]

When I had some issues on the ESP32 settime() Peter Hinch added the test at the top.

def settime():
    t = time()
    if t < 0:
        return False

    tm = utime.gmtime(t)
    machine.RTC().datetime((tm[0], tm[1], tm[2], tm[6] + 1, tm[3], tm[4], tm[5], 0))

I thought that this change got placed in the code, but not according to:
https://github.com/micropython/micropython-lib/tree/master/micropython/net/ntptime
I also see that def time() has changed since I started using it. Only that it handles different epochs.

[davefes]

Unfortunately, to change that you need to copy ntptime.py add those lines and rename it to my_ntptime.py, place that in your flash filesystem and then import my_ntptime, etc

[peterhinch]

There are circumstances in which the time server returns 0 causing the .time() method to return a large negative number. Hence the need for the test. I think this can occur if you query the time too frequently.

[devicplan]

Thanks for the help.

Also, when the call to the ntptime.settime() function is tested, the program terminates. No error code is output. If the pico is not connected, error -6 comes immediately.

...
while(True):
try:
ntptime.settime() # update time per ntp
except OSError as error:
print(str("errornr="),error)
time.sleep(2)
z=z+1
print(str("round = "), z)

Output:
...
round = 4
round = 5
round = 6
round = 7
round = 8
round = 9
round = 10
round = 11
round = 12
round = 13
round = 14
round = 15
Traceback (most recent call last):
File "", line 33, in
File "ntptime.py", line 1, in settime
RuntimeError: network connection failed

[scruss]

The NTP server is probably sending you a KoD (Kiss-o'-Death) packet to tell you to go away after so many too-frequent attempts. RFC4430: Best Practices tells us:

A client MUST NOT under any conditions use a poll interval less than 15 seconds.

The "after a few days the program crashes" problem is unlikely to be related to NTP. Are you cleaning up any memory allocations?

[davefes]

Yes, thanks for that ... I had been using a retry period of 5 seconds and still got the odd error.

[devicplan]

Thanks for pointing out the polling frequency according to RFC4430. The behavior of my test program with 2 seconds polling interval would be explained.
But why my program, which synchronizes the time only once a day, crashes with exactly the same command ntptime.settime() on a Raspberry Pico W is not clear. If I comment out the command there are no interruptions.
A similar application on an ESP8266 that updates the time every 2 hours with the same command has been running for many months.

[scruss]

Hard to tell without seeing all of your code. Maybe there's a device driver on RP2040 that's leaking memory that isn't on the ESP8266?

Are you using gc? My experience with the Pico W is that an occasional call to gc.collect() (perhaps right before ntptime.settime() is called) can keep programs running longer

[peterhinch]

It's worth being aware that WiFi links aren't necessarily stable over long periods as discussed in my unofficial FAQ. Laptops and tablets have an OS which does a good job of hiding brief outages from the user. Microcontrollers don't have that, and it's your job to maintain connectivity.

[devicplan]

The problem has been solved. After updating the time every 5 minutes for two days, a connection problem was detected. In my test program I had caught the function ntptime.settime(). I had not done that before in my program.
Thanks a lot for your tips and hints. Many greetings Jens

my test program:

...initialization WLAN
while(True):
if(a>300):
z=z+1
a=0
try:
ntptime.settime()
except OSError as error:
print(str("errornr="),error)
print("NTP ok")
time.sleep(1)
a=a+1
print(str("round = "), z, a)
led.on()
time.sleep(0.1)
led.off()

once this error occurred:
round = 230 299
round = 230 300
round = 230 301
errornr= [Errno 110] ETIMEDOUT
NTP ok
round = 231 1
round = 231 2
round = 231 3

[peterhinch]

The behaviour of ntptime.py has caused confusion a number of times in the past. I have raised this issue.

I wrote this version a while ago which addresses some of these issues and also has rudimentary localtime support.

[devicplan]

There are no more crashes since using ntptime.settime() over TRY.