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. Gedare _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
