×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Quick NTP question

Quick NTP question

Quick NTP question

(OP)
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,

RE: Quick NTP question

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.

RE: Quick NTP question

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
tgmlify - code syntax highlighting for your tek-tips posts

RE: Quick NTP question

(OP)
Great.

Thanks for the input.
Was wondering if it would be better to use ntpdate in a cron job or not.

RE: Quick NTP question

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
tgmlify - code syntax highlighting for your tek-tips posts

RE: Quick NTP question

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.          

RE: Quick NTP question

(OP)
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.  

RE: Quick NTP question

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 --> example

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 --> command

ntpq> peer
to see who's aligned with who

To be continued  ......

Laurie   

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close