Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Quick NTP question

Status
Not open for further replies.

reinstalled

IS-IT--Management
Feb 18, 2003
178
HI,

If I set up my Solaris box (8, 9, or 10) as an NTP client (Copying ntp.client to ntp.conf) will it "ask" the servers listed or will it just sit and wait for broadcasts? The servers are Internet based.

so my entries are
server IP Address
server IP Address


Thanks,
 
From memory (mine not the servers lol) for at least Sol 8-9, when you restart xntpd this will first run ntpdate that will try and access your NTP servers and jump the date and time to that provided by the NTP servers.

Once that completes then xntpd will take over the port/socket and sit and wait for a broadcast from the NTP servers.

Depending on what other settings you have configured the time will be slewed up or down over a period to keep your time in sync.

IHTH

Laurie.
 
It will "ask".

However the default configuration is often to "slew" the time to correct it, which will be too slow to the naked eye; it's often best to manually "step" the time to correct it initially using ntpdate -b <ntpserverIP>. It's also a good way to make sure your NTP server is contactable and sane.

Annihilannic
[small]tgmlify - code syntax highlighting for your tek-tips posts[/small]
 
Great.

Thanks for the input.
Was wondering if it would be better to use ntpdate in a cron job or not.
 
I prefer to run the daemon since gentle slewing of the clock is less noticeable to applications.

I should qualify what I said ealier about "asking"... that is usually the default configuration. It can be also set up to listen to broadcasts as Laurie described, but that is not a configuration I have encountered.

Annihilannic
[small]tgmlify - code syntax highlighting for your tek-tips posts[/small]
 
Yes there so many configuration you can have with ntp and we (in one environment) encountered some really strange behaviour where the two listed time servers presented caused slew back and forward on a regular basis not what you really want.

Obviously if the "client server" is a dB then the last thing you want is to be jumping back and forward with a cron task running ntpdate so as Annihilannic has indicated the preferable way is allowing the ntpd daemon to work its magic.

I spent weeks studying as much NTP documentation as I could before eventually getting a good ntpd (cluster) config that worked for us. Basic set-up is always simple but as we know nothing in our business is ever basic (well not for long).

Laurie.
 
I agree that letting the daemon do it's thing would be preferred.

What I really need to know is does it (the daemon) really sit and passively wait for a broadcast packet after initially "asking" on startup?

If so then it seems running ntpdate at intervals would be the solution? The servers I manage are spread out around world and are only ever off by 5-10 minutes, in most cases, when I think to look a couple times a year. So really this isn't that big a deal but I still want the "right" set up.

I've seen posts about folks setting their servers to be an ntp server instead of a client even though it doesn't serve anything but itself.
 
We (well I) tend have the localhost act as a timeserver at stratum 13 just in case nothing else is there to respond

So for cluster (and similar for stand-alone's) this is the key config of my ntp conf ..

Code:
slewalways yes
#
# The local (undisciplined Solaris) clock is identified as 127.127.1.0.
#
# Some type of primary clock is important;  but, it does not have
# to be the local kernel clock.
#
server 127.127.1.0
fudge 127.127.1.0 stratum 13
server dmz_timeserver01
server dmz_timeserver02

peer clusternode1-priv prefer
peer clusternode2-priv
peer fred_cpu_1_oam
peer fred_cpu_3_oam
peer fred_cpu_4_oam
 
# enable monitoring functions
enable monitor
#
# Drift file (optional)
#
driftfile /var/ntp/ntp.drift
# Stats (optional)
statsdir /var/ntp/ntpstats

I can do a test with snoop to confirm if the client is just waiting from broadcasts after the initial fetch but I'm on a day off so don't have direct access to my labs right now, but you may wish to do the same? Also if you do set up peers then you can watch your
Code:
ntpq> peer
to see who's aligned with who

To be continued ......

Laurie
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top