In article <[EMAIL PROTECTED]>, Harlan Stenn <[EMAIL PROTECTED]> wrote:
> Assuming the OS plays by the rules, there is no difference in how long it > will take to slew a difference of X regardless of the choice of ntpd -gq, > ntpdate, sntp, whatever. You have to qualify this by: 1) as long as X is the same; 2) as long as it is instructed to slew at the maximum rate. If the daemon is using the user space time discipline code, it instructs the kernel to slew by (for NTP v3) no more than 2ms at a time, and only in exceptional circumstances does it request the full 2ms. I think the current ntpd uses a one second update, so slews by no more than 500 micrososeconds at a time. Averaged over the update interval, the slew rate is likely to be a lot less than 0.5ms/s. If the kernel time discipline is in use, the kernel is generally requested to slew at less than 0.5ms/s, except if it starts a very long way from the target, or has been slewing for some time and not cleared the phase error. More samples will typically arrive before the initial offset has been cleared. There is no slewing state in ntpd for initial "errors" less than 128ms, it is in the normal discipline mode. Actually, there is no "slewing" state at all. > Ditto for a step. Steps are instantaneous, although the daemon will sometimes take about quarter of an hour to confirm the need for them. > If you want the time set well "reasonably quickly" and stay "correct", set > things up properly, run 'ntpd -g' and have a known-good drift file. Your > ntpd will be in state 4 in about 11 seconds. In addition, you need to ensure that the initial offset is > 128ms, otherwise there is no step and you have to wait the full loop time constant at its fastest setting. > I am hazy on this one. I *think* ntpd will DTRT thing here - it either > knows how to report the correct time during a slew period or it reports that > it is unsync'd and not ready to offer correct time. As I remember it, ntpd will start reporting an OK state as soon has enough upstream samples, which I think is the same condition for starting the slew. If the initial offset is 127ms, it will be on one side of the "correct" time, for the full loop time constant. There is no distinct slew state. Checking the 4.2.0 code, there is a slight special case for the very first sample, in that no permanent adjustment is made to the frequency, but, from the second sample, the full normal state handling is in effect, even though the phase error may still be in the 120ms range. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
