Re: [Ntp] Antw: Re: Antw: [EXT] Re: NTPv5 draft

[Miroslav Lichvar <[e-mail]>]

On Tue, Dec 01, 2020 at 10:22:59AM +0100, Ulrich Windl wrote:
> >>> Miroslav Lichvar <[e-mail]> schrieb am 01.12.2020 um 09:44 in
> Nachricht <20201201084448.GE1900232@localhost>:
> > I think it depends on the clock. Normally, the precision of the clock
> > should be constant. If it's a CPU with variable frequency, for
> > timekeeping performance it is better to set the frequency to a
> > constant value.
> 
> That's what I called "design" precision. However when you read the clock and
> your computer is not fast enough for the full precision, should you work with
> the full precision of the hardware or with the limited precision the software
> can get? (Say your clock has 1ns resolution, but reading it takes 10 to 15 ns,
> maybe even longer if there's high system load).

If the clock takes a longer time to read due to high system load, that
delay will be included in the delay measured by the client. I think
the precision field should ideally describe the inherent precision
coming from the frequency in the hardware, i.e. how much information
there is actually in the timestamps provided by the server. That's
difficult to determine in userspace, so most implementations set the
precision to a minimum time it takes to read the clock. That's just an
upper bound on the actual precision. If it's a high-frequency clock
accessed over a slow bus, or there is a slow system call involved, it
can overestimate the precision by few orders of magnitude.

> > clk_jitter is another candidate (it looks like a constant here for GPS). 
> > Maybe more. Some are heritage of microsecond resolution of NTPv3.
> > 
> > Those values are provided only in the monitoring protocol.
> 
> Agreed, but aren't they used internally? And are you saying we don't need
> monitoring? ;-)

I mean they are not relevant for the NTPv5 design. The monitoring
protocol should have its own specification.

-- 
Miroslav Lichvar