In article <[EMAIL PROTECTED]>, Steve Kostecke <[EMAIL PROTECTED]> wrote:
> If your clock is less than 128ms off ntpd slews it. The slew will take > the same amount of time regardless of how ntpd is running (e.g. as a > daemon or via a cron-job w/ -gq). My impression is that -gq will be faster. ntpdate is certainly faster. That's because it will slew at the maximum rate all the time, whereas the filtering in daemon mode ntpd will cause the rate to ramp up slowly and to ramp down as it gets close to the nominal time. This, I think is, the cause of one of the concerns that people have about ntpd startup time. If the initial offset error, for a warm start, is >~ 1 standard deviation, but < 128ms, an optimum approach would be to slew at maximum rate until one either crosses the estimated zero error, or, possibly about 1 SD from it, but ntpd doesn't do this and has no carry over of the SD to allow it to do so. It probably should not report a valid state until the initial slew completes, which may make some people unhappy. I don't think stability considerations arise during the inial slew, so a faster slew, if supported, should be acceptable. If it does start reporting valid times earlier, I think the extended period of high tolerance estimates will be worse than any instability due to downstream systems tracking a target that isn't apply the NTP loop filter. There is also quite a lot of loose terminology being used. The following may not be exhaustive, but: Step doesn't step to the correct time, it steps to the time it estimated from a weighted average of recently polled servers. When you allow the system to run in daemon mode, it will get much closer to the correct time, as the loop filtering will smooth out short term variations in the offset measurements. Whilst the actual step is instantaneous, verifying the need for a step takes a significant amount of time (in the most general case, about 15 minutes). The 0.5ms/s slew rates are relative to the static error in the machine clock, so they can reduce to almost 0 in one direction and almost 1ms/s in the other, in a system with a clock at the margins of usability. Although the effective slew rate will almost always be less than this, and should be so once locked, the user space time discipline will actually achieve this by a sawtooth with a frequency of 0.25 Hz, in older versions, and possibly 1Hz in later versions. This sawtooth will be at either maximum slew or zero slew at any instant. The typical kernel support for the user space discipline will actually step every clock tick. It is theoretically possible for kernel disciplines to implement an exact slew rate down to the oscillator period. > Once ntpd has run long enough to determine the correct PLL frequency, > and write it to the drift file, ntpd restarts are very quick. Only if the initial measured offset exceeds 128ms. If it is less than this, it will run the normal loop filter and take a signifcant amount of time to converge. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
