Re: [Ntp] Antwort: Re: The bump, or why NTP v5 must specify impulse response

[Daniel Franke <[e-mail]>]

On Fri, Apr 17, 2020 at 11:35 AM Warner Losh <[e-mail]> wrote:
> Counters of sufficient resolution wrap. There's often a software counter too. And getting either the raw software or raw hardware counters and/or their notion of a relationship to the local system time can be tricky as well. Some OSes allow access to the raw counters (since CPUs allow turning that access on/off), and some even publish what's basically a 'phase at count' testimate and a frequency estimate that the applications can then use to compute time w/o a round trip into the kernel (this is often hidden inside of libc's clock_gettime or similar).
>
> Also, how does NTPd get access to this pure counter when it timestamps the packets? It would need to know that in order to measure the evolution of that counter over time to make estimates about it.
>
> And I'd maintain that the NTP daemon needs to provide both the phase estimate of the counter vs the TAI and a shorter-term frequency estimate for the counter's evolution. Since the counter is likely to be lousy over time and the frequency will wander all over the place (relative to a high precision time keeping xtal or clock), the most useful information is that counter X is TAI time Y and the short-term frequency is Z (maybe with a Z' estimate as well). The OS will need to read the counter and produce a TAI/UTC time quite often, and doing more than a simple computation will show up in benchmarks. But that thinking may be a legacy of NTP steering the OS's notion of time that it gets from a pure counter under the covers. This is why we have ntp_adjtime providing a time delta and frequency error and a bunch of other stuff that talk about ntpd's notion of how good those are which are on a spectrum from generally useful, to totally NTPd specific. I have a hard time seeing a way to not push the error in time / frequency measurements down.
>
> Second, the OS needs to keep a smooth time to its clients w/o time jumps (but small changes in frequency are OK). So there will likely need to be some coordination between the OS and the ntp daemon to communicate how much of the 'steers' or 'tyler series' information it could ingest and what it's notion of a future counter's time will be so NTP can help steer the OS's use of the counter so it will be on time in the future and not overshoot as the frequency wanders around.

I don't think we're disagreeing about anything here. Where I say
"first few Taylor series coefficients" and you say "time delta and
frequency error", we're talking about the same thing — time delta and
frequency error are the first and second coefficients respectively.
I'm considering the kernel and libc all part of the OS, so questions
about how to deal with hardware counters that wrap and what should
happen in kernel versus user space all lives on the "OS" side of
abstraction barrier.