Unexpected time module behavior?

[reply2jh]

The following seems to suggest that the time.time() function passes time faster than time.monotonic

import time
sleeptime = 300
monotime = time.monotonic()
clocktime = time.time()
print('starting %ds wait' % sleeptime)
time.sleep(sleeptime)
monotime2 = time.monotonic()
clocktime2 = time.time()
monoElasped = monotime2 - monotime
clockElasped = clocktime2 - clocktime
print('Mono elasped %f\nClock elasped %d\n' % (monoElasped, clockElasped))

On 4.x I get:
starting 300s wait
Mono elasped 299.999504
Clock elasped 306

the "error" is around ~5s in 5 min, ~10s in 10min etc
for this code, I would have expected them to return the same duration. Is that correct?

[dhalbert]

time.monotonic() counts 1ms clock ticks but due to interrupt handling it can miss some. time.time() uses the on-chip real-time clock (RTC). We are going to make everything use the RTC, so we can do real processor sleep, at lower power, but we haven't done that yet. See #696.

Same issue as #876.

[reply2jh]

Thanks that makes sense. So then it is probably a coincidence that for my PyPortal the time.monotonic() seems to keep almost perfect time with respect to the atomic clock and time.time() runs quite fast.

[dhalbert]

The SAMD51 chip has a bug: the main clock that we're using (DFLL48M) cannot be locked to the crystal oscillator on the board. So the accuracy you're seeing is probably accidental.

[DavePutz]

I re-tested this one on 6.0. It looks like perhaps it can be closed. Here are the results on various platforms:
SAMD21
starting 300s wait
Mono elasped 300.002789
Clock elasped 300

SAMD51
starting 300s wait
Mono elasped 300.175905
Clock elasped 300

NRF52840
starting 300s wait
Mono elasped 300.000858
Clock elasped 300

ESP32S2
starting 300s wait
Mono elasped 300.004888
Clock elasped 300

[tannewt]

Thanks @DavePutz! I agree it can be closed. Both monotonic and time use the RTC now.