1825766 Members
2083 Online
109687 Solutions
New Discussion

Some issues on NTP

 
SOLVED
Go to solution
Robert-Jan Goossens
Honored Contributor

Re: Some issues on NTP

Hi,

Check this attached doc.

Regards,
Robert-Jan
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi,

I just implemented NTP today. But, the time synchorization took affect immediately. By right, the NTP client will try to adjust the time slowly and catch up the server time. But, why it takes affect immediately? (Before the implementation, the time for the NTP client is 8 minutes faster than NTP server)

Is there any parameter or command that I can apply in order to let the NTP client to adjust the time slowly instead of immediately step to follow the NTP server's time?

The attachment shows the NTP client's time has immediately been step to -8 minutes (-481.456008)

regards
Bill Hassell
Honored Contributor

Re: Some issues on NTP

The start/stop script is designed only to be used at bootup and shutdown. If you read the script, you'll see that the first startup task is to run ntpdate which will perform a STEP change. You should not run the /sbin/init.d/xntpd script on a production machine except during startup and shutdown (which is automatically done for you). Instead, check that xntpd is not running (ps -e | grep ntp) then simply run /usr/sbin/xntpd. Then check /var/adm/syslog/syslog.d for the current status. xntpd will slowly adjust the clock.


Bill Hassell, sysadmin
Stuart Urquhart
Frequent Advisor

Re: Some issues on NTP

I think if the time difference is large, but not large enough for xntpd to fail, it will make a step change. Add "-x" to the xntpd command line to force slews only
Bill Hassell
Honored Contributor

Re: Some issues on NTP

As mentioned, the STEP change can\me from running the start/stop script and the ntpdate command that is (by design) imbedded in the script. xntpd by default will only slew the clock when the time difference is low (within 128ms accuracy). It will make a STEP change when the difference is between 128ms and 17minutes (1000 seconds). Beyond 17minutes, xntpd assumes something is very wrong and shuts down for operator intervention. Running xntpd -x is not recommended by HP since the stability and accuracy of NTP is compromised. xntpd will also log a number of additional messages in syslog.

Using slew mode (-x) is really a coverup for network problems. Within a reasonably stable network, NTP will be quite stable and will never STEP change the time for years. All of this is covered in the man page for xntpd.


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Bill,

According to man xntpd, the steps that I have to follow is (instead of just start the xntpd)

i) ntpdate (force to date to be stepped)
ii) /sbin/init.d/xntpd start

Questions:
1) Is the above steps correct?

2) Can you provide me the example on how to use ntpdate? I already man ntpdate and still not clear about it.

3) I have gone through some article, it is advisable to run ntpdate periodically from cron every houw or two to synchronize the local clock to another system's clock. But, through man xntpd, the ntpdate is just required to be executed once only. So, which one should I follow? Any impact of running ntpdate?

regards.

Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Stuart,

In order to use "xntpd -x", I have to follow the steps as below:

1) /sbin/init.d/xntpd stop
2) /sbin/init.d/xntpd -x
3) /sbin/init.d/xntpd start

Am I right? I think the step 3 is not necessary, right??? Just 1 and 2 only?

regards.
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Bill,

After I started the xntpd, I leave it running both on NTP server and client. But, do I need to execute ntpdate command at minimum once per 12 hours to ensure time synchronisation? May I have your advise about it?

regards
Stuart Urquhart
Frequent Advisor

Re: Some issues on NTP

To enable the '-x' option, change XNTPD_ARGS="" in /etc/rc.config.d/netdaemons to XNTPD_ARGS="-x", then
/sbin/init.d/xntpd stop
/sbin/init.d/xntpd start

You shouldn't need to run ntpdate other than at boot. In fact, I think it uses the same TCP port as xntpd, so you probably can't ntpdate once xntpd is running.
Bill Hassell
Honored Contributor

Re: Some issues on NTP

ntpdate should never be run on a production system except during bootup. The same should is true for changing the time or date using the date command. If the time is off by more than a couple of minutes, your steps should be:

- stop ALL applications
- run ntpdate specifying the NTP server as in:
ntpdate ntp_server_name
- restart xntpd using:
/sbin/init.d/xntpd stop
/sbin/init.d/xntpd start

or simply reboot which accomplishes all the above steps. The steps above (run ntpdate followed by /sbin/init.d/xntpd start) are redundant--the start script accomplishes all of this.

ntpdate: just specify the NTP server name and ignore all the options in order to step change the time.

The article you read about using ntpdate every day is flat out wrong for systems that have xntpd and based on a (very old) way of keeping time. NEVER run ntpdate on a production machine. It should only be run on bootup (as it is in HP-UX).

In order to use the -x option, do NOT run the start/stop scripts. You must put the -x option in the start/stop config file: /etc/rc.config.d/netdaemons and edit these 3 lines:

export NTPDATE_SERVER="my.ntpserver.com"
export XNTPD=1
export XNTPD_ARGS=

The first 2 are ready to go (edit the SERVER name as required). The 3rd line is where the -x would go as in:

export XNTPD_ARGS="-x"

This is standard for all start/stop scripts. However, read the man page for xntpd concerning the -x option...HP does not recommend using it in a normal network environment. While you can manually stop and start xntpd, HP-UX has automated this in the start/stop scripts. Use them instead. And ALWAYS look in /var/adm/syslog/syslog.log file for ntp messages. This is the only way ntp can log what is happening. Also use ntpq -p occasionally to see that the time server(s) are functioning correctly.

And no, it is NOT advisable to every run ntpdate on a daily basis. xntpd was developed specifically to eliminate running date or ntpdate. Check out the source documents for ntp at www.ntp.org, specifically: http://www.ntp.org/ntpfaq/NTP-s-config.htm and http://www.ntp.org/ntpfaq/NTP-a-faq.htm where David Mills (caretaker for NTP information and standards) keeps all the details about NTP.


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi,

Thanks for the feedback from Bill and Stuart.

Is there any way to view the start/stop script because these 2 files are executable files?

I think I will go for "-x' testing due to our informix data issue. (We prefer SLEWING even it has some problems)

I will monitor the server & network performance. Will update all of you asap.

Anyway, really thanks for your assist.

regards.
Patrick Wallek
Honored Contributor

Re: Some issues on NTP

The /sbin/init.d/xntpd script is just that. A SCRIPT. You can look at it with cat, more, vi or whatever.
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi,

In order to use the -x option, is the below steps correct? After finish modified the NTP server site then followed by NTP client.

For NTP server
1) /sbin/init.d/xntpd/stop
2) at /etc/rc.config.d/netdaemons and edit the line:
export XNTPD_ARGS=-x
3) /sbin/init.d/xntpd/start

For NTP Client
1) /sbin/init.d/xntpd/stop
2) at /etc/rc.config.d/netdaemons and edit the line:
export XNTPD_ARGS=-x
3) /sbin/init.d/xntpd/start

Because after I follow the above steps, the time still immediately adjusted instead of slowly adjust (slewing).

According to Bill, he advised me not to run start/stop script if I am using -x option. What does it mean?

regards.
Bill Hassell
Honored Contributor

Re: Some issues on NTP

The NTP start/stop scripts are meant to run ONLY at bootup and shutdown, regardless of whether you are using the -x option or not. The reason is that ntpdate is hardcoded into the script and it will jumpstep the time. So while you specified the option correctly in /etc/rc.config.d/netdaemons, by running the xntpd script, ntpdate jumped the time. You should have stopped and started xntpd manually like this:

UNIX95=1 ps -fC xntpd
kill
xntpd -x

That kills the process and then you start it with the desired option. When you reboot, all of this will be automatic with the start/stop script. Note in your comment above, the correct syntax for (any) start/stop script is: start, not /start.


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi,

From your mail, I know anything that put under /sbin/init.d will be auto executed during server boot up (same as win98 autoexec.bat, right)

Now in my mind, I have 2 ways of doing the NTP by slewing adjust the time.

1)
a) Kill the xntpd process instead of executing /sbin/init.d/xntpd stop or start.
UNIX95=1 ps -fC xntpd
kill
xntpd -x

b) Make sure there is an entry for export XNTPD_ARGS=-x at /etc/rc.config.d/netdaemons

c) After doing a) & b) at NTP server, then follow by each of the NTP client.

d) Reboot the server.

2) I managed to go through the xntpd script and found that the argument -b is for STEP method (immediately change) and -B is for SLEWING method (slowly change). I get to know about it through man xntpd.

if [ -n "${NTPDATE_SERVER}" ]; then
/usr/sbin/ntpdate -b ${NTPDATE_SERVER}
fi

So, my second way is as below:
a) /sbin/init.d/xntpd stop

b) Replace the ntpdate -b with ntpdate -B.

c) Take out the -x for XNTPD_ARGS which is
at /etc/rc.config.d/netdaemons

d) /sbin/init.d/xntpd start

e) After doing a), b), c) & d) at NTP server, then follow by each of the NTP client.

Is my 2 ways stated above correct? If yes, I plan to use the second way. Because no need to restart the server. If the above steps is incorrect, can you pls show me the correct steps (prefer the way of activating NTP without restarting the server)?

regards.
Bill Hassell
Honored Contributor

Re: Some issues on NTP

The start/stop scripts are stored in /sbin/init.d but are not automatically executed by simply being stored there. These scripts must run in a specific order during bootup and shutdown so an automatic method has been developed, the sequencing links. List the contents of these sequencing directories:

ll /sbin/rc1.d /sbin/rc2.d and /sbin/rc3.d

Then read the documents on start/stop scripts found at docs.hp.com

Number 1 is fine to use xntpd -x for your servers and clients. However, there is NO need to reboot any of your clients or servers.

Number 2 has some problems. Do NOT change ntpdate in the startup script. You *WANT* ntpdate to jump the time (if necessary) on bootup. xntpd is started long before any other applications are running so they will NEVER see any time step. ntpdate is only run once in the start/stop script. Just use your #1 procedure and skip the reboot.


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Bill,

For the way number 1, it works!!!

Now I want to add in another NTP client, do I just need to follow the same steps as mentioned before?

Since I need to execute xntpd -x, can I just leave the export XNTPD_ARGS to blank?

When I try to issue command ntpq -p, the figure will always change. Can you pls explain what does these figure about? For NTP server, the figure quite static but for NTP client, the figure change quite frequently. Why?

remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 3 l 20 64 377 0.00 0.000 10.01

regards.
Bill Hassell
Honored Contributor

Re: Some issues on NTP

To add another HP-UX client, just edit /etc/rc.config.d/netdaemons and change the 3 lines:

export NTPDATE_SERVER="your.server.com"
export XNTPD=1
export XNTPD_ARGS="-x"

Then replace the (lengthy) /etc/ntp.conf file with:

server 12.34.56.78

That's all you need. Replace 12.34.56.78 with the IP address of your NTP server. If you kill and start xntpd with -x, that will take care of your running system. The netdaemons file is used for bootup and shutdown. You always need to edit the netdaemons file but it has no effect on the running system.

As far as ntpq -p, the important values are reach (which should be 377) and poll (on a well managed network, 512 to 1024). The delay, offset and dispersion at statistics which will always vary somewhat, but are really not needed for normal operation. In your example, the ntpq values indicate no NTP server, that this computer is using itself as the reference clock.


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Bill,

Thanks for you reply.

For the ntpq -p that I attacted for the last mail is for the NTP server. The below ntpq -p is for the NTP client.

remote refid st t when poll reach delay offset disp
==============================================================================
*Mercury LOCAL(1) 4 u 35 64 377 69.50 6.181 32.39

Questions:
1) Poll 64 means every 64 seconds, NTP server or client will send out 64 bytes to check whether the time is sychronized or not. NTP server will send first or NTP client?

2) Can I manually set the poll value to 1024? (which is equal to ~17 minutes)

3) I remember you told me if everything is stable, then the 64 bytes will be send every 17 minutes (maximum interval). Is it possible that this 64 bytes sending will only be sent at the particular time that I want (any method to manually set the time)?

4) If cannot set the time of sending 64 bytes, can I know how the 64bytes sent? Through any agent? xntpd?

5) What is the 64 bytes contains? a message, file or just a signal?

6) Below is the syslog.log for the NTP client. Why the synchronisation always lost? Network not stable? Or automatically lost after slewing the time? Or any resons? I think the connection is always established, right.

May 28 10:48:21 miranda xntpd[2242]: time reset (slew) 1.629569 s
May 28 10:48:21 miranda xntpd[2242]: synchronisation lost
May 28 10:51:09 miranda xntpd[2242]: synchronized to 10.11.160.2, stratum=4
May 28 11:20:58 miranda xntpd[2242]: time reset (slew) -0.652503 s
May 28 11:20:58 miranda xntpd[2242]: synchronisation lost
May 28 11:23:41 miranda xntpd[2242]: synchronized to 10.11.160.2, stratum=4
May 28 11:58:26 miranda xntpd[2242]: synchronisation lost
May 28 11:58:26 miranda xntpd[2242]: synchronized to 10.11.160.2, stratum=4
May 28 12:13:23 miranda xntpd[2242]: time reset (slew) -1.056826 s
May 28 12:13:23 miranda xntpd[2242]: synchronisation lost
May 28 12:16:02 miranda xntpd[2242]: synchronized to 10.11.160.2, stratum=4
May 28 15:03:30 miranda xntpd[2242]: time reset (slew) 0.136559 s
May 28 15:03:30 miranda xntpd[2242]: synchronisation lost
May 28 15:06:14 miranda xntpd[2242]: synchronized to 10.11.160.2, stratum=4

regards
Bill Hassell
Honored Contributor

Re: Some issues on NTP

1) The client always sends out the message, The server replies with the time information.

2) No, you cannot change the poll rate, nor do you want to. The protocol is quite involved and if you tried to change the poll rates, the accuracy would be seriously affected. The program will calculate the poll rate based on a complex set of rules.

3) Yes, the poll rate will eventually reach the maximum on a stable network. You cannot control when this occurs.

4) All the details about the data messages are found at www.ntp.org, specifically: http://www.eecis.udel.edu/~mills/ntp.html

5) Refer to the NTP website.

6) It looks like you have networking prolems but to troubleshoot this would require a lot more time than it is worth.

You are making this project a lot more complicated than necessary. Use ntpq -p once a week to check on the clients. Most sysadmins start NTP and forget it. It is a very involved protocol that just works.


Bill Hassell, sysadmin
Bill Hassell
Honored Contributor

Re: Some issues on NTP

6) Additional info: there is no connection established. The server accepts all incoming requests whenever they occur. For a detailed description of the protocol, see http://www.eecis.udel.edu/~mills/database/brief/arch/arch.pdf


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Bill,

I also know my project is getting complicated from day to day. But what to do. All the questions is from my boss. She asked and I have to answer...

I went through the web site that you provided and I found out something.

http://www.eecis.udel.edu/~mills/ntp/html/confopt.html

From this link, I able to get the info as below:

syntax
======
server address [key key | autokey] [burst] [iburst] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll]

peer address [key key | autokey] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll]

parameters
==========
minpoll
maxpoll
These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two. The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to an upper limit of 17 (36.4 h). The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 4 (16 s).

Questions
1) Can I use the above method as the xntp is running now?

2) Is the poll interval is same as stratum=10 that I set at /etc/ntp.conf file which is fudge 127.127.1.1 stratum=10. If yes, can I just change to 17? 17 means the ntp client will only send the 64 bytes to the server once every ~36 hours (equal to 1 and 1/2 days), right?

3) Can you provide me some example syntax to use server address and peer address as stated above?

4) Can I have any NORMAL syslog.log which contains ntp? Is there any sentence called synchronisation lost also? Or actually this sentence means normal because after adjust the time, the connection will lost automatically. As what you told me is there is no connection established between NTP server and client, right?

regards.
Bill Hassell
Honored Contributor

Re: Some issues on NTP

I am very concerned about the emphasis on the polling interval. It seems that you are trying to lengthen the poll time for some reason. If you looked at the NTP protocol description, you'll note the extreme emphasis on accuracy. If accuracy cannot be maintained, then the poll period will be reduced. WIthout this adjustment, the accuracy cannot be maintained in a problem network. I would strongly suggest that you get a network consultant to look at your network problems since the NTP errors are symptoms of an unstable network.

To answer your questions:

1) Yes, you can change them while xntpd is running. Just kill xntpd and restart it (don't use the start/stop script in /sbin/init.d)

2) I would not recommend changing the poll interval at all.

3) The server/peer entries are used in larghe enterprise NTP solutions where there is an atomic clock or similarly accurate time source and the peers will work out millisecond differences. The details are quite complex.

4) I would look at the web page: http://www.eecis.udel.edu/~mills/ntp/html/notes.html and run ntpq -p regularly (every 10 minutes) into a log. I suspect that your network needs work but that you don't have the tools to do this. If possible, setup a separate network for NTP and add an extra LAN card to each server.


Bill Hassell, sysadmin
Ngoh Chean Siung
Super Advisor

Re: Some issues on NTP

Hi Bill,

After discussion with my boss, we would like to try to use ntpdate through cronjob. It means that the time synchronisation will occur once per day only. That's means I need to configure the settings for the ntpdate.

1)Can I hv the steps to configure ntpdate through cronjob from the start until the end?

2)How to check the variance/drift for the local time of a server?

Thanks & regards.
Bill Hassell
Honored Contributor

Re: Some issues on NTP

OK, As mentioned early in this thread, using ntpdate is NOT recommended as it will always jump the time and will not result in accurate timesync. As far as settings, there aren't any. You just run ntpdate and give it the name of your time server.

As far as accuracy for your NTP server, I am assuming this server is running xntpd and has 3 to 5 NTP sources in the ntp.conf file. In that case, use ntpq -p to report on current accuracy. The man page for ntpq gives a lot of details on the metrics. If you are going to use ntpdate on the server too, accuracy is not measureable nor is it relevant. The server will be accurate once a day and will drift for the next 24 hours. In NTP terms, the server (and clients) are just approximately accurate.


Bill Hassell, sysadmin