On 27 June 2015 at 05:14, Paul Sokolovsky <pmiscml@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...) 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@gmail.com | Brisbane, Australia