[ntp:questions] time to sync vs ptp?

David Lord snews at lordynet.org
Thu May 30 21:22:07 UTC 2013

matthew.garman at gmail.com 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
 > After doing this, the clock's offset was *increasing* after an
   hour.  Offset is measured by "ntpdate -q peer".
 > 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.

You might as well keep using the date command and forget about
ntpd. You are fighting ntpd and have little chance of winning.

After a reboot my pcs usually are within 1 ms within 30 minutes,
and that's about the best they will do in my non temperature
controlled location. Periods better than 300 usec do happen but
they depend on the weather and the pcs being otherwise idle. Ntpd
relies on establishing a drift file, /var/db/ntp/ntpd.drift on
my systems. The drift file can take many hours to be established
and many days if you keep experimenting and making changes.

If you need to experiment then try a more recent version, I'm
using 4.2.6p5 on NetBSD (I've tried some 4.2.7 versions but had
no success).


 > 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?
 > For what it's worth, I've recently been playing with the open-source 
PTPv2 dae
mon.  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?
 > I know I'm using very figurative/non-specific terminology here... but 
I'm tryi
ng 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.
 > Thanks,
 > Matt

More information about the questions mailing list