timestamp resolution

[Morten Brørup]

> From: Robin Jarry [mailto:rjarry at redhat.com]
> Sent: Thursday, 21 May 2026 12.55
> 
> Morten Brørup, May 21, 2026 at 12:43:
> > Then I suggest we introduce an unsigned clock type with much lower
> resolution.
> > If it's 32 bit, it can handle an uptime of 136 years with one second
> resolution.
> >
> > Using lower resolution timestamps provides some performance benefits.
> > Specifically, the number of memory store operations can be
> significantly reduced by not writing into a timestamp field if it
> already holds the same value.
> 
> I wonder if the cost of checking if the value changed before writing
> defeats the performance gain, compared to writing without question.
> 
> Did you find any hotspots while profiling regarding timestamps? I think
> this may be an unnecessary optimization.

DPDK uses this trick when clearing some mbuf fields that likely already hold the wanted value.
E.g. here:
https://elixir.bootlin.com/dpdk/v26.03/source/lib/mbuf/rte_mbuf.h#L1343

> 
> > On the other hand...
> > Using coarser timers does increase jitter, so instead of using
> seconds, some fraction of a second could be used.
> > E.g. 1/16 of a second could handle an uptime of 8.5 years.
> >
> > Would the definition of such a type, and its inline support
> functions, go into the api/gr_clock.h header file, or would it go into
> a separate header file?
> 
> gr_clock.h is the correct place.
> 
> The only issue I may think of is that on some systems, clock_t can be
> a floating number (double). Maybe we could replace the return value of
> gr_clock_us() to a typedef we control?
> 
> 	typedef uint64_t gr_time_us_t;
> 
> What do you think?

Agree.
Furthermore, the resolution of clock_t is implementation defined:
The resolution is 1 us on Linux, where CLOCKS_PER_SEC is 1000000.
On Windows, the resolution is 1 ms, and CLOCKS_PER_SEC is 1000.

I agree with your type definition.
You should add a description mentioning that its origo is usage dependent, i.e. its value may be relative to CLOCK_MONOTONIC_RAW, CLOCK_REALTIME, or some other origo.