On 2013-05-30, [email protected] <[email protected]> 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.
Why in the world would you use such an old version of ntp and an old version of the distro. Many many security issues have arisen and been patched since then. > > After doing this, the clock's offset was *increasing* after an hour. Offset > is measured by "ntpdate -q peer". > Yes, the offset increasing after an hour is certainly possible and even likely if the drift rate is wrong. That is how ntpd words. > From what I've gathered about NTP, it attempts to adjust clocks "gently" and > "slowly". What I'm doing now, and I'm sure this will make some cringe, is to > run "ntpdate -u -b peer" in a loop, sleeping two seconds between runs. I > understand this is the opposite of slowly and gently. Yes, and this still does not address the problem of the drift rate. ntpd has to run a while to figure out what the right drift rate is. Unfortunately it does so by a Markovian (no memory) feedback, which is slow and suffers from exactly the kind of behaviour you see. If you want something faster ( and more accurate) run chrony instead. (It keeps a memory and thus lcan figure out where it wants to be in terms of offset and drift far faster than can ntpd) > > But is there a way to somehow combine the behavior of both? Be a little more > aggressive like ntpdate, but retain some of the "politeness" of the daemon? As I said, ntpdate does not adjust the drift rate. And ntpd IS more aggressive if the offset exceeds 128ms. It will then step the clock (a la ntpdate). Note that ntpdate simply steps the clock, which means it canstep backwards which can mess up your filesystem. > > For what it's worth, I've recently been playing with the open-source PTPv2 > daemon. It appears to "beat the system clock into submission" rather > quickly---I see syncs occurring typically in a matter of minutes. Is there a > way to make NTP act more like PTP with regards to getting clocks sync'ed > quickly? David Mills has a very strongly held philosophy about how ntpd should behave, and he is not about to change that. If you like ptpv2 better, use it. > > I know I'm using very figurative/non-specific terminology here... but I'm > trying to wade through all the NTP documentation, but it quickly gets over my > head, and I'm not sure what's applicable and what's not. Hopefully this list > can help me get a better handle on this stuff. You are not going to change anyone's mind with "I am ignorant, and have no idea what I am talking about, but could you not change ntpd in the following way." You are far better off finding a program that behaves the way you want, and use that. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
