Internal time representations

Gedare Bloom gedare at rtems.org
Mon Aug 1 16:59:26 UTC 2016 

On Mon, Aug 1, 2016 at 12:47 PM, Joel Sherrill <joel at rtems.org> wrote:
> On Aug 1, 2016 11:41 AM, "Gedare Bloom" <gedare at rtems.org> wrote:
>>
>> On Mon, Aug 1, 2016 at 1:26 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>> > On 28/07/16 16:53, Gedare Bloom wrote:
>> >>
>> >> Hi Sebastian,
>> >>
>> >> The problem that I encountered was that there are two different
>> >> representations used for the watchdogs, the 34+30 compact timespec,
>> >> a.k.a. "watchdog ticks", used for absolute, and the 64-bit "score
>> >> ticks" used for relative. Since both of these are called ticks
>> >> internally, I had a bit of confusion on what to use, and which
>> >> interfaces for converting time formats into something each watchdog
>> >> uses as a timeout. Pavel suggested that switching to a single format
>> >> would help reduce confusion, and may help with variable clock ticks.
>> >
>> >
>> > I still think that the time formats for the watchdogs are the right
>> > ones.
>> > Maybe we should rename
>> >
>> > _Watchdog_Ticks_from_seconds() ->
>> > _Watchdog_Expiration_time_from_seconds()
>> >
>> > _Watchdog_Ticks_from_timespec() ->
>> > _Watchdog_Expiration_time_from_timespec()
>> >
>> > We already have a Watchdog_Control:
>> >
>> >   /** @brief This field is the expiration time point. */
>> >   uint64_t expire;
>> >
>> Yes, renaming would alleviate some of the confusion I encountered.
>
> Just to be clear. Are both the ticks and seconds watchdog sets at ticks
> resolution?
>
We have a relative and absolute watchdog. Relative is programmed in
score "ticks", and absolute is programmed in nanoseconds.

> Formerly, one was ticks and the other was seconds. Seconds granularity is
> insufficient for POSIX.
>
I don't think there exists a watchdog with seconds granularity now.

>> >>
>> >> Perhaps the FreeBSD time counters are a sufficient representation to
>> >> handle setting up variable ticks. Confusion might also be less if we
>> >> don't use the same terminology "ticks" for the two different formats.
>> >> Relative are actual "ticks" based on the configured RTEMS clock, while
>> >> absolute are ns time-based.
>> >>
>> >> Gedare
>> >>
>> >> On Thu, Jul 28, 2016 at 2:23 AM, Sebastian Huber
>> >> <sebastian.huber at embedded-brains.de> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I am not sure which problem you want to address. For the watchdogs we
>> >>> use
>> >>> currently a 64-bit integer key for relative and absolute timeouts. For
>> >>> the
>> >>> watchdog it is important that
>> >>>
>> >>> * the key comparison operations are fast,
>> >>> * the conversion from common time formats to the key are fast, and
>> >>> * there is no integer overflow within a reasonable time frame.
>> >>>
>> >>> This is all satisfied currently. It is NOT important to convert this
>> >>> key
>> >>> into a common time format, since there is no use case for this.
>> >>>
>> >>> For timekeeping we use the FreeBSD time counters (provider for
>> >>> CLOCK_REALTIME and CLOCK_MONOTONIC). They use struct bintime (aka
>> >>> Timestamp_Control) for time representation. It allows fast conversion
>> >>> to/from common time formats. Addition is also fast. In addition there
>> >>> is
>> >>> a
>> >>> sbintime_t available which can be used for some problem domains as an
>> >>> optimization.
>> >>>
>> >>> For NTP and PPS we just have to port the code from FreeBSD. It is very
>> >>> well
>> >>> integrated into the FreeBSD time counters.
>> >>>
>> >>>
>> >>> On 27/07/16 23:29, Pavel Pisa wrote:
>> >>>>
>> >>>> Hello Gedare,
>> >>>>
>> >>>> thanks much for the great summary of the discussion.
>> >>>>
>> >>>> On Wednesday 27 of July 2016 18:30:02 Gedare Bloom wrote:
>> >>>>>
>> >>>>> 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.
>> >>>>
>> >>>> minor correction, copact time works in 34+30 bit format so it
>> >>>> has no 2038 problem (final year is about 2514 for unsigned
>> >>>> and 2242 for signed representation)
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/watchdogimpl.h#n295
>> >>>>
>> >>>> On the other hand, conversion of the timespec seconds to this format
>> >>>> requires some shifts and masking. Conversion of 32-bit + 32-bit
>> >>>> timespec
>> >>>> to linear ns64 requires one 32*32->64 bit multiply and 64-bit
>> >>>> addition.
>> >>>> This has higher cost but on the modern CPUs it is not so big
>> >>>> difference.
>> >>>> It simplifies computation of differences, adding of relative time
>> >>>> to actual time etc. It can be significant overhead for
>> >>>> 16-architectures
>> >>>> (bare h8, even h8s) and blocker for 8-bit ones (AVR). But they are
>> >>>> not so common today.
>> >>>>
>> >>>> Conversion to timespec is significant problem.
>> >>>>
>> >>>> If the 34+30 bit compact timespec advantage of the faster conversion
>> >>>> prevails for PER_CPU_WATCHDOG_ABSOLUTE then I would vote to change
>> >>>> PER_CPU_WATCHDOG_RELATIVE to the same format.
>> >>>>
>> >>>> This simplifies clock_nanosleep logic and generally makes
>> >>>> code more readable and lowers space for mistakes.
>> >>>>
>> >>>> If we consider 64-bit linear format then we should think about
>> >>>> conversion to 64+32 bit timespec to overcome 2038 year problem.
>> >>>> This makes multiplication 64*32->64 which is more complex.
>> >>>> The most of the upper 32-bits would be discarded in ns64 format.
>> >>>> But time wrap is around 2554, so no problem. For copacted
>> >>>> timspec based format id 64-bit second field conversion easier,
>> >>>> two LSB bits from upper 32-bit part are moved to MSB bits of
>> >>>> compacted timespec.
>> >>>>
>> >>>> On the other hand, conversion of generic time source (which needs
>> >>>> scaling)
>> >>>> to the compacted timespec is disaster. So I think that linear
>> >>>> 64-bit (ns64) format is better at the end.
>> >>>>
>> >>>> But discussion and counter examples are welcome.
>> >>>>
>> >>>> The cost of conversion from ns64 to timespec is high.
>> >>>> May it be we can find some optimization but it is problem.
>> >>>> So at this time I suggest ns64 only for timers which fire
>> >>>> and user provided time, there is no requirement to read
>> >>>> expire value back by user in common POSIX APIs (at least
>> >>>> I hope).
>> >>>>
>> >>>>> 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.
>> >>>>
>> >>>> Best wishes,
>> >>>>
>> >>>>                 Pavel
>> >>>> _______________________________________________
>> >>>> devel mailing list
>> >>>> devel at rtems.org
>> >>>> http://lists.rtems.org/mailman/listinfo/devel
>> >>>
>> >>>
>> >>> --
>> >>> Sebastian Huber, embedded brains GmbH
>> >>>
>> >>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >>> Phone   : +49 89 189 47 41-16
>> >>> Fax     : +49 89 189 47 41-09
>> >>> E-Mail  : sebastian.huber at embedded-brains.de
>> >>> PGP     : Public key available on request.
>> >>>
>> >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> devel mailing list
>> >>> devel at rtems.org
>> >>> http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>> > --
>> > Sebastian Huber, embedded brains GmbH
>> >
>> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> > Phone   : +49 89 189 47 41-16
>> > Fax     : +49 89 189 47 41-09
>> > E-Mail  : sebastian.huber at embedded-brains.de
>> > PGP     : Public key available on request.
>> >
>> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

More information about the devel mailing list