[PATCH grout] add high-performance clock

[Robin Jarry]

Morten Brørup, Jun 17, 2026 at 13:44:
> That's what I thought too, when I submitted the initial patch (Tuesday
> 9th).
>
> But further experimentation showed that
> clock_gettime(CLOCK_MONOTONIC_RAW) and rte_rdtsc() (divided by
> rte_get_tsc_hz()) are not in sync, not even when the clocksource is
> "tsc".
>
> They are not only offset by a different epoch (which I thought), they
> also drift differently (which came as a surprise to me). On a VMware
> virtual machine, I saw them drifting a few seconds further apart
> overnight.
>
> It seems there is no simple way to convert between these two clocks,
> just like there is no way to convert between CLOCK_MONOTONIC_RAW and
> CLOCK_MONOTONIC.

OK good to know.

> Train of thought:
>
> For now, Grout uses the timestamps for e.g. ageing in the bridge FDB,
> which doesn't require a high-res clock. I could add a low-accuracy
> clock based on CLOCK_MONOTONIC (which is NTP adjusted), and use that
> for timestamping the FDB entries. It would be somewhat similar to my
> suggestion about adding support for CLOCK_REALTIME (Saturday 13th).
>
> With such a change, CLOCK_MONOTONIC would replace CLOCK_MONOTONIC_RAW
> as the "common clock across all processes", and gr_clock_ns() would go
> back to being a wrapper around clock_gettime(), but now using
> CLOCK_MONOTONIC instead of CLOCK_MONOTONIC_RAW.
>
> But only provides a solution for low-res clocks.
>
> The root cause is that we are mixing time intervals (e.g. last seen
> "60 seconds ago") with timestamps (e.g. last seen "17-JUN-2026
> 13:18:00 CEST"). We do this, because we have to. E.g. we put
> a timestamp on an FDB entry, so we can calculate its age (the time
> interval).

Low-res clocks are perfectly fine for this use case. I imagine that high
res clocks would be only useful for datapath only operations where the
timestamps don't need to be exposed to the API (QoS, L4S, etc.).

What about keeping the high res clocks only internal to grout and use
CLOCK_MONOTONIC_RAW (not affected by NTP) for low res timestamps that
are eventually exposed to the user?

If performance in the datapath is a concern, we could keep a per-worker
cached value that is only updated every housekeeping interval like
I had outlined here:

https://inbox.dpdk.org/grout/DIP6E2Y6CLJY.26JKOONI7DQGD@redhat.com/

> Another solution would be to convert between relevant clock domains at
> the API border. But we might extend the API border with shared memory
> for accessing very large tables, which may contain entries with Grout
> timestamps. If so, the non-Grout process needs to understand Grout's
> clock domain, to be able to convert to its own clock domain.
>
> The solution I had proposed - making gr_clock_ns() a client API
> - solves this challenge: The API allows reading Grout's clock through
> gr_clock_ns(), so the non-Grout application can calculate the age of
> an entry by subtracting the entry's timestamp from the return value of
> gr_clock_ns(). And if it needs a wall clock timestamp of the entry, it
> can subtract the age from the return value of
> clock_gettime(CLOCK_REALTIME).

Honestly, I don't like the idea of querying the API to get a "timestamp
value" to be able to compute time intervals from API messages that we
just received. This feels redundant. The conversion (if any) should be
done by grout before sending the first message.

-- 
Robin

> Might not be suitable for persons suffering from weak hearts.