Internal time representations

Mon Aug 1 15:41:39 UTC 2016

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.

>>
>> 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.
>