unruh writes: > On 2013-07-09, David Woolley <david@ex.djwhome.demon.invalid> wrote: > > On 09/07/13 09:07, Miroslav Lichvar wrote: > > > >> > >> I think the kernel would have to be recompiled with a smaller > >> MAXFREQ_SCALED constant or ntpd recompiled with smaller NTP_MAXFREQ if > >> the kernel discipline is disabled. > >> > > > > The kernel discipline will be disabled if he forces slewing. > > That is of course another problem. Maybe he should switch to chrony > which does allow slewing even of large offsets, and does it via kernel > discipline. (Unfortunately it works only on Linux or BSD, so if he is > using windows, that suggestion does not work). Chrony will also allow > slewing faster than 500PPM so that problem does not occur (unless the > slew rate gets up to 100000PPM)
That would be fine if he was also OK with "blindly following the current leader" instead of "tracking the best source of time". Changing the slew rate affects the behavior of the system clock, and since the NTP algorithms have been thoroughly tuned and tested in a very wide range of conditions, changing the slew rate like this can (and likely will) introduce unstable oscillations in the networked collection of systems. -- Harlan Stenn <st...@ntp.org> http://networktimefoundation.org - be a member! _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
