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

[Ulrich Windl <[e-mail]>]

>>> Miroslav Lichvar <[e-mail]> schrieb am 01.12.2020 um 09:44 in
Nachricht <20201201084448.GE1900232@localhost>:
> On Tue, Dec 01, 2020 at 09:30:35AM +0100, Ulrich Windl wrote:
>> >>> Steven Sommars <[e-mail]> schrieb am 30.11.2020 um
21:32 in
>> Nachricht
>> <CAD4huA79u3NkR8LS96Gqgs58mJguoN7=p=[e-mail]>:
>> > Agree, these fields could use better descriptions or (better)
replacement.
>> > 
>> > One manufacturer (LeoNTP) lowers precision to indicate reduced accuracy
and
>> > claims to obey the NTP specification.
>> 
>> Actually if you consider precision to be a "runtime value" (as opposed to a

> "design value") it's obvious that it is actually variable. However the  
> overhead to update the value was considered too heavy in NTP design, I
guess.
> 
> 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).

> 
>> > Using NTP short format the smallest non‑zero root dispersion is 15
>> > microseconds.  One can argue for finer granularity
>> 
>> Not just there: stability (clk_wander) could also need more digits. 
> 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? ;-)

Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar