NTP server

[Yarok]

Hello,

How do I activate NTP server on HP UX 9000 B.11.11?

My aim is to make a time synchronization system with GPS device.

BR,

Yaron

[Ismail Azad]

Hi,

Well first of all you need to enable the xntpd daemon so that it runs on boot by going to the file /etc/rc.config.d/netdaemons and turning the control variable to 1. The main file that is used for NTP is /etc/ntp.conf and it is pretty extensively documented.



Regards
Ismail Azad

[Matti_Kurkela · Accepted solution]

> How do I activate NTP server on HP UX 9000 B.11.11?

Edit /etc/ntp.conf to suit your requirements, change the value "XNTPD=0" to "XNTPD=1" in file /etc/rc.config.d/netdaemons, and run "sh /sbin/init.d/xntpd start" to start the NTP server daemon.

> My aim is to make a time synchronization system with GPS device.

This requires quite a bit of extra set-up.

See the official NTP documentation on reference clock drivers included in the NTP daemon:

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

If you have a basic GPS device instead of one specially designed as a time reference, this is probably the driver you want:

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

First, you must configure a serial port for incoming data from the GPS.

To determine the available serial port devices, run:
ioscan -C tty -fn

The serial port device is not created automatically. You must create it.
The command to create the device should look like this:

/usr/sbin/mksf -d asio0 -H (hardware path for the appropriate tty device) -p (instance number) -a0 -i -v

The correct values for the -H and -p options depend on what hardware you have (server model, whether you're using one of the server's built-in serial ports or an add-on PCI serial MUX card).

The command should produce a device named like /dev/ttyXpY, where X and Y are numbers.

To verify the serial communication, you might want to configure "cu" for the GPS serial port. To do that add a line like this to file /etc/uucp/Devices:

Direct ttyXpY - 4800 direct

Replace "ttyXpY" with the appropriate device name, and 4800 with the communication speed your GPS uses (4800 bps is a common speed for GPS devices).

After this, you can connect and power up the GPS and run "cu -lttyXpY" (using the appropriate device name of course!). If the GPS can receive the satellites, it should start sending NMEA sentences (lines starting with characters "$GP") after a while.

A dedicated time reference GPS receiver might use a different protocol: see the documentation of your GPS in that case.

Once you've verified the server can see the data sent by the GPS, it's time to make it talk with the NTP server daemon. To do that, you must make a symbolic link so that the correct serial port device is reachable using the device name listed in the NTP documentation.

For a GPS device using the NMEA protocol, the device name is /dev/gpsN (N=number). In this example, I assume you're connecting only one GPS device to your system, so N = 0.

ln -s /dev/ttyXpY /dev/gps0

The next step is to add the appropriate configuration entry in /etc/ntp.conf. The NTP daemon is tricky here: it does not explicitly reference the device name anywhere. Instead, you must use a "pseudo-IP-address" listed in the NTP documentation: the daemon will translate the pseudo-IP into the device name corresponding the symbolic link created above.

For a GPS device using the NMEA protocol, the pseudo-IP is 127.127.20.N... and as we chose N=0 when creating the symbolic link, the same number must be used here too.
So an example server entry would be:

server 127.127.20.0

If your GPS uses communication speed other than 4800 bps, you must add a "mode" parameter to this line: see the NTP reference clock documentation page for instructions.

This enables basic GPS communication, which should be good enough to achieve roughly millisecond-level time precision. If you need more precise than that, you will have to use a GPS device that can provide a PPS signal (Pulse-Per-Second), and use a second serial port for that.

MK

[Matti_Kurkela]

If your GPS device is designed to work as a time synchronization device, then it might have a network connector and be able to use the NTP protocol on its own.

In that case, the set-up is much simpler: you configure the IP address, netmask and gateway to the GPS device, just like with any networked device. There may be an access list that determines which servers may connect to the GPS device: configure it to allow access for your HP-UX server.
All this should be described in the documentation of your GPS device.

When your networked GPS device can be pinged from your HP-UX host, you'll typically only need to add one "server" line to /etc/ntp.conf, just as if you were synchronizing to another HP-UX NTP server. You can even do it with a GUI, using SAM.

MK

[Yarok]

Dear Matti Kurkela,
Many thanks for the answers. I am always happy to receive such a professional care.
I do use a GPS device that has a network connection.
I red both answer carefully and follow the instructions and it work just fine.
I tried it also via SAM (very simple) and view that the /etc/rc.config.d/netdaemons file is updated accordingly.
Finally, I tracked /var/adm/syslog/syslog file and saw the synchronization process. For some reason that I couldnâ t understand, I noticed the following messages (from the syslog):
1. â Synchronization lostâ (and the xntp process was down), that was a day after it works fine. I red that if the sync is greater than 1000 sec it would not happened, but that was not the case.
Can you figure out the reason the sync lost?
2. â tftpd 28093]: connect: No route to hostâ follow that by 10 min â Timeout (no requested in 10 min)â . What do the above messages mean?
3. How can I determine the sync process frequency? I mean â when the sync occurs and reoccurs again?
BR,

Yaron

[Matti_Kurkela]

> 1. "Synchronization lost" (and the xntp process was down), that was a day after it works fine. I red that if the sync is greater than 1000 sec it would not happened, but that was not the case.

Was there any other log messages from xntpd just before the "Synchronization lost" message?

If xntpd finds it needs to do a "large" adjustment to the system clock, it will temporarily drop out of sync. After a few more polling cycles, it should re-synchronize again if the adjustment had the desired effect on the system clock. This is normal behaviour.

Xntpd dying is *not* normal behaviour.

Without more information is hard to guess why it might have died, unless your system clock is wildly inaccurate or reacts badly to adjustment. In that case, it might be a symptom of a hardware or firmware issue.

----------
> 2. "tftpd 28093]: connect: No route to host" follow that by 10 min "Timeout (no requested in 10 min)". What do the above messages mean?

Not related to NTP at all. These messages are apparently produced by the tftpd daemon, which usually is needed only on network boot servers (e.g. Ignite-UX servers and Ignite netboot helpers).

The first message suggests a packet arrived to the tftpd port of your server, causing inetd to start tftpd. But your network configuration apparently did not include a valid route for sending a response back (no route to host). 10 minutes later, the tftpd server shuts down because it has heard nothing more from the possible TFTP client.

...Is your server accessible from the Internet? If it is not protected by a firewall, both the tftpd messages and the death of the xntpd process might be side effects of someone port-scanning your server or running attack programs against it.

-----------------
> 3. How can I determine the sync process frequency?

Run "ntpq -p" and look at the "when" and "poll" values.

The "when" value counts seconds since the last time check. The next time check happens when the "when" value becomes equal to the "poll" value.

When the NTP daemon starts, it usually checks the time every 64 seconds or so (poll = 64). This is adjustable using the "minpoll" setting in the /etc/ntp.conf file.
If the system clock has any gross errors (several hundreds of milliseconds!) the daemon will keep the poll interval at 64 seconds until it has managed to sync the system clock to a reasonable degree.

After the system has stayed in sync (within +/- 128 ms of the timesource's time) for several hours, the NTP daemon has enough information to predict the average error rate of the system clock, and it can start increasing the time between time checks. If the checks indicate the daemon's predicted corrections are OK, the time interval can be increased further; if the prediction is not correct and the daemon sees the clock starting to drift out of the true time, it will shorten the interval again. It will try to find the "optimal" interval automatically.

The maximum interval between time checks is 1024 seconds by default, but it can be adjusted using the "maxpoll" configuration setting in /etc/ntp.conf.

The default maximum and minimum time check intervals correspond to settings "minpoll 6" and "maxpoll 10", i.e. 2^6 and 2^10 seconds respectively.

The last three columns of the "ntpq -p" output may be useful in figuring out how well your time synchronization works. All the values are in milliseconds.

The "delay" column indicates the average network travel-time between your server and the NTP timesource.

The "offset" column indicates how much the UTC time of your system clock differs from the UTC time of the NTP timesource.

The last field (titled either "dispersion" or "jitter" depending on ntpd version) indicates how much the network travel-time between your server and the timesource changes between one check and another. Obviously, if this value is higher than about 200 ms, it will be almost impossible for the xntpd daemon to sync with that remote timesource, because the errors in travel time estimation will be too great. High values may be caused by various reasons, like a congested network.

MK

[Yarok]

1. >Was there any other log messages from xntpd just before the "Synchronization lost" message?
Not that I have seen. Where should I look for?
The GPS device is very accurate and reliable.
I will keep monitoring the issue and let you know if I found something.
2. > ...Is your server accessible from the Internet?
No its not. But you right it has nothing to do with the NTP.
The users here are performing ftp to other machines on daily basis, and I guess sometimes the â logoutâ process is not completed (double clicking on the ftp windowâ ¦)
3. Perfect explanation!!!

BR,

Yaron