| View previous topic :: View next topic |
| Author |
Message |
Frood
n00b
Joined: 14 Mar 2003
Posts: 7
Location: Boston, MA USA
|
 Posted: Mon Aug 23, 2004 7:31 am Post subject: ntpd diverges from real time |
 |
|
I've got a bizarre and very frustrating problem with ntpd. It seems that ntpd is determined to desynchronize my clock from the servers. Here's what happens:
| Code: |
triumph etc # init.d/ntpd stop
* Stopping ntpd... [ ok ]
triumph etc # ntpdate -b sundial.columbia.edu
23 Aug 02:18:45 ntpdate[12802]: step time server 128.59.59.177 offset 545.377332 sec
triumph etc # init.d/ntpd start
* Starting ntpd... [ ok ]
triumph etc # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
rubidium.broad. .GPS. 1 u 15 64 1 9.189 408.981 0.008
avi-lis.gw.ligh .CDMA. 1 u 12 64 1 92.733 558.497 0.008
CYAN.SRV.CS.CMU rackety.udel.ed 2 u 4 64 1 91.763 721.655 0.008
filbert.cc.colu gnomon.cc.colum 2 u 13 64 1 20.806 444.147 0.008
|
A minute or so later, the offset from all servers has increased:
| Code: |
triumph etc # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
rubidium.broad. .GPS. 1 u 23 64 3 27.087 1824.91 1415.92
avi-lis.gw.ligh .CDMA. 1 u 18 64 3 58.649 1946.52 1388.02
CYAN.SRV.CS.CMU rackety.udel.ed 2 u 10 64 3 147.753 2234.09 1512.44
filbert.cc.colu gnomon.cc.colum 2 u 21 64 3 27.185 1923.27 1479.13
|
Another minute later:
| Code: |
triumph etc # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
rubidium.broad. .GPS. 1 u 12 64 77 20.692 9893.25 1578.66
avi-lis.gw.ligh .CDMA. 1 u 8 64 77 50.448 10027.8 1628.75
CYAN.SRV.CS.CMU rackety.udel.ed 2 u 65 64 37 108.930 8608.22 1549.61
filbert.cc.colu gnomon.cc.colum 2 u 13 64 77 48.883 9875.09 1561.83
|
This goes on and on, with the daemon driving my clock further and further away from real time. Eventually it gets to the point where I can sit and watch the system clock fall minute by minute further behind the clock sitting on my desk.
The logfile gives me no clue what's going on:
| Code: |
23 Aug 02:18:54 ntpd[12876]: frequency initialized -140.310 from /var/lib/ntp/ntp.drift
23 Aug 02:18:54 ntpd[12876]: running as uid(123)/gid(123) euid(123)/egid(123).
|
The bizarre thing about this is that everything was fine until today. The clock was in perfect sync with the rest of the world. I didn't change anything on the system (I haven't even done so much as an an emerge sync since last week.)
There's no /etc/adjtime file. I've also tried stopping the daemon, deleting /var/lib/ntp/ntp.drift, and then restarting it. Still, no luck. The same thing happens; the daemon just pushes itself further and further out of sync with the outside world.
I'm running the 2.6.7-gentoo-r11 kernel.
Can anyone tell me what's going on? |
|
| Back to top |
|
 |
Frood
n00b
Joined: 14 Mar 2003
Posts: 7
Location: Boston, MA USA
|
| Posted: Tue Aug 24, 2004 4:52 am Post subject: |
|
|
Okay, it seems to be running fine now. This is really bizarre. I didn't change anything, and suddenly it works.
Well, I'd still love to know what's going on if anyone has an idea. |
|
| Back to top |
|
|
yinyang
n00b
Joined: 29 Jul 2003
Posts: 65
Location: Berlin/Germany
|
| Posted: Tue Aug 24, 2004 7:28 am Post subject: |
|
|
My guess is that your drift file (it seems its position was changed from /etc/adjtime to /var/lib/mis/ntp.drift at least on my system) still said your clock wasn't correct before you launched the ntp daemon. Actually ntp doesn't set your time correct (thats what ntpdate is for) but rather speeds up or slows down your clock so you can "catch up" with the correct time.
So you basically set the correct time with ntpdate but you still had a speedy/slow clock. After a while though ntpd was able to adapt to this.
But as I said its just a guess  |
|
| Back to top |
|
|
larand54
l33t
Joined: 20 Feb 2004
Posts: 695
Location: Sweden
|
| Posted: Tue Aug 24, 2004 8:15 am Post subject: |
|
|
The daemon isn't driving your clock away, it's your clock that's speeding away.
ntp want's to have some time to calculate the new "drift" value and until it satisfied, your clock is drifting away. That's normal but your clock is quite speedy . But when ntp is satisfied it adjust your clock and slows it down with the new values in the drift file.
In some way you probably lost your old drift-file. |
|
| Back to top |
|
|
Frood
n00b
Joined: 14 Mar 2003
Posts: 7
Location: Boston, MA USA
|
| Posted: Wed Aug 25, 2004 7:09 am Post subject: |
|
|
Okay, thanks to both of you for explaining this to me. I suppose I just need to be more patient with ntpd in the future.
(And I guess this means my system clock really sucks.) |
|
| Back to top |
|
|
|
Other Things Gentoo
