Clock drift

Marvell Orion based
Post Reply
KeyCat
Posts: 70
Joined: Tue Apr 05, 2011 8:07 am

Clock drift

Post by KeyCat » Tue Aug 30, 2011 4:08 pm

Just installed openntpd to sync the clock but noticed a heavy clock drift and it seems to get worse over time, below is a snippet from the syslog. Anyone knows a cure for this?

Code: Select all

...
Aug 30 15:43:59 NSA-220 ntpd[646]: adjusting local clock by -35.432203s
...
Aug 30 15:47:38 NSA-220 ntpd[646]: adjusting local clock by -35.775886s
...
Aug 30 15:49:13 NSA-220 ntpd[646]: adjusting local clock by -35.989286s
...
Aug 30 15:50:18 NSA-220 ntpd[646]: adjusting local clock by -36.873707s
...
Aug 30 15:54:33 NSA-220 ntpd[646]: adjusting local clock by -36.982399s
...
Aug 30 15:55:05 NSA-220 ntpd[646]: adjusting local clock by -37.090511s
Aug 30 15:55:36 NSA-220 ntpd[646]: adjusting local clock by -37.195389s
...
Aug 30 15:56:10 NSA-220 ntpd[646]: adjusting local clock by -38.104529s
...
/KC

Mijzelf
Posts: 6207
Joined: Mon Jun 16, 2008 10:45 am

Re: Clock drift

Post by Mijzelf » Tue Aug 30, 2011 5:50 pm

That log is ridiculous. The correction is always -36 seconds, but the intervals differ. I think somehow ntpd doesn't succeed in actually adjusting the clock.
Can you adjust the time manually, and does that influence the correction logged by ntpd?

KeyCat
Posts: 70
Joined: Tue Apr 05, 2011 8:07 am

Re: Clock drift

Post by KeyCat » Tue Aug 30, 2011 6:16 pm

I agree that it looks wierd (note that I cut out irrelevant lines and replaced with "...") but it's not alwas -36 seconds... here is the log a bit earlier.

Code: Select all

Aug 30 14:07:55 NSA-220 ntpd[646]: adjusting local clock by -16.170700s
...
Aug 30 14:11:02 NSA-220 ntpd[646]: adjusting local clock by -16.427764s
...
Aug 30 14:12:39 NSA-220 ntpd[646]: adjusting local clock by -16.976646s
..
Aug 30 14:15:20 NSA-220 ntpd[646]: adjusting local clock by -17.771961s
...
Aug 30 14:18:59 NSA-220 ntpd[646]: adjusting local clock by -18.205621s
...
Aug 30 14:21:04 NSA-220 ntpd[646]: adjusting local clock by -18.534672s
Aug 30 14:22:41 NSA-220 ntpd[646]: adjusting local clock by -19.310812s
...
Aug 30 14:26:28 NSA-220 ntpd[646]: adjusting local clock by -19.754983s
Can you adjust the time manually, and does that influence the correction logged by ntpd?
Yes.

After some more searching I think "ajdtimex" is the answer but I'm still trying to understand how to actually use it to adjust the system clock. Any hints or pointers appreciated...

/KC

Mijzelf
Posts: 6207
Joined: Mon Jun 16, 2008 10:45 am

Re: Clock drift

Post by Mijzelf » Tue Aug 30, 2011 6:41 pm

I still think that ntpd doesn't actually adjust the clock, but only logs the difference between the clock and the real time.

In that case
Aug 30 14:11:02 NSA-220 ntpd[646]: adjusting local clock by -16.427764s
Aug 30 15:50:18 NSA-220 ntpd[646]: adjusting local clock by -36.873707s
gives a clock drift of about 20 seconds in 1 hour 40 minutes, which is 0,2 seconds a minute. Well, that's reasonable.

But if ntpd is actually adjusting
Aug 30 15:49:13 NSA-220 ntpd[646]: adjusting local clock by -35.989286s
Aug 30 15:50:18 NSA-220 ntpd[646]: adjusting local clock by -36.873707s
Aug 30 15:54:33 NSA-220 ntpd[646]: adjusting local clock by -36.982399s
the first two lines give a drift of 36 seconds in 61 seconds, while the next 2 lines give a drift of 36 seconds in the next 4 minutes. That would be weird.

You can adjust the clock drift partly with adjtimex. From the man pages:
-t val, --tick val
Set the number of microseconds that should be added to the system time for each kernel tick interrupt. For a kernel with USER_HZ=100, there are supposed to be 100 ticks per second, so val should be close to 10000. Increasing val by 1 speeds up the system clock by about 100 ppm, or 8.64 sec/day. tick must be in the range 900000/USER_HZ...1100000/USER_HZ. If val is rejected by the kernel, adjtimex will determine the acceptable range through trial and error and print it. (After completing the search, it will restore the original value.)
-f newfreq, --frequency newfreq
Set the system clock frequency offset to newfreq. newfreq can be negative or positive, and gives a much finer adjustment than the --tick switch. When USER_HZ=100, the value is scaled such that newfreq = 65536 speeds up the system clock by about 1 ppm, or .0864 sec/day. Thus, all of these are about the same:
--tick 9995 --frequency 32768000
--tick 10000 --frequency 6553600
--tick 10001 --frequency 0
--tick 10002 --frequency -6553600
--tick 10005 --frequency -32768000
You're loosing about 0.2 seconds a minute, which is 288 seconds a day. So 'adjtimex -t 10033' should eliminate most drift.
And then you'll have to find out why ntpd doesn't correct the time.

KeyCat
Posts: 70
Joined: Tue Apr 05, 2011 8:07 am

Re: Clock drift

Post by KeyCat » Tue Aug 30, 2011 7:02 pm

Mijzelf wrote:I still think that ntpd doesn't actually adjust the clock, but only logs the difference between the clock and the real time.
I will look into ntpd, maybe it is as you say. When I refered to setting it manually I used another utility named "ntpdate". I will see if I can sync manually using "ntpd" and also read up on "adjtimex".

/KC
Last edited by KeyCat on Sun Sep 04, 2011 7:59 am, edited 1 time in total.

KeyCat
Posts: 70
Joined: Tue Apr 05, 2011 8:07 am

Re: Clock drift

Post by KeyCat » Sun Sep 04, 2011 7:58 am

Sorry for the delay but here are the results regarding openntpd...

Managed to get openntpd syncing the clock after I reinstalled the package (?) and looking at the logfiles it seems to do it's job.

Code: Select all

...
Aug 31 12:54:37 NSA-220 ntpd[1973]: adjusting local clock by -0.225354s
Aug 31 12:58:48 NSA-220 ntpd[1973]: adjusting local clock by -0.224143s
Aug 31 13:03:34 NSA-220 ntpd[1973]: adjusting local clock by -0.221547s
Aug 31 13:08:09 NSA-220 ntpd[1973]: adjusting local clock by -0.218798s
Aug 31 13:16:32 NSA-220 ntpd[1973]: adjusting local clock by -0.217146s
Aug 31 13:16:32 NSA-220 ntpd[1974]: clock is now synced
Aug 31 13:20:36 NSA-220 ntpd[1973]: adjusting local clock by -0.248118s
Aug 31 13:20:36 NSA-220 ntpd[1974]: clock is now unsynced
Aug 31 13:25:43 NSA-220 ntpd[1973]: adjusting local clock by -0.245560s
...
However after having the daemon running for a few days I noticed it for some reason kills itself with following in the log file and I had to manually restart it...

Code: Select all

...
Sep  2 18:35:00 NSA-220 ntpd[3207]: dispatch_imsg in main: pipe closed
Sep  2 18:35:00 NSA-220 ntpd[3207]: Lost child: child exited
Sep  2 18:35:00 NSA-220 ntpd[3207]: Terminating
...
Sep  3 11:14:23 NSA-220 ntpd[3399]: fatal: client_query socket: Address family not supported by protocol
Sep  3 11:14:23 NSA-220 ntpd[3398]: dispatch_imsg in main: pipe closed
Sep  3 11:14:23 NSA-220 ntpd[3398]: Lost child: child exited
Sep  3 11:14:23 NSA-220 ntpd[3398]: Terminating
...
Looks like I have to find another ntp daemon since openntpd 3.9 seems to have several issues...

/KC

Mijzelf
Posts: 6207
Joined: Mon Jun 16, 2008 10:45 am

Re: Clock drift

Post by Mijzelf » Sun Sep 04, 2011 6:47 pm

I wonder if you are missing some /dev/clock device node. I had a look on my box, and it has a /dev/rtc:

Code: Select all

crw-r--r-- 1 root root 10, 135 2009-12-07 20:20 rtc
Does your box have one too?

KeyCat
Posts: 70
Joined: Tue Apr 05, 2011 8:07 am

Re: Clock drift

Post by KeyCat » Mon Sep 05, 2011 7:28 am

Just checked and yes I do...

Code: Select all

cj@NSA-220:/dev# ls -l rtc
crw-r--r-- 1 root root 10, 135 2009-12-23 20:12 rtc
/KC

KeyCat
Posts: 70
Joined: Tue Apr 05, 2011 8:07 am

Re: Clock drift

Post by KeyCat » Thu Sep 08, 2011 6:40 am

Managed to fix to system clock drift from 16.2 sec/60 min to 0.19 sec/60 min and that is good enough for me (ended up using adjtimex -t 9960). So now I really don't need a NTP daemon running and just runs ntpdate every hour.

Code: Select all

 7 Sep 16:20:01 ntpdate[3763]: adjust time server 130.236.254.17 offset -0.191646 sec
 7 Sep 17:20:01 ntpdate[3773]: adjust time server 192.121.13.5 offset -0.195563 sec
 7 Sep 18:20:01 ntpdate[3789]: adjust time server 92.244.0.126 offset -0.194295 sec
 7 Sep 19:20:01 ntpdate[3799]: adjust time server 79.136.86.64 offset -0.193558 sec
I suspect the NTP daemon had issue due to my relatively large drift and would work better now but with current drift crontab is all I need.

/KC

Post Reply