[ntp:questions] NTPD Sync. Problem
garrett.hennessey at gmail.com
Wed Dec 20 16:51:57 UTC 2006
Thanks to everyone who responded. The server at 192.168.1.150 is
temporarily using its local clock as well, but this will not be the
case when this system is deployed.
I changed the stratum of the 192.168.1.161 local time to 12 as
suggested. Everything seems happy now.
Thanks again for your help.
Steve Kostecke wrote:
> On 2006-12-19, Garrett <garrett.hennessey at gmail.com> wrote:
> > remote refid st t when poll reach delay offset jitter
> > 127.127.1.1 .LOCL. 16 l 2 64 377 0.000 0.000 0.001
> ntpd is not using the undisciplined local clock because it is operating
> at Stratum 16. You need to modify your ntp.conf to fix this.
> > 192.168.1.150 .LOCL. 1 u 5 64 0 0.000 0.000 0.000
> ntpd has been able to establish an association with this server (because
> the refid, stratum and type are set). But, as has been stated elsewhere,
> ntpd has not received an NTP packet from 192.168.1.150 during the last 8
> poll intervals.
> Have you checked the configuration of 192.168.1.150 to ensure that you
> are allowed access?
> 192.168.1.150 is claiming to be a Stratum-1 server even though it is
> "synced" to it's undisciplined local clock. This is generally frowned
> upon since it can allow a low quality time source to masquerade as real
> time source.
> > I am running this on a linux system which I want to serve time to other
> > computers on my local network when the primary time server is
> > unavailable.
> Just make sure that the strata of the undisciplined local clocks on both
> time servers is _not_ the same.
> > The linux system also should sync its time to the primary
> > time server when that computer is available (it won't be always), and
> > when it's not available it should serve it's local time to the other
> > clients on the network.
> Please keep in mind that, in this configuration, the ntpd in the .150
> server will be following that system's drifting mother board clock.
> And the .161 server will either be following it's own drifting mother
> board clock _or_ it will be attempting to converge on the .150 server's
> drifting mother board clock. So the clients will be following a moving
> target. Don't expect extremely tight coupling.
> > Primary Time Server: 192.168.1.150
> > The linux server IP: 192.168.1.161
> > Here's my ntp.conf for the linux server:
> > server 127.127.1.1
> > fudge 127.127.1.1 stratum 16
> Change the 16 to 11 or 12.
> > server 192.168.1.150
> Append iburst to this line to speed up synchronization w/ this server.
> > driftfile /var/lib/ntp/drift
> > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
> This restrict statement is not breaking anything. But you've left the
> default restriction, for everyone else other than 192.168.1.0/24,
> _less_ restrictive. I'd change this to 'restrict default nomodify
> > The other clients on the network are able to get time from the linux
> > server,
> The .161 server is unsynchronized. You clients should not be accepting
> time from it.
> > but it's serves the local time which is different from the time
> > at 192.168.1.150.
> The .161 server can't serve time because it is not synchronized.
> > It never updates it's local time to that of 192.168.1.150 (primary
> > time server).
> Check the .150 server configuration.
> If possible, post the .150 server ntp.conf file and 'ntpq -p' billboard
> so that we can see them.
> > What am I missing here?
> Some real sources of time.
> Steve Kostecke <kostecke at ntp.isc.org>
> NTP Public Services Project - http://ntp.isc.org/
More information about the questions