On Tue, Jan 18, 2011 at 12:49:52PM +0000, David Woolley wrote: > Miroslav Lichvar wrote: > > >The trouble is with "when locked". When the jitter reaches a certain > >point (or better the ratio between jitter and clock stability -- > >usually expressed as Allan intercept in the NTP docs), the PLL won't > >be able to get a good lock and the clock accuracy will be limited only > >by the clock stability, not the jitter. > > Are you suggesting that the assumed Allan intercept if a couple of > orders of magnitude too high?
Yes, when the jitter is too low or the clock too unstable. Ideally, ntp would run a statistic and adjust it in runtime. Chrony counts number of runs of residuals with same sign, perhaps it could work for ntp too. But in ntp the assumed Allan intercept only controls the PLL/FLL switch (and only in daemon mode), the PLL time constant is always fixed to polling interval. > >As ntpd fixes the time constant to the polling interval, the only > >thing you can do is to use a lower polling interval. If ntpd was able > > Linking them makes total sense. The poll interval needs to be a > small submultiple of the time constant, so that there is reasonable > oversampling and allowance is made for the subsetting of the samples > in the initial filter. Polling faster than this adds very little > information to the timing solution and polling slower will break the > Nyquist criterion. Linking them makes sense if you want to keep things simple and robust. The problem is that even the minimum allowed poll 3 is too long in some situations and that it wastes network bandwidth. > >to change time constant and PLL/FLL mode independently from polling > >interval, it would be a huge improvement. Would be very tricky though. > > > >I'd suggest you to look at the clknetsim graphs, I think you can get a > >very good understanding how is time and frequency accuracy affected by > >jitter/wander, poll interval and the PLL gain. > > > >http://mlichvar.fedorapeople.org/clknetsim/ > > > You are measuring (RMS) offset, which is not the same as error, and > you are not accounting for network wander, which can reach 100s of > ms, if NTP isn't prioritised. Define error and network wander. Please note that the RMS offset is from the actual clock offset maintained by the simulator, not the one reported by ntp. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
