Internal time representations
gedare at rtems.org
Wed Jul 27 16:30:02 UTC 2016
After an IRC chat this morning with Pavel, we've decided to query
everyone about thoughts on unifying the internal score representations
for time into a single format. This discussion comes from the work
I've done with nanosleep, which now uses both the relative and
absolute watchdogs that have two different representations of
time--relative uses the score "ticks", and absolute uses a 64-bit
compacted version of timespec with seconds in the upper 32-bits and ns
in the lower 32. The proposed format is a count of nanoseconds in
64-bits, or ns64.
Advantages of the ns64 is that conversion of user time formats
(timespec, timeval, etc) to 64-bit nanoseconds is relatively
efficient, and the internal time representations can be compared with
easy logic. The ns64 allows for higher precision event triggers than
score ticks. Furthermore, converting multiple time sources into ns64
is simpler to maintain consistent notion of time than score "ticks".
Thus, we anticipate the ns64 would make it easier to introduce
variable length ticks (a.k.a. tickless/no_hz) and to synchronize time
across SMP chips where each core has its own time source.
Some disadvantages are
1) conversion back to user time is costly
2) clock "tick" may add multiple nanoseconds to the ns64 counter
3) no one has budget to implement it now :)
I wanted to stimulate some discussion about the topic to see if there
was any great objection to this kind of change, and what other inputs
others may have.
More information about the devel