[riot-notifications] [RIOT-OS/RIOT] sys/evtimer: use ztimer_sec instead of ztimer_now64 now_min (#16697)

Marian Buschsieweke notifications at github.com
Mon Aug 2 20:55:41 CEST 2021

I agree with @miri64.

More generally, I wonder if we should reconsider whether allowing `ztimer_now()` on clocks with a different epochs is a good idea. IMO thisis a non-obvious footgun that is just waiting to blast off.

The alternatives that come to my mind are:

1. Allow only one "main" clock to provide timestamps
    * + Absolutely foot-gun free
    * + Trivial to implement
    * - Which should be the "main" clock? What when two modules have a conflicting requirements regarding the "main" clock?
    * - manually converting between time scales is really meh, especially since ztimer implements the conversion logic fine
2. Allow all clocks derived from the "main" hardware clock to provide timestamps
    * + a bit more convenient than 1.
    * - replaces one footgun by another (IMO it is quite surprising that making use of an RTT could result in some clocks loosing their timestamping features)
3. Synchronise the ztimer backends
    * - a horrible idea IMO, since clocks will drift. Mixing timestamps from different sources will result in different durations being reported for the same real duration depending on which clock was used for the start and which for the stop timestamp.
    * - overhead / complexity
4. Always use the same hardware clock for timestamps. (E.g even if ZTIMER_USEC would use periph_timer for timers, still use periph_rtt and frequency conversion for timestamps.)
    * + no big footguns and relatively easy
    * - different resolutions for timers and timestamps
    * - clock drift between timestamps and timers. (If timer duration are dynamically computed from durations measured using the delta of two timestamps, that could be an issue).
5. Drop access to timestamps altogether. Instead, allow only to measure durations by providing two functions (for start and stop) which operate on an opaque `struct`. With develhelp the struct would contain a pointer to the clock it was started on and the stop function `assert()`s the same being used there. The stop function would be allowed to be called multiple times for the same starting value and a convenience "epoch" starting value for each clock could be provided for when timestamps are needed.
    * + No loss of functionality
    * + No overhead when not using DEVELHELP
    * + Fixes the footgun
    * + The convenience epoch values could be compile time constants to allow them to be garbage collected at link time. Also, they could be randomly chosen at built time to ensure mixing "timestamps" from different clocks fails soon and noisy.
    * - More verbose code
    * - Some overhead (one pointer and an `asserr()`) when using DEVELHELP

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210802/72116ca7/attachment.htm>

More information about the notifications mailing list