On Mon, Aug 1, 2016 at 12:47 PM, Joel Sherrill <j...@rtems.org> wrote: > 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? > 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.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
