Internal time representations

Mon Aug 1 16:47:24 UTC 2016

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?

Formerly, one was ticks and the other was seconds. Seconds granularity is
insufficient for POSIX.

> >>
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160801/41cf1120/attachment.html>