Unruh wrote: > David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>> I should also have pointed out that the 500ppm slew rate limit is >> imposed by *n*x kernels, not by ntpd. In the case of -x, which forced > > No it is not. the kernel limit is 1 part per 10, by altering the tick rate. > There are two adjustment parameters, the tickrate and the frequency. ntp > uses only the frequency adjustment which is limited to 500PPM, and does not > adjust the tick rate. We are talking about the user space discipline. That was written for the adjtime (no-x) system call, even if it might sometimes now use adjtimex. In user discipline mode, it does not directly control the frequency at all. In V3, it simply divides the phase correction into 4 second chunks and asks the kernel to slew by the appropriate amount each 4 second interval. I think v4 does this every second. The kernel then runs the clock fast or slow for enough of that period to apply the period's phase correction. With some kernels, the last tick may be at 100, 200, 300, 400 or 500ppm, although some are limited to just using 500ppm. The result is that the effective frequency is a three level squarish wave, typically alternating between zero and just one of the polarities, most of the time. The phase error is the integral of this, so has a sawtooth pattern. I think the tick field is there to support another legacy system call tickadj, which allowed one to modify this value and the value that corresponded to the 500ppm slew rate, used during adjtime (no-x) corrections. I think that tickadj wasn't universal across *n*ces, and it isn't present in Linux 2.6. adjtime seems to be implemented in libc, presumably in terms of adjtimex. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
