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. Cheers, Garrett Steve Kostecke wrote: > On 2006-12-19, Garrett <[EMAIL PROTECTED]> 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 > notrap'. > > > 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 <[EMAIL PROTECTED]> > NTP Public Services Project - http://ntp.isc.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
