Re: [Ntp] Antw: Re: Antw: [EXT] comments on draft‑mlichvar‑ntp‑ntpv5‑03

[Miroslav Lichvar <[e-mail]>]

On Wed, Nov 24, 2021 at 01:34:06PM +0100, Ulrich Windl wrote:
> >>> Miroslav Lichvar <[e-mail]> schrieb am 24.11.2021 um 13:09 in
> > MAXDISP is the threshold when the server is considered unsynchronized
> > after it stops updating its clock. It should be larger than any
> > normally expected dispersion to not block synchronization.
> > 
> > With the default PHI of 15 ppm, it takes 16/15e‑6 seconds (about
> > 12.3 days) for the dispersion to accumulate 16 seconds. In the worst
> > case it should cover up to 15 strata updating clocks at a maximum
> > polling interval.
> > 
> > I think 1 second would be too small.
> 
> But doesn't that value also say "the reference clock can be off by as much as
> MAXDISP"?

In the sense that if a stratum 1 server had a dispersion of 1 second,
it wouldn't be accepted by its clients as synchronized?

> Considering that values above MAXDIST (1s) are ignored anyway, I wonder.
> Probably the real reason is that 16 needs five left shifts until it is less
> than MAXDIST (samples until server is accepted).
> 
> It's all a lot of heuristics, possibly still rooting from the time when it was
> important to avoid integer overflows in the math.
> 
> With MAXDISP being just one second, the first sample from a server will
> probably make it a valid one.

That is a good point. The clock filter does have an assumption about
the MAXDISP/MAXDIST ratio as it uses MAXDISP for dummy sumples when
empty. I think it would be better if it simply counted the samples
instead of processing dummy values.

-- 
Miroslav Lichvar