# Time advances forward slowly over time even with NTPD conf

## mitchro

I have set up ntpd and have set it to point to a time server at the University of MN.  As time goes on, the clock advances approx. 30 every 24 hours.  Does anyone have any idea what is going on?

Thanks

----------

## biznatch

What kernel are you running?

----------

## mitchro

I am running 2.6.11 r5 configured with genkernel.

----------

## thecooptoo

im using 2.6.11-gentoo-r4 and have virtually given up trying to get ntpd to work 

ive tried openntp

fiddling with tickadj

adding iburst  to the conf files 

every server config I can think of 

and it still wont keep up

----------

## mikef

What does ntpd.log say?

----------

## schwicky

Does it sync with the servers?

What is the output of ntpq -p 5-10 minutes after you restarted the ntpdaemon?

----------

## thecooptoo

```
28 Apr 17:12:03 ntpd[28278]: synchronized to 192.168.0.10, stratum=6

28 Apr 17:21:43 ntpd[28278]: time reset +580.050885 s

28 Apr 17:21:43 ntpd[28278]: kernel time sync disabled 0041

28 Apr 17:21:56 ntpd[28278]: synchronized to 213.239.201.102, stratum=2

28 Apr 17:23:01 ntpd[28278]: ntpd exiting on signal 15

28 Apr 17:23:08 ntpd[28293]: parent died before we finished, exiting

```

----------

## schwicky

Ok, it seems the time difference between your clock and the date from ntp is too big to ajust it. 

You should set the time once with ntpdate <ntp-servername> (maybe you can add it to your runlevel "rc-update add npt-client default") and then let ntpd run to stop your clock from ticking away. 

You should also check that you have a /var/lib/ntp/ntp.drift file owned by ntp:ntp. It's the place where the ntp daemon stores how much your clock drifts so that it can automatically ajust it.

----------

## thecooptoo

I do that everytime i adjust the time 

stop the daemon

synchronise it 

restart the daemon

the gap gradually increases, the offset reported by ntpq -p gradually increases  and then  the ntp daemon fails

----------

## mikef

Seems as if ntpdate is resetting your time, but ntpd is not.

One difference I know is that ntpdate uses a high-numbered UDP port, but ntpd uses the privileged UDP port 123. Do you have any problem with this? Perhaps firewall?

When you run ntpq -p do you get reasonable values for when, poll and reach. Especially reach - a good value is 377.

----------

## thecooptoo

router 0s the local server that I will use exclusively when (if)  this  is sorted

I restarted it and resynced it approx 18 hrs ago  - its approx 20 mins slow 

```
     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

 router          LOCAL(0)         6 u  774 1024  377    0.979  1308362 2271.20

 veracity.mcc.ac 194.81.227.227   2 u  758 1024  377   25.820  1307982 2271.58

 www.audaxsystem 193.79.237.14    2 u  760 1024  377   19.308  1307984 2270.00

root@dads UnitPdfs # /etc/init.d/ntpd stop

 * Stopping ntpd...                                                                                             [ ok ]

root@dads UnitPdfs # ntpdate router

Looking for host router and service ntp

host found : router

 2 May 14:54:33 ntpdate[14226]: step time server 192.168.0.10 offset 1311.598279 sec

root@dads UnitPdfs # /etc/init.d/ntpd start

 * Starting ntpd...                                                                                             [ ok ]

root@dads UnitPdfs # date

Mon May  2 14:55:25 BST 2005

root@dads UnitPdfs #

```

As i understand it , its contacting the servers  and working out the difference but just not changing the clock. on my router ntpd seems to work OK. Only difference I tihnk may be relevant (other than GUI stuff) is the router is a 2.4 kernel and the desktop 2.6)

----------

## mikef

Your system clock seems to be running 1600 seconds slow per day. This is a lot. I think a typical figure is about 5-10 seconds per day.

The man page for ntpd says it takes about 2000 secs to correct a one second error, by making small changes to the rate. Perhaps it can't cope.

This is only a guess, I looked for but didn't find a definitive statement about typical inaccuracies.

----------

## thecooptoo

found this in  dmesg whilst looking for something else . Not sure if its relevant

```
Losing too many ticks!

TSC cannot be used as a timesource.

Possible reasons for this are:

  You're running with Speedstep,

  You don't have DMA enabled for your hard disk (see hdparm),

  Incorrect TSC synchronization on an SMP system (see dmesg).

Falling back to a sane timesource now.

```

----------

## schwicky

I have no experience with speedstep and stuff but I don't think it affects the clock. I believe it has only effects on scheduling and that kind of stuff. 

What is interesting in your ntpq output is that your router has a stato of 6 which is kind of high and that there is neither a star nor a plus in front of the server lines which would indicate that your machine is actually synching with them. 

Did you look at the /var/lib/ntp/ntp.drift file? 

Another thing you might try it to sync to only one server, for example your router, and see if there is a difference. Just to be sure it's a firewall issue, or the like. 

Do you have any restict rules in your config file? I usually put

```
restrict <servername> nomodify noquery notrap
```

for each server I sync to.

----------

