time.sleep() truncates to 0

[caternuson]

This shows the behavior which occurs near max resolution:

Adafruit CircuitPython 2.1.0 on 2017-10-17; Adafruit Trinket M0 with samd21e18
>>> import time
>>> t1 = time.monotonic(); time.sleep(0.1); t2 = time.monotonic(); t2-t1
0.0991211
>>> t1 = time.monotonic(); time.sleep(0.01); t2 = time.monotonic(); t2-t1
0.00878906
>>> t1 = time.monotonic(); time.sleep(0.001); t2 = time.monotonic(); t2-t1
0.0
>>> 

And some key bits of code are here:
https://github.com/adafruit/circuitpython/blob/master/shared-bindings/time/__init__.c#L76
which calls here:
https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/common-hal/time/__init__.c#L37
with an implicit cast from float to uint32_t occurring in the process which results in the truncation.

[tannewt]

I don't think this is an issue. We cannot guarantee timings from Python, especially short ones like this, because the VM is slow and work (like USB) happens between VM steps. This truncation is a combination of both sleep being short and monotonic's millisecond resolution. There is no way its actually taking no time.

Please reopen if there is a reason you need this fine timing.

[dhalbert]

(@caternuson and I had a chat in #circuitpython about this last week).

We could, though, at least round to the nearest millisecond. The problem is the truncation: 0.001 as a CPy float is slightly less than 0.001 in decimal, and gets truncated to 0 milliseconds. time.sleep(0.001) will not sleep at all; time.sleep(0.001000001) will sleep for 1 millisecond. And time.sleep(0.1) will sleep for 99 milliseconds, when it could more accurately sleep for 100.

The code comes from MicroPython which just truncates. But they have sleep_ms() and sleep_us() routines, which take integer args (works fine when floats are not implemented). I think the last one does a busy-wait.

[tannewt]

I'm not convinced we can provide millisecond accurate sleeps anyway because of interrupts and other background work like mass storage. Rounding isn't important when we can't measure it accurately enough anyways. We could introduce a `precisetime` module for more accurate sleeps but I'm not sure we need it.

…

On Tue, Nov 14, 2017 at 8:16 AM Dan Halbert ***@***.***> wrote: ***@***.*** <https://github.com/caternuson> and I had a chat in #circuitpython about this last week). We could, though, at least round to the nearest millisecond. The problem is the truncation: 0.001 as a CPy float is slightly less than 0.001 in decimal, and gets truncated to 0 milliseconds. time.sleep(0.001) will not sleep at all; time.sleep(0.001000001) will sleep for 1 millisecond. And time.sleep(0.1) will sleep for 99 milliseconds, when it could more accurately sleep for 100. The code comes from MicroPython which just truncates. But they have sleep_ms() and sleep_us() routines, which take integer args (works fine when floats are not implemented). I think the last one does a busy-wait. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#429 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqTQMtix0FWF34AozyUjWMsiPA9IJks5s2bzegaJpZM4QYqNf> .

[caternuson]

From my point of view this isn't an issue due to a need for precise / accurate timing, like for bit banging some protocol. It's more of getting an unexpected behavior due to the truncation. For example, consider this very simple averaging of some sensor reading:

avg = 0
for i in range(20):
    avg += sensor.noisy_analog_reading
    time.sleep(0.001)
avg /= 20

I'd expect that to average over ~20ms, but instead it will be much less since the time.sleep() is effectively 0.

I also don't (currently) think there's a need for precise time, it's more a question of how things behave as the delay time approaches the lower limit.

[tannewt]

I don't think time.sleep(0.001) will be effectively 0. Have you tried measuring it with a saleae and setting a pin? That may be more reliable than monotonic.

…

On Tue, Nov 14, 2017 at 8:59 AM Carter Nelson ***@***.***> wrote: From my point of view this isn't an issue due to a need for precise / accurate timing, like for bit banging some protocol. It's more of getting an unexpected behavior due to the truncation. For example, consider this very simple averaging of some sensor reading: avg = 0for i in range(20): avg += sensor.noisy_analog_reading time.sleep(0.001) avg /= 20 I'd expect that to average over ~20ms, but instead it will be much less since the time.sleep() is effectively 0. I also don't (currently) think there's a need for precise time, it's more a question of how things behave as the delay time approaches the lower limit. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#429 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqabV03KhPyTkwI3I5HZVdbvd5P6zks5s2ccEgaJpZM4QYqNf> .

[caternuson]

Tester func:

def toggler(t, n):
    t1 = time.monotonic()
    for i in range(n):
        pin.value = True
        time.sleep(t)
        pin.value = False
        time.sleep(t)
    t2 = time.monotonic()
    return (t1,t2,t2-t1)

Result from REPL:

>>> toggler(0.1,20)
(1086.49, 1090.46, 3.96143)
>>> toggler(0.01,20)
(1093.97, 1094.33, 0.359863)
>>> toggler(0.001,20)
(1096.48, 1096.49, 0.00878906)
>>> toggler(0,20)
(1100.21, 1100.22, 0.00683594)

Result from saleae for toggler(0.001,20):

Result from saleae for toggler(0,20):

[dhalbert]

@caternuson Try it with toggler(0.00101, 20) and I think that will show the difference.

[dhalbert]

The line mentioned above (https://github.com/adafruit/circuitpython/blob/master/shared-bindings/time/__init__.c#L76) is:

    common_hal_time_delay_ms(1000 * seconds);

seconds is a float. If it's slightly less than 0.001 decimal, then the result of the multiplication will be <1. common_hal_time_delay_ms() takes a uint32_t. The implied cast will truncate 0.999... to 0.

[caternuson]

REPL:

>>> toggler(0.00101,20)
(3361.62, 3361.66, 0.0410156)

saleae: