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

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

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


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 to see who's aligned with who

To be continued  ......

Laurie