On 2013-05-31, Rob <[email protected]> wrote: > [email protected] <[email protected]> wrote: >> On Thursday, May 30, 2013 2:21:15 PM UTC-5, Rob wrote: >>> > I have a server running NTP 4.2.2 (as part of the RedHat 5.7 release). >>> > Last night I changed it's /etc/ntp.conf file, specifically the "server >>> > xyz" line to point to a new NTP server. >>> >>> > After doing this, the clock's offset was *increasing* after an hour. >>> > Offset is measured by "ntpdate -q peer". >>> >>> >>> This is a wellknown problem. >>> >>> When you do a couple of ntpd shutdown/restarts e.g. because you >>> >>> a experimenting with different server configurations, the combination >>> >>> of ntpd and the kernel goes haywire and it will actually steer the time >>> >>> the wrong way. >>> >>> >>> >>> Just wait a day or so, and it will have solved itself. >> >> >> Would it be possible to provide a link or point me to some reference >> material where I can read more about this issue? > > I think the issue is never acknowledged by the author. He believes > his system is proven to be stable. It is only in practice that we > see this happen, it cannot happen in theory.
No. He will acknowlege that it can happen in theory (I gave a quick handwaving explanation). But he is interested in the long term stability, not the short term behaviour of the system. that kind of behaviour will occur in any feedback system like ntpd uses. Assme that initially the offset is zero, but the rate is wrong by 10PPM. The system will assume initially that everything is fine. It is only when the rate error causes an offset to develop, that ntpd will begin to alter the rate of the clock to correct that offset. It only does this adjustment slowly so it will be a while ( while the offset has wandered even further from zero) for the rate error to have been eliminated., By then the offset is large, so the system will overcorrect to rate to bring the rate back down to zero. If you handle the time factors and the correction magnitude, the resulting system will be almost critially damped so that there is not an oscillation. And if it is close to critical damping then it also does not take too long. to reach that state. It is not unexpected. With memory ( ie knowing what the past offsets were and the rate corrections were) one can much more raplidly approach the stable euqilibrium. That is what chrony does. Tests that both I and Lichvar have done indicate that chrony not only does it much more rapidly approach stability, but also creates a smaller average offset spread than does ntpd in many situations (the spread of offsets are between a factor of 2 to 20 times better than with ntpd). Certainly more tests, under a wider variety of conditions are needed. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
