In article <[EMAIL PROTECTED]>, Serge Bets <[EMAIL PROTECTED]> wrote:
> Are you sure? I have here a machine whose natural driftfile is -100 PPM. > It still seems to slew 500 PPM in both directions, not -400 +600. This may be a language problem. ntpdate and the part of the kernel that implement the 500ppm limit have no idea what the static error of the clock is, so if the clock frequency is 1,000,100 micro seconds of clock time per second of real time, the positive slew will be 1,000,600 micro seconds per second, and the negative slew will be 999,600 micro seconds per second. It cannot slew at 1,000,500 or 999,500 because it has no idea that it is already in error by 100. Internally, though, it will be using these figures as the number of microseconds to add to the software clock for every HZ clock interrupts, but HZ clock interrupts won't be exactly one second. However, if you have an error of 100 ppm, it is worth using tickadj to cancel the whole 100ppm's, in which case it's normal rate will be 999,900 microseconds per HZ interrupts and the positive and negative slew adjustments will give values, which, when cancelled by the static frequency error, will result in real time slew rates of +/- 500ppm. I may have signs wrong, but that doesn't affect the argument. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
