[Python-ideas] millisecond and microsecond times without floats

[Nick Coghlan]

On 27 June 2015 at 05:14, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> I however was thinking about our exchange with Antoine, and his
> surprise that we don't want to use 64-bit value. I guess I nailed the
> issue: I selected "monotonic()" because it seemed the closest to what we
> need, and in my list, our stuff is still "monotonic" in a sense that it
> goes only forward at constant pace. It just wraps around because so is
> the physical nature of the underlying fixes-size counter. Apparently,
> such "extended" treatment of "monotonic" is confusing for people who
> know time.monotonic() and PEP418.
>
> So, looks like we'll need to call our stuff different, I'm going to
> propose ticks_ms() and ticks_us() for MicroPython (hopefully "ticks"
> it's a well-known embedded term, and intuitive enough for other folks,
> at the very least, it's better than Linux kernel's jiffies ;-) ).

I like it - as you say, ticks is already a common term for this, and
it's clearly distinct from anything else in the time module if we ever
decide to standardise it. It also doesn't hurt that "tick" is the term
both LabVIEW (http://zone.ni.com/reference/en-XX/help/371361J-01/glang/tick_count_ms/)
and Simulink (http://au.mathworks.com/help/stateflow/examples/using-absolute-time-temporal-logic.html)
use for the concept.

As a terminology/API suggestion, you may want to go with:

    tick_ms() - get the current tick with 1 millisecond between ticks
    tick_overflow_ms() - get the overflow period of the millisecond tick counter
    ticks_elapsed_ms(start, end) - get the number of millisecond ticks
elapsed between two points in time (assuming at most one tick counter
overflow between the start and end of the measurement)

    tick_us() - get the current tick with 1 microsecond between ticks
    tick_overflow_us() - get the overflow period of the microsecond tick counter
    ticks_elapsed_us(start, end) - get the number of microsecond ticks
elapsed between two points in time (assuming at most one tick counter
overflow between the start and end of the measurement)

The problem I see with "ticks_ms()" and "ticks_us()" specifically is
that the plural in the name implies "ticks elapsed since a given
reference time". Since the tick counter can wrap around, there's no
reference time - the current tick count is merely an opaque token
allowing you to measure elapsed times up to the duration of the tick
counter's overflow period.

I also don't think you want to assume the overflow periods of the
millisecond timer and the microsecond timer are going to be the same,
hence the duplication of the other APIs as well.

Something else you may want to consider is the idea of a "system
tick", distinct from the fixed duration millisecond and microsecond
ticks:

    tick() - get the current tick in system ticks
    tick_overflow() - get the overflow period of the system tick counter
    ticks_elapsed(start, end) - get the number of system ticks elapsed
between two points in time (assuming at most one tick counter overflow
between the start and end of the measurement)
    tick_duration() - get the system tick duration in seconds as a
floating point number

On platforms without a real time clock, the millisecond and
microsecond ticks may then be approximations based on the system tick
counter - that's actually the origin of my suggestion to expose
completely separate APIs for the millisecond and microsecond versions,
as if those are derived by dividing a fast system tick counter
appropriately, they may wrap more frequently than every 2**32 or 2**64
ticks.

Depending on use case, there may also be value in exposing the
potential degree of jitter in the *_ms() and *_us() tick counters. I'm
not sure if that would be best expressed in absolute or relative
terms, though, so I'd suggest leaving that aspect undefined
unless/until you have a specific use case in mind.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia