[Explained] time.sleep() oddities

Post Reply

Print view

5 posts • Page 1 of 1

hippy: Posts: 19831; Joined: Fri Sep 09, 2011 10:34 pm

[Explained] time.sleep() oddities

Quote

Thu Nov 06, 2025 9:53 pm

Is it just me or are 'time.sleep(0.00nnnn)' millisecond / microsecond delays unreliable ...

Code: Select all

import time
for delay in [0.002000, # 2
 0.001750, # 1.75
 0.001500, # 1.5
 0.001250, # 1.25
 0.001000, # 1
 0.000750, # 0.75
 0.000500, # 0.5
 0.000250, # 0.25
 0.000000]: # 0
 start = time.ticks_us()
 time.sleep(delay)
 end = time.ticks_us()
 print("{:8.6f} {:>4} us {} {}".format(delay, end - start, start, end))

Code: Select all

 .-------------------.
 | RP2040 | RP2350B |
.----------|---------|---------|
| 0.002000 | 2073 us | 1528 us |
| 0.001750 | 1063 us | 516 us |
| 0.001500 | 1091 us | 619 us |
| 0.001250 | 949 us | 588 us |
| 0.001000 | 897 us | 642 us |
| 0.000750 | 108 us | 44 us |
| 0.000500 | 71 us | 62 us |
| 0.000250 | 106 us | 42 us |
| 0.000000 | 66 us | 65 us |
`----------^---------^---------'

It all seems a bit random - I got "0.001500 96 us" on one run.

Last edited by hippy on Fri Nov 07, 2025 7:24 am, edited 1 time in total.

katak255: Posts: 916; Joined: Sun Apr 07, 2024 3:29 pm

Re: time.sleep() oddities

Quote

Fri Nov 07, 2025 12:41 am

Problem is probably due to this:

https://github.com/micropython/micropyt ... /modtime.c

Assuming it uses mp_hal_delay_ms, this goes to:

https://github.com/micropython/micropyt ... phalport.c

and we have millisecond granularity. I guess they don't expect folks to use time.sleep() for under 1 ms timings. :)

Mike**K: Posts: 308; Joined: Fri Dec 16, 2022 3:08 pm

Re: time.sleep() oddities

Quote

Fri Nov 07, 2025 1:12 am

Aren't print and format going to affect timings?

Pi5_User: Posts: 142; Joined: Wed Aug 28, 2024 3:49 pm

Re: time.sleep() oddities

Quote

Fri Nov 07, 2025 6:20 am

As a matter of curiosity do you get similar resukts using

Code: Select all

time.sleep_ms()

instead?

hippy: Posts: 19831; Joined: Fri Sep 09, 2011 10:34 pm

Re: time.sleep() oddities

Quote

Fri Nov 07, 2025 7:23 am

katak255 wrote: ↑
Fri Nov 07, 2025 12:41 am
Problem is probably due to this ... https://github.com/micropython/micropyt ... /modtime.c ... and we have millisecond granularity. I guess they don't expect folks to use time.sleep() for under 1 ms timings. :)

Perhaps so, but that's a ridiculous implementation if you ask me. And I am not sure exactly what it's doing with such random and unpredictable results.

Doing an alarm event delay for anything above a millisecond and more accurate cycle count or polled timer delay for less is common practice, and it's usually acceptable to round to four significant digits to avoid unnecessary cycle count or polled timer delays, so I don't know why they didn't do that.

I guess one problem is the MicroPython team aren't RP2 experts. They also have this dogmatic 'lowest common denominator' approach which is why we can't have float PWM frequencies even though the RP2 is quite capable of them.

Mike**K wrote: ↑
Fri Nov 07, 2025 1:12 am
Aren't print and format going to affect timings?

No, I note the time before and immediately after the sleep and only then do the slower and variable time 'print' and 'format'. I don't consider timer wraparound but do print both start and end values so I can tell when that has happened.

Pi5_User wrote: ↑
Fri Nov 07, 2025 6:20 am
As a matter of curiosity do you get similar resukts using ... time.sleep_ms() ... instead?

The 'time_ms' doesn't allow sub-milliseconds so that's no use here, but 'time_us' does seem to work -

Code: Select all

 .-------------------.
 | RP2040 | RP2350B |
 .----------|---------|---------|
 | 2000 us | 2080 us | 2035 us |
 | 1750 us | 1788 us | 1770 us |
 | 1500 us | 1537 us | 1519 us |
 | 1250 us | 1289 us | 1270 us |
 | 1000 us | 1024 us | 1027 us |
 | 750 us | 778 us | 765 us |
 | 500 us | 531 us | 523 us |
 | 250 us | 273 us | 266 us |
 | 0 us | 23 us | 20 us |
 `----------^---------^---------'

That's in line with what I was expecting; a fairly accurate delay plus a few tens of microseconds of overhead.

I am guessing that for 2 ms, and probably above, it splits those into an alarm timer chunk and whatever is left over. That's what I would have expected for all the sleeps.

Thanks everyone.