Some issues on NTP

[Ngoh Chean Siung]

Hi Bill,

Thanks for your feedback.

As I know, ntpdate will be using STEP method to adjust the time. Even though it is not accurate all the time but my boss wants the time to be adjusted once a day only. So, I asked you a question which is about the drift of the time. What I mean is example for our watch, it will drift a bit slower after a few months or years. Then we need to adjust back to the correct time. The question that I want to asked for the last mail is how I know the drift of the time for a server. Maybe 5 seconds slower after 6 months. How I can check this information?

In order to execute the ntpdate in cronjob, I still have some questions.

1) Do I need to set the cronjob in NTP server, client or both?

2) As I know, in order to execute ntpdate in cronjob, I have to stop/kill the xntpd process first. In cronjob, is it possible to set the killing process of xntpd before running ntpdate and after the ntpdate was executed, the xntpd will be started?

3) After running ntpdate through cronjob,
a) If I leave xntpd running after ntpdate was executed, will the time being adjusted whenever it has time different or only adjust according to the cronjob?

b) If I don't leave xntpd running after ntpdate was executed, the time will only be adjusted according to the cronjob, right?

regards.

[Bill Hassell]

1) Since your manager wants a single update every day, then I would run the server's ntpdate first, then the clients a few minutes later. So put ntpdate in both server and client cronjobs with the execution time different.

2) Since your manager does not want to update time during the day, you stop xntpd permanently. Make sure you can set the clock using ntpdate before you put it into a cronjob. Turn off xntpd in this order:

- /sbin/init.d/xntpd stop
- Edit /etc/rc.config.d/netdaemons and set export XNTPD=0

xntpd polls the server every 64 to 1024 seconds and that is not desired in your case.

3) If you leave xntpd running, then you'll not be following the wishes of your manager. xntpd adjusts the time by slewing the clock after every poll if necessary.

If you set the clock every day, the servers will drift slightly (a few seconds). Server clocks are not nearly as accurate as your wristwatch but the amount of drift in 24hours is minimal. All of the details found at ntp.org that I mentioned are designed for the best accuracy possible and this requires xntpd.

[Ngoh Chean Siung]

Hi Bill,

1) Can I just schedule the cronjob in NTP client only? Because NTP server will follow its own local clock. So, no need to set the ntpdate in cronjob. Am I right?

2) Below is the ntpdate command that I'm going to use in cronjob,
/usr/sbin/ntpdate -d IP_Address 2>&1

a) As I know, the parameter "-d" is to enable debugging mode. All the debugging result is available in syslog.log, right?

b) Through man ntpdate, I able to find out the info as below:

Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the settimeofday(2) system routine. If the error is less than 0.5 seconds, it will slew the time by calling the adjtime(2) system routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron(1M) every hour or two.

So, it means that if I use the parameter "-d", the time adjustment will base on the below theory, right? If I use "-b", means time adjustment is based on STEP method, right? Can I put 2 parameters (such as -dp)? what is the syntax?

3) For the stratum, it is automatically assigned by the system, right. It is depends on the sync distance, right. The figure of stratum is getting bigger (max is 15) if the location between 2 servers is far. Am I right?

regards.

[Bill Hassell]

1) If the top level NTP server is running on its own clock then there is no need to do anything with the server (no cronjob needed). All the clients will be in sync with the server.

2) ntpdate -d will change nothing! It is used to display the details of the ntpdate packets and the last line will show what change will be made--but no change will take place. The details from ntpdate are of little value without a detailed knowledge of how ntpdate works.

2a) No, ntpdate -d writes nothing into syslog.

2b) The man page statement seems to be unclear since -b and -B options specify two different behaviors. Without -b or -B, it appears that ntpdate will try to slew the clock unless xntpd is running. As the man page mentions, using a cron job for ntpdate is not an accurate method to maintain time. When xntpd is started using the start/stop script, ntpdate -b is used to step the clock.

3) The concept of a stratum is discussed at http://www.ntp.org/ntpfaq/NTP-s-algo.htm and has to do with the number of servers between the reference clock (stratum 0) and a given client. In your case, your NTP server has a self-contained stratum 0 clock (itself) and appears as a stratum 1 server to your clients. If another machine points to one of your clients for NTP sync, that client will be a stratum 2 server. This has nothing to do with distance, it is a logical relationship among servers.

[Bill Hassell]

In summary, you can use the recommended xntpd method or put ntpdate -b in a cron job like this:

10 1 * * * /usr/sbin/ntpdate -b myNTPserver > /dev/null

This will result in no messages from ntpdate unless there is a problem. The error message: "the NTP socket is in use, exiting" usually means that xntpd is running.

[Ngoh Chean Siung]

Hi Bill,

After went through the website that you provided, found out the below article.

1) Can't I become happy with ntpdate alone?

ntpdate sets the system clock once and mostly in a brute way. As real clocks drift, you need periodic corrections. Basically ntpdate can be executed in a cron job hourly or daily, but the machine won't be an NTP server then.
In contrast, running xntpd will learn and remember the clock drift and it will correct it autonomously, even if there is no reachable server. Therefore large clock steps can be avoided while the machine is synchronized to some reference clock. In addition xntpd will maintain error estimates and statistics, and finally it can offer NTP service for other machines. Last, but no least, ntpdate cannot query a local reference clock.

Question
1) ntpdate cannot query a local reference clock means I cannot use command ntpq -p, right?

2) Currently I am still running the xntpd, the stratum for NTP server is 3 and NTP client is 4. Why the stratum for NTP server is 3 and not 0 as you mentioned to me?

3) After I stop the xntpd and start to run ntpdate through cronjob, so I no need to take care about the stratum because it will not have the stratum anymore. Am I right?

regards.

[Bill Hassell]

1) Correct. ntpq -p on your server or clients won't work (error=ntpq: read: Can't assign requested address) since there is no daemon managing the time.

2) Stratum 0 is always reserved for a reference clock such as a GPS receiver, WWV (or DCF77, MSF) receiver or atomic clock. Stratum 3 is a default value for servers that have no reference, that is, they use the internal clock. See the comments in /etc/ntp.conf at the heading: Undisciplined Local Clock.

3) On the server, continue running xntpd or it will not act as a time server. On the clients, turn off the xntpd by killing it or using the start/stop script, then configure /etc/rc.config.d/netdaemons to have export XNTPD=0. Then run ntpdate to make sure it syncs, and add it to cron.

[Ngoh Chean Siung]

Hi Bill,

Thanks for your assist along my NTP study.

Now my boss already approved me to proceed the NTP implementation.

All the best!

regards.

[Huiqi Liu]

Thanks guys for a very informative discussion on NTP.

I have a question though:

Since we upgraded our NTP server to HP-UX 11.0 and xntpd to 3.5f, timep on our ProCurve switches can't synchronize their clocks any more. Previously the server was on HP-UX 10.20 and it was working OK. If I change the switches to use sntp then it works. However I have dozens of switches and would prefer to get timep working again, rather than changing the setting on all the switches.

Can anyone help? (Basically how to configure xntpd 3 server to support timep clients).

Many thanks.

[Bill Hassell]

The ProCurve switches are using a pre-historic protocol (timep) which probably uses port 37 (in HP-UX, the 'time' daemon) or port 13 (in HP-UX, the 'daytime' daemon). These daemons are probably turned off on your new system (most security experts recommend disabling these dinosaurs). Nobody is maintaining those ancient services anymore. Probably nobody has even looked at the code since the early 90's. Are there hidden exploits hanging around in there? Not a good idea to guess.

You can switch the ProCurves to sntp which is supported and secure, or turn on daytime (and/or time) and see if things start working.

[Huiqi Liu]

Thank you very much, Bill!