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

[Warner Losh <[e-mail]>]

On Fri, Apr 17, 2020 at 10:08 AM Daniel Franke <[e-mail]> wrote:

> 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.
>

Well, the OS provides an 'abstract' counter, but only kinda. Usually it
integrates the past to some point in time after the last counter wrap and
then uses the delta from that point to the current counter to compute the
time. The OS may have a hard time providing a pure counter to NTP, and it
should be designed such that it may only get the low order bits from the
counter and an OS timestamp...

Warner