<p dir="ltr"></p>
<p dir="ltr">On Aug 1, 2016 11:41 AM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
><br>
> On Mon, Aug 1, 2016 at 1:26 AM, Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> > On 28/07/16 16:53, Gedare Bloom wrote:<br>
> >><br>
> >> Hi Sebastian,<br>
> >><br>
> >> The problem that I encountered was that there are two different<br>
> >> representations used for the watchdogs, the 34+30 compact timespec,<br>
> >> a.k.a. "watchdog ticks", used for absolute, and the 64-bit "score<br>
> >> ticks" used for relative. Since both of these are called ticks<br>
> >> internally, I had a bit of confusion on what to use, and which<br>
> >> interfaces for converting time formats into something each watchdog<br>
> >> uses as a timeout. Pavel suggested that switching to a single format<br>
> >> would help reduce confusion, and may help with variable clock ticks.<br>
> ><br>
> ><br>
> > I still think that the time formats for the watchdogs are the right ones.<br>
> > Maybe we should rename<br>
> ><br>
> > _Watchdog_Ticks_from_seconds() -> _Watchdog_Expiration_time_from_seconds()<br>
> ><br>
> > _Watchdog_Ticks_from_timespec() -> _Watchdog_Expiration_time_from_timespec()<br>
> ><br>
> > We already have a Watchdog_Control:<br>
> ><br>
> >   /** @brief This field is the expiration time point. */<br>
> >   uint64_t expire;<br>
> ><br>
> Yes, renaming would alleviate some of the confusion I encountered.</p>
<p dir="ltr">Just to be clear. Are both the ticks and seconds watchdog sets at ticks resolution?</p>
<p dir="ltr">Formerly, one was ticks and the other was seconds. Seconds granularity is insufficient for POSIX.</p>
<p dir="ltr">> >><br>
> >> Perhaps the FreeBSD time counters are a sufficient representation to<br>
> >> handle setting up variable ticks. Confusion might also be less if we<br>
> >> don't use the same terminology "ticks" for the two different formats.<br>
> >> Relative are actual "ticks" based on the configured RTEMS clock, while<br>
> >> absolute are ns time-based.<br>
> >><br>
> >> Gedare<br>
> >><br>
> >> On Thu, Jul 28, 2016 at 2:23 AM, Sebastian Huber<br>
> >> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> >>><br>
> >>> Hello,<br>
> >>><br>
> >>> I am not sure which problem you want to address. For the watchdogs we use<br>
> >>> currently a 64-bit integer key for relative and absolute timeouts. For<br>
> >>> the<br>
> >>> watchdog it is important that<br>
> >>><br>
> >>> * the key comparison operations are fast,<br>
> >>> * the conversion from common time formats to the key are fast, and<br>
> >>> * there is no integer overflow within a reasonable time frame.<br>
> >>><br>
> >>> This is all satisfied currently. It is NOT important to convert this key<br>
> >>> into a common time format, since there is no use case for this.<br>
> >>><br>
> >>> For timekeeping we use the FreeBSD time counters (provider for<br>
> >>> CLOCK_REALTIME and CLOCK_MONOTONIC). They use struct bintime (aka<br>
> >>> Timestamp_Control) for time representation. It allows fast conversion<br>
> >>> to/from common time formats. Addition is also fast. In addition there is<br>
> >>> a<br>
> >>> sbintime_t available which can be used for some problem domains as an<br>
> >>> optimization.<br>
> >>><br>
> >>> For NTP and PPS we just have to port the code from FreeBSD. It is very<br>
> >>> well<br>
> >>> integrated into the FreeBSD time counters.<br>
> >>><br>
> >>><br>
> >>> On 27/07/16 23:29, Pavel Pisa wrote:<br>
> >>>><br>
> >>>> Hello Gedare,<br>
> >>>><br>
> >>>> thanks much for the great summary of the discussion.<br>
> >>>><br>
> >>>> On Wednesday 27 of July 2016 18:30:02 Gedare Bloom wrote:<br>
> >>>>><br>
> >>>>> After an IRC chat this morning with Pavel, we've decided to query<br>
> >>>>> everyone about thoughts on unifying the internal score representations<br>
> >>>>> for time into a single format. This discussion comes from the work<br>
> >>>>> I've done with nanosleep, which now uses both the relative and<br>
> >>>>> absolute watchdogs that have two different representations of<br>
> >>>>> time--relative uses the score "ticks", and absolute uses a 64-bit<br>
> >>>>> compacted version of timespec with seconds in the upper 32-bits and ns<br>
> >>>>> in the lower 32. The proposed format is a count of nanoseconds in<br>
> >>>>> 64-bits, or ns64.<br>
> >>>><br>
> >>>> minor correction, copact time works in 34+30 bit format so it<br>
> >>>> has no 2038 problem (final year is about 2514 for unsigned<br>
> >>>> and 2242 for signed representation)<br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> <a href="https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/watchdogimpl.h#n295">https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/watchdogimpl.h#n295</a><br>
> >>>><br>
> >>>> On the other hand, conversion of the timespec seconds to this format<br>
> >>>> requires some shifts and masking. Conversion of 32-bit + 32-bit timespec<br>
> >>>> to linear ns64 requires one 32*32->64 bit multiply and 64-bit addition.<br>
> >>>> This has higher cost but on the modern CPUs it is not so big difference.<br>
> >>>> It simplifies computation of differences, adding of relative time<br>
> >>>> to actual time etc. It can be significant overhead for 16-architectures<br>
> >>>> (bare h8, even h8s) and blocker for 8-bit ones (AVR). But they are<br>
> >>>> not so common today.<br>
> >>>><br>
> >>>> Conversion to timespec is significant problem.<br>
> >>>><br>
> >>>> If the 34+30 bit compact timespec advantage of the faster conversion<br>
> >>>> prevails for PER_CPU_WATCHDOG_ABSOLUTE then I would vote to change<br>
> >>>> PER_CPU_WATCHDOG_RELATIVE to the same format.<br>
> >>>><br>
> >>>> This simplifies clock_nanosleep logic and generally makes<br>
> >>>> code more readable and lowers space for mistakes.<br>
> >>>><br>
> >>>> If we consider 64-bit linear format then we should think about<br>
> >>>> conversion to 64+32 bit timespec to overcome 2038 year problem.<br>
> >>>> This makes multiplication 64*32->64 which is more complex.<br>
> >>>> The most of the upper 32-bits would be discarded in ns64 format.<br>
> >>>> But time wrap is around 2554, so no problem. For copacted<br>
> >>>> timspec based format id 64-bit second field conversion easier,<br>
> >>>> two LSB bits from upper 32-bit part are moved to MSB bits of<br>
> >>>> compacted timespec.<br>
> >>>><br>
> >>>> On the other hand, conversion of generic time source (which needs<br>
> >>>> scaling)<br>
> >>>> to the compacted timespec is disaster. So I think that linear<br>
> >>>> 64-bit (ns64) format is better at the end.<br>
> >>>><br>
> >>>> But discussion and counter examples are welcome.<br>
> >>>><br>
> >>>> The cost of conversion from ns64 to timespec is high.<br>
> >>>> May it be we can find some optimization but it is problem.<br>
> >>>> So at this time I suggest ns64 only for timers which fire<br>
> >>>> and user provided time, there is no requirement to read<br>
> >>>> expire value back by user in common POSIX APIs (at least<br>
> >>>> I hope).<br>
> >>>><br>
> >>>>> Advantages of the ns64 is that conversion of user time formats<br>
> >>>>> (timespec, timeval, etc)  to 64-bit nanoseconds is relatively<br>
> >>>>> efficient, and the internal time representations can be compared with<br>
> >>>>> easy logic. The ns64 allows for higher precision event triggers than<br>
> >>>>> score ticks. Furthermore, converting multiple time sources into ns64<br>
> >>>>> is simpler to maintain consistent notion of time than score "ticks".<br>
> >>>>> Thus, we anticipate the ns64 would make it easier to introduce<br>
> >>>>> variable length ticks (a.k.a. tickless/no_hz) and to synchronize time<br>
> >>>>> across SMP chips where each core has its own time source.<br>
> >>>>><br>
> >>>>> Some disadvantages are<br>
> >>>>> 1) conversion back to user time is costly<br>
> >>>>> 2) clock "tick" may add multiple nanoseconds to the ns64 counter<br>
> >>>>> 3) no one has budget to implement it now :)<br>
> >>>>><br>
> >>>>> I wanted to stimulate some discussion about the topic to see if there<br>
> >>>>> was any great objection to this kind of change, and what other inputs<br>
> >>>>> others may have.<br>
> >>>><br>
> >>>> Best wishes,<br>
> >>>><br>
> >>>>                 Pavel<br>
> >>>> _______________________________________________<br>
> >>>> devel mailing list<br>
> >>>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> >>>> <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>> Sebastian Huber, embedded brains GmbH<br>
> >>><br>
> >>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> >>> Phone   : +49 89 189 47 41-16<br>
> >>> Fax     : +49 89 189 47 41-09<br>
> >>> E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
> >>> PGP     : Public key available on request.<br>
> >>><br>
> >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> devel mailing list<br>
> >>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> >>> <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> ><br>
> ><br>
> > --<br>
> > Sebastian Huber, embedded brains GmbH<br>
> ><br>
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> > Phone   : +49 89 189 47 41-16<br>
> > Fax     : +49 89 189 47 41-09<br>
> > E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
> > PGP     : Public key available on request.<br>
> ><br>
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> ><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br></p>