Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.5k
tests/extmod: Make test time_res.py more deterministic.#18347
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
codecovbot commentedOct 30, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## master #18347 +/- ##======================================= Coverage 98.38% 98.38% ======================================= Files 171 171 Lines 22297 22297 ======================================= Hits 21936 21936 Misses 361 361 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Replace sample-counting approach with direct monotonicity andresolution tests. The previous method mixed ticks_ms() and RTCclock sources which could drift, causing non-deterministic resultsacross platforms. New approach directly tests that time functionsadvance at their documented rates.Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
14b63f8 to6453feeCompare
Uh oh!
There was an error while loading.Please reload this page.
Summary
This PR improves the determinism of
tests/extmod/time_res.pywhich has been failing intermittently on Windows CI.Problem: The test was counting unique values returned by time functions over a 2.5-second window, expecting at least 3 unique values for second-resolution functions (
gmtime(),localtime()). This approach had fundamental issues:Clock source mismatch: Used
ticks_ms()(system tick timer) to measure test duration while samplinggmtime()/localtime()(RTC). On embedded platforms these are different hardware clocks that can drift relative to each other.Race conditions: To see 3 unique second values in a 2.5-second window, the RTC must advance by >2.0 seconds. Due to timing overhead and clock drift, the test could observe only 2.4 seconds of RTC time, causing spurious failures.
Windows-specific issues: Windows system clock has ~15ms granularity, making the sample-counting approach particularly unreliable.
Recent CI failures:
Attempted Solution: Replace with direct resolution and bounds testing:
Testing
The test logic here is hopefully more robust:
time(),gmtime(),localtime()): Sleep 1200ms and verify value changed within 1-2.4 second rangeticks_ms,ticks_us,ticks_ns): Sleep 150ms and verify advanced within 80%-200% of expectedticks_cpureturns 0This approach aims to tests the actual contract of each function (proper time resolution within bounds) rather than a proxy metric (sample counts in specified window).
The test should hopefully now pass reliably on all platforms including Windows, Unix, and embedded targets without platform-specific skip lists.