-
Notifications
You must be signed in to change notification settings - Fork 1.3k
time.monotonic_ns is not always monotonic on 5.3.1 #3430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Seems like a concurrency issue when reading the underlying timer(s). |
I had a PyPortal (SAMD51) plugged in and thought it was worth a test to check behaviour there. I'll leave it running for an hour but it looks good so far as there's been no output after 5 mins.
|
The values read would be binary but the problem appears (based on a small sample) on a decimal boundary. This is odd. Is there a "sub timer" used for sub ms part? |
I tested this with a Clue as well. On 5.3.1 the error reproduced immediately, on 6.0.0-beta.0 it ran without error for 10 minutes. It looks like there were significant changes in how time.monotonic_ns is calculated on the nrf52840 port between the two versions. |
@DavePutz Totally, the sleep work I did switched our internal timekeeping to the real time clock on all ports. @kevinjwalters I'm closing this because it is fixed for 6.x. |
There's something afoot with Perhaps this should go in whatever test suite there is to detect and prevent this from reoccuring? |
Assuming the order is well defined for evaluation of list elements something odd is going on here as
monotonic_ns()
is briefly jumping backwards:Taking numbers from 4th line of output and adding a space shows this is possibly an issue as the ms portion increments, second line looks like it should be 16600503004000:
The text was updated successfully, but these errors were encountered: