| If we have a GPS/radio receiver, we can immediately assume that our time source is reliable and accurate. We will want to connect this device to a machine that is going to be accessible for as long as possible. The most common connection method is via an RS-232 cable. Once connected, we may have to configure a device file associated with that device, e.g., /dev/wwvb1 for the Spectracom Netclock/2. Associated with the device will be a unique Class-A IP address. It is this address that the NTP software uses to identify different types of devices, e.g., 127.127.26.1 for the HP 58503A GPS receiver. The second to last octet of the IP address that identifies the driver itself, in this case 26, is the NTP driver for an HP 58503A GPS receiver. The last octet identifies different instances of the same device; if you have a second HP 58503A, it would be identified as 127.127.26.2. The best sources for the most up-to-date driver numbers are either the manual page for xntpd or the Web site http://www.ntp.org. You should also check the file /etc/ntp.conf . If someone has accidentally deleted/modified it, there is a default copy in /usr/newconfig/etc/ntp.conf . It is the Class-A IP address of the device that is the IP address of our timeserver. I don't have a GPS/radio receiver, so I have to use a public-access timeserver as my source of time. It's a good idea to choose more than one for redundancy. I think a minimum of three is a good idea. My task will be to identify suitable timeservers. When I say suitable, I am thinking of the two aspects of their character: -
The fact that they themselves have good, reliable time sources, e.g., GPS, as well as a number of timeservers themselves (just in case their own time source fails). -
The quality of the network connection to them. We need to be able to rely on the network connectivity to the timeserver; otherwise , our clock will stray away from being synchronized. This will be highlighted in two figures from ntpq ; offset will remain high, above 50, and our xntpd daemon constantly has to work to bring that value to zero. The other figure is the disp value, which is a primary indicator of network quality. Let's look at some Stratum-1 servers. I have accessed the list of Stratum-1 servers at http://www.eecis.udel.edu/~mills/ntp/servers.html. Being based in the UK, I am looking for a timeserver that (a) is close, and (b) has no restrictions on using the server. Here are some timeservers I'm interested in: -
ntp0.cs.mu.OZ.AU (128.250.36.2) Location : The University of Melbourne, Melbourne, Australia Geographic coordinates : 37:48:09.60S 144:57:29.50E Synchronization : NTP V4 primary (Trimble Acutime GPS), i386/NetBSD 1.6 Service area : Australia, New Zealand, Pacific Region Access policy : open access, please limit to two peer hosts per site Note : service previously available at 128.250.37.1 moved to 128.250.37.2 Contact : David Hornsby (ntp@cs.mu.OZ.AU) -
ntp.metas.ch (193.5.216.14) Location : Federal Office of Metrology and Accreditation Switzerland (METAS), Bern, Switzerland Geographic coordinates : N 46:55:25 E 07:27:51 Synchronization : radiosynchronized receiver locked to HBG transmitter and ACTS dialup link to METAS T&lab UTC(CH) Service area : Switzerland, others by arrangement Access policy : open access, please send a message to notify Note : the IP address may change, please use DNS Contact : Laurent-Guy Bernier (laurent-guy.bernier@metas.ch) -
ntp-cup.external.hp.com (192.6.38.127) Location : Cupertino, California (San Francisco Bay area) 37:20N/122:00W Synchronization : NTPv3 primary, HP-UX/Palisade-GPS Service area : West Coast USA Access policy : open access Contact : timer@cup.hp.com Note : no need to notify for access, go right ahead. All of these servers have quite an open access policy and should be reasonably close, as far as network connectivity is concerned . Let's test the network connectivity because this is going to be a major concern for the NTP daemon ( xntpd ):
root@hpeos002[] # ping ntp0.cs.mu.OZ.AU 64 5 PING ntp0.cs.mu.OZ.AU: 64 byte packets 64 bytes from 128.250.37.2: icmp_seq=0. time=342. ms 64 bytes from 128.250.37.2: icmp_seq=4. time=336. ms ----ntp0.cs.mu.OZ.AU PING Statistics---- 5 packets transmitted, 2 packets received, 60% packet loss round-trip (ms) min/avg/max = 336/339/342 root@hpeos002[] #
As you can see, this machine is not very contactable. The roundtrip times are high, and I am experiencing packet loss. Initially, I would disregard this machine because I fear I will not be able to contact it often enough. I will keep it in for the time being.
root@hpeos002[] # ping ntp.metas.ch 64 5 PING metasweb01.admin.ch: 64 byte packets 64 bytes from 193.5.216.14: icmp_seq=0. time=54. ms 64 bytes from 193.5.216.14: icmp_seq=1. time=53. ms 64 bytes from 193.5.216.14: icmp_seq=2. time=53. ms 64 bytes from 193.5.216.14: icmp_seq=3. time=53. ms 64 bytes from 193.5.216.14: icmp_seq=4. time=53. ms ----metasweb01.admin.ch PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 53/53/54 root@hpeos002[] #
This looks much better. I have a short roundtrip time and no packet loss. I should be able to contact this machine regularly, keeping my clock in close synchronization.
root@hpeos002[] # ping ntp-cup.external.hp.com 64 5 PING ntp-cup.external.hp.com: 64 byte packets 64 bytes from 192.6.38.127: icmp_seq=0. time=183. ms 64 bytes from 192.6.38.127: icmp_seq=1. time=172. ms 64 bytes from 192.6.38.127: icmp_seq=2. time=172. ms 64 bytes from 192.6.38.127: icmp_seq=3. time=172. ms 64 bytes from 192.6.38.127: icmp_seq=4. time=180. ms ----ntp-cup.external.hp.com PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 172/175/183 root@hpeos002[] #
This machine is not too bad; I would prefer a roundtrip time closer to the roundtrip time to the timeserver in Switzerland. The benefit of the HP machine is that the access policy is completely open. If I don't send a message to the administrator in Switzerland, there is a chance that he will refuse access. It may be unlikely , but because Stratum-1 servers are heavily utilized, there may come a time when restrictions are put in place. It's always best to be polite and send a message, just in case. Thanks to the administrators of the above systems for letting me use their timeservers for this demonstration. I can affirm my choices by analyzing how these particular timeservers are configured. In this, I am looking for their own particular time sources; even though they are Stratum-1 servers, they should have some other sources of time, just in case their own time source stops working. To perform this analysis, I will use the command ntpq to query other timeservers:
root@hpeos002[] # ntpq -p ntp0.cs.mu.OZ.AU remote refid st t when poll reach delay offset disp ============================================================================= *REFCLK(29,0) .GPS. 0 l - 32 377 0.00 0.000 0.48 canon.inria.fr 71.80.83.0 16 u - 1024 0 0.00 0.000 0.00 +muckleshoot2.cs.GPS. 1 u - 64 377 0.34 0.000 0.95 +mumnunah.cs.mu..GPS. 1 u - 64 377 0.19 -0.016 0.93 -mulga.cs.mu.OZ.murgon.cs.mu.OZ 2 u - 64 377 1.08 0.009 0.95 root@hpeos002[] #
We may need to discuss the meaning of the output from this command before going any further. There may be some terms we haven't discussed yet, but will later: -
The remote (server name ) column shows hosts specified in the local host's configuration file plus other hosts that are configured to be peers with the local host. The host address can be preceded by a special character. These characters indicate the fate of the peer server in the clock selection process. The characters and their meanings are as follows : preceded with an '*' indicates the current synchronization source. A '-' indicates a host that was not considered for synchronization, while a '+' indicates a host that was considered for synchronization. -
- '*' selected for synchronization -
- '#' selected for synchronization, but distance exceeds maximum -
- 'o' selected for synchronization, PPS signal in use -
- '+' included in the final synchronization selection set -
- 'x' designated false ticker by the intersection algorithm -
- '.' picked out from the end of the candidate list -
- '-' discarded by the clustering algorithm -
- 'blank' discarded due to high stratum and/or failed sanity checks -
The refid (reference identification) column shows the current source of synchronization for the remote host. '.WWVB.' indicates that the host uses a radio clock that receives time signals from the U.S. government radio station WWVB. -
The st (stratum) column shows the stratum level of the remote host. -
The t (types) columns shows the available types, which include l=local (such as a GPS clock), u=unicast (this is the most common type), m=multicast, b=broadcast, -=netaddr (usually 0). -
The when column shows the number of seconds since the remote host response was received. -
The poll (poll period) column shows the polling interval to the remote host, as determined by xntp d. You can define the minimum polling interval with the minpoll option in the pee r, serve r, or broadcast definitions in the /etc/ntp.conf file. Some of the popular values for network connections include 512 and 1024 seconds (approximately 8 minutes and 17 minutes). Systems with external clocks, like GPS, should poll every 64 seconds or less. -
The reach (reachability) column shows how successful attempts to reach the server are. This is an 8-bit shift register with the most recent probe in the 2^0 position. The value 001 indicates that the most recent probe was answered, while 357 indicates that one probe was not answered. The value 377 indicates that all of the recent probes have been answered . -
The delay (roundtrip time) column shows how long (in milliseconds ) it took for the reply packet to come back in response to the query sent to the server. -
The offset (time difference) column shows how different (in milliseconds) the server's clock and the client's clock are from one another. Note that when this number exceeds 128, NTP makes an adjustment and the message "synchronization lost" appears in the log file. -
The disp (dispersion) column shows how much the "offset" measurement varies between samples. This is an error-bound estimate. The dispersion is a primary measure of network service quality. For our Australian server above, we can see that he is using a GPS clock as its own time source. We can see also see that it uses two other Stratum-1 ( st field) servers in case its own time source fails (the + means that it's a good candidate for synchronization). The Stratum-2 server is next in line for selection (see the “ next to the server name). The server canon.inria.fr will not be selected (a "blank" before its name). Although it's far away, this machine does have a good, reliable source of time with low disp , reach , and offset values. It may be that the disp between my site and Australia will rule him out, but I can't say that for certain. We will keep him in on the grounds since his time source is good.
root@hpeos002[] # ntpq -p ntp.metas.ch remote refid st t when poll reach delay offset disp ============================================================================= GENERIC(0) .HBG. 0 l - 64 0 0.00 0.000 0.00 PTB_ACTS(1) .UTCH. 0 l - 1024 44 0.00 1.360 5316.85 xntp2.ien.it .IEN. 1 u - 1024 377 554.60 -248.12 14.86 *ntp1.ptb.de .PTB. 1 u - 1024 377 21.10 1.106 14.86 +ntp-p1.obspm.fr.1PPS. 1 u - 1024 377 25.25 0.406 14.83 root@hpeos002[] #
Our Swiss timeserver actually uses a server in Germany (ntp1.ptb.de): The "*" means that this source has been selected for synchronization. This is probably due to the fact that the disparity for its local dialup connection PTB_ACTS is so high. Its other local source is a transmitter signal. The fact that reach , delay , offset , and disp are all zero is a little suspicious. I am tempted to venture that this machine may be having problems with its local clocks; I would even go so far to venture that it may not be operating as a Stratum-1 server due to the fact that its primary source is a Stratum-1 server itself. It's at this stage that we can start to build a better picture of which servers are best for our purposes. I will keep our Swiss timeserver in our configuration to demonstrate the need to take time in your selection process.
root@hpeos002[] # ntpq -p ntp-cup.external.hp.com remote refid st t when poll reach delay offset disp ============================================================================= *REFCLK(29,1) .GPS. 0 l - 32 376 0.00 0.003 0.02 +bigben.cac.wash.USNO. 1 u - 128 377 33.94 -1.826 0.37 +clepsydra.dec.c.GPS. 1 u - 64 371 68.27 -29.293 126.24 192.5.5.250 gps.laguna.vix. 2 - 369d 1024 0 14.28 4.984 16000.0 +tick.ucla.edu .PSC. 1 u - 128 377 65.63 -24.682 0.47 +usno.pa-x.dec.c.USNO. 1 u - 128 357 66.96 -28.561 0.44 root@hpeos002[] #
Our public-access timeserver at Hewlett Packard has a number of good quality timeservers, as well as a GPS receiver of its own. There is another command we can use: ntptrace . For some bizarre reason, there is no man page for it. I think of it as an NTP alternative to traceroute . In this case, it's going to tell me information about some distant server instead of some distant route. Here's an example:
root@hpeos002[] # ntptrace ntp0.cs.mu.OZ.AU murgon.cs.mu.OZ.AU: stratum 1, offset -0.000684, synch distance 0.00066, refid 'GPS' root@hpeos002[] # ntptrace ntp.metas.ch metasweb01.admin.ch: stratum 2, offset -0.013743, synch distance 0.05754 ntp1.ptb.de: stratum 1, offset 0.003814, synch distance 0.00008, refid 'PTB' root@hpeos002[] # ntptrace ntp-cup.external.hp.com ntp-cup.external.hp.com: stratum 1, offset 0.003293, synch distance 0.00018, refid 'GPS' root@hpeos002[] #
We can use this information, i.e., stratum and synch distance , to help us choose appropriate timeservers. Now we can look at setting up our own NTP server. |
