timestamp resolution

[Morten Brørup]

> From: Robin Jarry [mailto:rjarry at redhat.com]
> Sent: Thursday, 21 May 2026 12.00
> 
> Hi Morten,
> 
> Morten Brørup, May 21, 2026 at 11:54:
> > Digging deeper into Grout's inner workings...
> >
> > I noticed that the timestamp fields of both the MAC FDB
> (gr_fdb_entry->last_seen) and the Connection Tracking table
> (gr_conntrack->last_update) have very high resolution: clock_t is
> microseconds.
> >
> > If they are only used for aging, one second would suffice: time_t is
> seconds.
> >
> > Was there some other reason for the extremely high resolution
> timestamps?
> 
> No specific reason, we don't need higher precision than the second. We
> could use time_t but it is a signed integer. I wanted an unsigned one
> to
> avoid any confusion.

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.

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?