Matthias Fuchs wrote: > > I am trying to understand ntpd's -x option. From the ntpd documentation > I expect ntpd to adjust the (system-)time in all situations when -x > is used. The only exception I see is when the system time is totally wrong
That' not what happens. It will still step if the error exceeds 10 minutes (600 seconds). In general, you don't want to use this option, as it makes the system only safely usable as a pure leaf client and it turns off the kernel time discipline. -x sets clock_max to 600 (seconds) but clock_max > 0.5 forces kernel time discipline off. The latter is true whether you use tinker or -x to set clock_max. > (more than 1000s) ntpd will see this as an error and exit. This can be > avoided through the "tinker panic 0" configuration. > > Right? > > But now, when I start ntpd with the -x option and an offset of > about 30s before ntpd is started, I get error messages like this > > frequency error 557 PPM exceeds tolerance 500 PPM > Slew is in part proportional to offset. If the offset is too high the slew will get clamped at 500ppm. Either it will eventually settle, or the system will hunt forever. This is one of the reasons why a 128ms limit is imposed in normal operation. > Also there seems to be not regulation at all and ntptime reports > errors: > > ~# ntptime > ntp_gettime() returns code 5 (ERROR) As noted above, -x disables the kernel time discipline, as it is not designed to cope with large offsets and rate limited slews. ntptime is an interface to the kernel time discipline. If you want to avoid slews without using a good time source and good initial conditions, you will have to accept that the, less refined, user space time discipline will be used with simple tickadj calls. Code details checked on 4.2.4p4. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions