time synchronization with ntp during boot without xntpd running permanently?

[V. Nyga]

Hi gurus,

I want to synchronize clients two times per week - once with ntpdate in cron in the middle of the week, once during boot up.
I can perform synchronization during boot with /etc/rc.config.d/netdaemons, but then xntpd is running too.
How can I configure boot session that xntpd is stopped again after synchro?
Or only running ntpdate during boot up?
Any tipps?

Thanks
Volkmar

[James R. Ferguson · Accepted solution]

Hi Volkmar:

You should configure and run 'xntpd' _ALL_ the time. At bootup, set your clock correctly by running 'ntpdate'. This is achieved by specifying:

NTPDATE_SERVER=yourtimeserver

...in '/etc/rc.config.d/netdaemons'.

In this fashion you will have accurate timekeeping ALL the time.

Regards!

...JRF...

[A. Clay Stephenson]

It is not necessary that xntpd be running on a client in order to use ntpdate. You simply list the server(s) in the ntpdate command; it is necessary that you have at least one NTP server somewhere in order to use ntpdate. My question is why would you want to do something like this? The overhead of continuously running NTP is quite low and your approach guarantees that your clients are going to agree on the time only rarely.

[mobidyc]

Hello,

for your information, don't run ntpdate if you have a lot of time desynchronisation, ntpdate will set the date/time immediately, this can have bad effects in your logs or applications, xntp will adjust the time by drifting the clock, transparently for your log and applications.

a solution (deprecated) for what you want:

i think it's not supported by HP but you can edit /sbin/init.d/xtnpd and comment:
/usr/sbin/xntpd $XNTPD_ARGS && echo "xntpd \c"

the effect is that ntpdate will synchronize your server at boot but the xntpd daemon will not start.

you can play with your crontab for xntp when you want.

Regards,
Cedrick Gaillard

[V. Nyga]

Thanks a lot!

What's about network traffic because of ntp?
I don't wanna create much traffic for this or a bigger server load.
There are 30 clients who need the correct time.
My clients have nothing important running at their own, but with a license program a too big difference of time makes problems (especially after boot up and a bad battery).
So two synchros per week should be enough.

V.

[John Payne_2]

Volkmar,

Reread what Clay said about the overhead of ntp. It's just a plain and simple little protocol. There is no reason not to run it on your system. Very low overhead, very low network footprint.

John

[James R. Ferguson]

Hi (again) Volkmar:

There is absolutely no need to worry about network traffic. Normally polling of the timeserver occurs only every 512 or 1024 seconds. If you use an external clock (GPS) then that reduces to 64 seconds or less. The 'minpoll' variable determines the frequency.

NTP traffic will impose a drop-in-a-rainstorm worth of load.

Regards!

...JRF...

[V. Nyga]

@JRF:
Can I define the polling period?

@ACS:
'..not necessary that xntpd be running on a client in order to use ntpdate'
Yes, but if I configure ntp at boot I have to configure netdaemons, (and this is for running xntpd and ntpdate before), haven't I?

@Cedrick:
At boot up there will be no problem with applications. Also not at night in the middle of the week, as no user applikation will run.

V.

[A. Clay Stephenson]

At boot, you make your own rc script that invokes ntpdate but this is dumb. Now that you have stated your (unfounded) concerns the real answer to your question is to run NTP. You can't configure the polling interval nor do you want to. NTP automatically and dynamically adjusts its polling periods. If NTP finds a stable, well-behaved timesources it rapidly (over a period of tens of minutes) settles down to infrequent (typically 1024 seconds) polling periods. You also want multiple time sources so that NTP can ignore bad sources --- or more accurately formerly good sources that became bad. The overhead of NTP is all but zero and you will have a very difficult time trying to measure it. The only exception to this is if you have a rogue client attempting a denial of service attack on your NTP servers but then you have a security problem rather than a performance problem.

[V. Nyga]

Thanks to all, I think I'll try the 'dumper' solutions, but go ahead with xntpd for most of my clients.

Nice easter!

[rick jones]

A bit of clarification - when a client first tries to synchronize with a time server (or time servers - one really should configure three or four sources of time whenever possible) it will query the timeserver(s) every 64 seconds. Once it has acheived synchronization, then it will start to back-off the interval out to the 1024 second level.

[Bill Hassell]

Just to emphasize: NTP is so slow with very small messages, that you can take the slowest HP-UX box you can find (25-50 Mhz), put it on a 10 Mbit LAN and it will sync THOUSANDS of servers without breathing hard. If you login to your system, run ps -ef and then exit, you will have created more network traffic than xntpd would use during the entire day. Don't use the 'jump' time method with ntpdate - it will cause problems with databases.

[V. Nyga]

Thanks for add-ons