OpenVZ Forum


Home » General » Support » *SOLVED* Clock Drift / NTPd - CentOS OpenVZ Host - Problems
Re: *SOLVED* Clock Drift / NTPd - CentOS OpenVZ Host - Problems [message #7153 is a reply to message #6301] Thu, 05 October 2006 13:06 Go to previous messageGo to previous message
tchipman is currently offline  tchipman
Messages: 28
Registered: June 2006
Junior Member
Hi All,

Thought I should post another followup here, since the issue has evolved a fair bit since my last post. Since making the tweak with "burst / iburst" to my ntp config, it appeared to do the trick .. time wasn't ever so far out.

However, I was still seeing not-great values reported via "ntpq -p", ie, offset values in the thousands. Observing my /var/log/messages file, it was also clear that the ntp daemon was struggling, with frequent shifts of the NTP time source being used, and occasional "time warp" clock resets (ie, 120second adjustments being made periodically), approx as follows:

---PASTE---

from /var/log/messages ...

Oct 1 04:20:42 hydra ntpd[6350]: synchronized to 129.1X3.1.100, stratum 2
Oct 1 04:20:47 hydra ntpd[6350]: no servers reachable
Oct 1 04:23:20 hydra ntpd[6350]: synchronized to 129.1X3.5.100, stratum 2
Oct 1 04:24:18 hydra ntpd[6350]: synchronized to 129.1X3.105.63, stratum 3
Oct 1 04:24:21 hydra ntpd[6350]: no servers reachable
Oct 1 04:24:35 hydra ntpd[6350]: synchronized to 129.1X3.105.63, stratum 3
Oct 1 04:25:31 hydra ntpd[6350]: no servers reachable
Oct 1 04:27:03 hydra ntpd[6350]: synchronized to 129.1X3.1.100, stratum 2
Oct 1 04:25:16 hydra ntpd[6350]: time reset -106.823489 s
Oct 1 04:26:35 hydra ntpd[6350]: synchronized to 129.1X3.1.100, stratum 2
Oct 1 04:26:39 hydra ntpd[6350]: no servers reachable
Oct 1 04:27:54 hydra ntpd[6350]: synchronized to 129.1X3.1.100, stratum 2
Oct 1 04:28:51 hydra ntpd[6350]: synchronized to 129.1X3.105.63, stratum 3
Oct 1 04:28:53 hydra ntpd[6350]: no servers reachable
Oct 1 04:29:05 hydra ntpd[6350]: synchronized to 129.1X3.1.100, stratum 2

---ENDPASTE----

Yesterday I was puttering around with this a bit more. Some reading I came across suggested that a boot-flag option, "clock=pmtmr" might be of some use. I rebooted with this, but it was clear from Dmesg that it was being ignored, telling me:

Warning: clock= override failed. Defaulting to PIT

So, I tweaked my boot parameters again and removed my boot parameter, "acpi=off", since I hadn't tested behaviour thus with my "new ntp config" (using burst / iburst).

Since the change, NTP behaviour is *exactly* what I would have wanted - the time source is no longer having trouble, offset values are reasonable, and the clock is solid. ie:


[root@hydra log]# ntpq -p
remote refid st t when poll reach delay offset jitter
============================================================ ==================
*sxt-np-1.XXXX.D 128.XXX.150.93 2 u 111 1024 377 6.370 -0.550 1.929
+KIL-NP-1.XXXX.D XXX.246.168.9 2 u 133 1024 377 3.472 0.198 5.219
Router.Phys.OCE XXX.173.5.100 3 u 100 1024 357 704.997 350.089 111.705

and additionally in /var/log/messages,


Oct 4 17:44:44 hydra ntpd[10375]: ntpd 4.2.0a@1.1190-r Sun Aug 13 01:49:12 CDT 2006 (1)
Oct 4 17:44:44 hydra ntpd: ntpd startup succeeded
Oct 4 17:44:44 hydra ntpd[10375]: precision = 4.000 usec
Oct 4 17:44:44 hydra ntpd[10375]: Listening on interface wildcard, 0.0.0.0#123
Oct 4 17:44:44 hydra ntpd[10375]: Listening on interface lo, 127.0.0.1#123
Oct 4 17:44:44 hydra ntpd[10375]: Listening on interface eth0, XXX.173.23.235#123
Oct 4 17:44:44 hydra ntpd[10375]: Listening on interface eth2, XXX.168.111.235#123
Oct 4 17:44:44 hydra ntpd[10375]: kernel time sync status 0040
Oct 4 17:44:44 hydra ntpd[10375]: frequency initialized -86.648 PPM from /var/lib/ntp/drift
Oct 4 17:44:51 hydra ntpd[10375]: synchronized to XXX.173.5.100, stratum 2
Oct 4 17:44:59 hydra ntpd[10375]: kernel time sync disabled 0041
Oct 4 17:46:04 hydra ntpd[10375]: kernel time sync enabled 0001
Oct 4 22:16:37 hydra sshd(pam_unix)[4782]: session opened for user chipmant by (uid=0)

ie, note that once sync was enabled at 17:46:04, it hasn't been lost / nor has it drifted / the clock is solid now.

So - things are infinitely better now as they stand as compared to the original state. I'm not sure if this mess of a history will help anyone else, ever, but I thought I should post the end-of-story here... just in case.

--Tim Chipman

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: problem with last kernel/2.6.18/028stab053.5 vps kernel: unregister_netdevice
Next Topic: Install from Live CD?
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Oct 20 20:44:15 GMT 2024

Total time taken to generate the page: 0.05587 seconds
Powered by FUDforum Powered by Virtuozzo Containers