On Aug 1, 2016 11:41 AM, "Gedare Bloom" <ged...@rtems.org> wrote: > > On Mon, Aug 1, 2016 at 1:26 AM, Sebastian Huber > <sebastian.hu...@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.hu...@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@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.hu...@embedded-brains.de > >>> PGP : Public key available on request. > >>> > >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >>> > >>> > >>> _______________________________________________ > >>> devel mailing list > >>> devel@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.hu...@embedded-brains.de > > PGP : Public key available on request. > > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
