Danny Mayer wrote: > No, ntpd deliberately limits frequency changes to 500 PPM. That's hard > coded. You need to avoid using anything greater than that as Dave has > explained. That would be the reason why it taks ntpd longer to bring the > clock back to the right time.
Assuming that the static frequency error is consistent with a medium to high quality motherboard, slew rate limiting should only kick in if the clock was out by more than the order of a second in the first place, in which case stepping would have to have been inhibited. For normal users the slow convergence is due to loop time constant being more suited to handling gradual temperature variations than startup transients of frequency hits. The slew rate limit, for zero static error, is 1s/2000s. The loop first zero crossing I seem to be remember being quoted at about 3000s, with minpoll set for 64 and the slew rate not being exceeded. The resulting peak slew rate is more than 1/3000, for a 1 second error, but will be well below 1/2000 for a 128ms error. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions