[Ntp] Wtrlt: Issues with clock_getres() and clock_gettime() on fast machines

[Ulrich Windl <[e-mail]>]

(Originally sent to the old list; sorry)
>>> "Ulrich Windl" <[e-mail]> schrieb am 03.11.2020
um
10:40 in Nachricht <[e-mail]>:
> Hi!
> 
> I ran into a problem with an application doing timing:
> clock_getres() returns 1 nanosecond as resolution, even though the actual 
> clock may have less resolution.
> Trying to avoid outputting fractional digits that are more or less nonsense,

> I tried to find out the maximum resolution by doing a few fast clock
samples, 
> building and sorting differences.
> That worked, but then I suddenly got a clock resolution of zero (less than 
> one nanosecond)!
> I debugged it, and actually I saw up to three subsequent calls to 
> clock_gettime() (CLOCK_MONOTONIC in my case) returning exactly the same 
> timestamp, while the time between the calls should be around 2 microseconds

> or so.
> 
> I think in the past (possibly excluding plain old time()) the clock 
> resolution always had been faster than the shortest possible clock polling 
> interval, but recent machines seem to turn that around: If your polling 
> interval is less or equal to clock resolution, the same timestamp will be 
> returned.
> I also think that in the past there was a work‑around ensuring that the time

> will at least advance by one nanosecond between calls, but that's obviously

> not common any more.
> The other problem is with NTP corrections: Assume your clock resolution 
> actually is 1 nanosecond or better, and the minimum polling delay is also 
> about one nanosecond, and the system clock is too fast, going to be
corrected 
> to be slower. Wouldn't then a number of clock_gettime() retrun identical 
> timestamps, or maybe, even worse show a clock running backwards?
> Dividing by a zero or negative time difference will not result in good rate

> numbers, not to talk about application crashes (as it was in my case, so I 
> got alerted initially)...
> 
> I think these issues should be addressed by some informational document, 
> helping implementers to "do things right". Opinions?
> 
> Regards,
> Ulrich