HP OpenVMS Systems Documentation
Compaq TCP/IP Services for OpenVMS
A local host may run more than one time service. For example, a host may have both NTP and DTSS (Digital Time Synchronization Service) installed. However, only one of these time services is allowed to set the system clock.
If you are running a time service in addition to NTP, you must stop either the other time source or NTP from setting the system clock. You can stop NTP from setting the system clock by adding the following statements to the configuration file:
server 127.127.1.0 prefer fudge 127.127.1.0 stratum 0
In these statements, the hardware address of the local clock (LOCAL) is
127.127.1.0. These statements force NTP to use its own system clock as
a reference clock. The host continues to respond to NTP time queries
but does not make any adjustments to the system clock, thereby allowing
the other time service to make those changes.
12.4 Configuring NTP as Backup Time Server
You can configure the NTP service as a backup time server. In this case, if all other network synchronization sources become unavailable, the NTP service becomes active. You can also use this method to allow the local node to act as the NTP server in an an isolated network. To configure the NTP service as the backup server or the sole NTP server, enter the following commands in the NTP configuration file:
server 127.127.1.0 fudge 127.127.1.0 stratum 8
In this example, the stratum is set to a high number (8) so that it
will not interfere with any other, possibly better, time
synchronization source. You should set the stratum to a number that is
higher than the stratum of all other time synchronization sources.
12.5 Operating with Time Zone Offsets
The operating system's installation procedure provides a command procedure that defines a time zone differential (offset) logical name in the system logical name table (LNM$SYSTEM_TABLE). The procedure is SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM. The logical name is SYS$TIMEZONE_DIFFERENTIAL.
To change the time zone differential offset, follow these steps:
NTP works with UTC only. However, the OpenVMS time reflects the local time. Therefore, you must follow the preceding steps to account for a change in daylight saving time (DST).
NTP maintains a record of system clock updates in the file SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP_RUN.LOG. NTP reopens this log file daily, each time creating a new version of the file (older versions are not automatically purged). Events logged to this file may include the following messages:
To set the amount of logging information to be recorded, set the following logical name to a value from 1 through 6, where 6 specifies the most detailed logging:
Table 12-1 describes the messages most frequently included in the NTP log file.
|Synchronized to IP-address||
Announces that a peer candidate has passed validity and accuracy tests
(as performed by the clock selection algorithms) and has been selected
as the new synchronization source. For example:
synchronized to 22.214.171.124, stratum=2
|Time reset time||
Indicates that NTP has set the local clock by slewing the local time to
match the synchronization source. This happens because the local host
is no longer synchronized. For example:
time reset (slew) -0.218843 sec
|Synchronization lost||This usually occurs after a time reset. All peer filter registers are cleared, for example, for that particular peer; all state variables are reset along with the polling interval; and the clock selection procedure is once again performed.|
|Previous time adjustment incomplete||Indicates that the last clock adjustment did not finish in one attempt. The residual is added to the next adjustment.|
|Couldn't resolve hostname, giving up on it||
Indicates that the host name could not be resolved. This peer will not
be considered for the candidate list of peers. For example:
couldn't resolve 'fred', giving up on it
|Send to IP-address: reason||
Indicates that a problem occurred while sending a packet to its
destination. The most common
reason logged is "connection refused." For example:
sendto(126.96.36.199): connection refused
|Connection reestablished to IP-address||
Indicates that errors occurred when sending packets, but now packets
are being sent successfully. For example:
connection reestablished to 188.8.131.52
|Time error delta-time is way too large (set clock manually)||NTP has detected a time difference greater than 1000 seconds between the local clock and the server clock. You must set the clock manually or use the NTPDATE program and then restart NTP. Once NTP sets the clock, it will continuously track the discrepancy between the local time and NTP time and adjust the clock accordingly.|
|offset : n sec freq: x poll: y sec||
An hourly message, where:
|No clock adjustments will be made, DTSS is active||
Indicates that the DTSS time service is running on the system. The DTSS
time service should be disabled if you would like NTP to set the system
time. To disable the DTSS time service, enter the following command:
$ RUN SYS$SYSTEM:NCL DISABLE DTSS
Alternatively, you can configure the NTP server not to make clock adjustments, as described in Section 12.3.3. NTP dynamically detects whether the DTSS time service is enabled at any time and will log this message if appropriate.
|Clock adjustments will resume. DTSS no longer active||Indicates that the DTSS time service has been disabled on the system. NTP will now handle clock adjustments. NTP dynamically detects whether the DTSS time service is enabled at any time and will log this message if appropriate.|
12.6.1 Sample NTP Log File
The following sample shows an NTP log file:
16 Apr 16:36:30 ntpd version = 3-5.91 16 Apr 16:36:31 tickadj = 97, tick = 976, tvu_maxslew = 99231, est. hz = 1024 16 Apr 16:36:31 precision = 976 usec 16 Apr 16:36:33 read drift of 0 from TCPIP$NTP.DRIFT 16 Apr 16:43:00 synchronized to 184.108.40.206, stratum=2 16 Apr 16:43:00 time reset (slew) -62.810275 sec 16 Apr 16:43:00 synchronization lost 16 Apr 16:44:58 Previous time adjustment incomplete; residual -0.005758 sec 16 Apr 16:48:21 synchronized to 220.127.116.11, stratum=2 16 Apr 16:52:28 Previous time adjustment incomplete; residual -0.005270 sec 16 Apr 16:53:26 Previous time adjustment incomplete; residual -0.085888 sec 16 Apr 17:11:40 synchronized to 18.104.22.168, stratum=3 16 Apr 17:13:49 synchronized to 22.214.171.124, stratum=2 16 Apr 17:14:53 time reset (slew) -0.577109 sec 16 Apr 17:14:53 synchronization lost 16 Apr 17:21:38 synchronized to 126.96.36.199, stratum=3 16 Apr 17:26:54 synchronized to 188.8.131.52, stratum=2 16 Apr 17:35:24 offset: 0.033115 sec freq: -7.813 ppm poll: 1024 sec 16 Apr 17:46:23 synchronized to 184.108.40.206, stratum=3 16 Apr 17:47:28 Previous time adjustment incomplete; residual -0.000020 sec 16 Apr 17:49:32 Previous time adjustment incomplete; residual 0.093696 sec 16 Apr 17:49:36 Previous time adjustment incomplete; residual 0.003318 sec 16 Apr 17:52:08 Previous time adjustment incomplete; residual -0.049460 sec 16 Apr 17:52:24 Previous time adjustment incomplete; residual 0.003416 sec 16 Apr 17:53:28 Previous time adjustment incomplete; residual 0.000088 sec 16 Apr 18:06:10 time reset (slew) -0.218843 sec 16 Apr 18:06:11 synchronization lost 16 Apr 18:17:39 synchronized to 220.127.116.11, stratum=3 16 Apr 18:17:43 synchronized to 18.104.22.168, stratum=2 16 Apr 18:21:47 synchronized to 22.214.171.124, stratum=3 16 Apr 18:23:41 synchronized to 126.96.36.199, stratum=2 16 Apr 18:35:40 offset: -0.052522 sec freq: -7.839 ppm poll: 1024 sec
Authentication support is implemented using the MD5 algorithm to compute a message digest. The servers involved in an association must agree on the key and key identifier used to authenticate their messages.
Keys and related information are specified in a key file. Keys are used for:
|keys keys-file||Specifies the file name for the keys file, which contains the encryption keys and key identifiers used by NTP, NTPQ, and NTPDC when operating in authenticated mode.|
|trustedkey key-ID [...]||Specifies the encryption key identifiers that are trusted for the purposes of authenticating peers suitable for synchronization, as well as keys used by the NTPQ and NTPDC programs. The authentication procedures require that the local and remote servers share the same key-ID and key value for this purpose, although different key values can be used with different servers. The key-ID arguments are 32-bit unsigned decimal integers from 1 to 15. Note that the NTP key 0 is used to indicate an invalid key value or key identifier; therefore, it should not be used for any other purpose.|
Specifies the key identifier to use with the NTPDC program, which uses
a proprietary protocol specific to this implementation of NTP. This
program is useful to diagnose and repair problems that affect the
operation of NTP. For information about NTPDC, see Section 12.8.3.
The key-ID argument to this command is an unsigned 32-bit decimal number that identifies the trusted key in the keys file. If no requestkey command is included in the configuration file, or if the keys do not match, any request to change a server variable is denied.
Specifies the key identifier to use with the NTPQ program, which uses
the standard protocol defined in RFC-1305. This program is useful to
diagnose and repair problems that affect the operation of NTP. For more
information about NTPQ, see Section 12.8.4.
The key-ID argument to this command is a 32-bit decimal integer that identifies a trusted key in the keys file. If no controlkey command is included in the configuration file, or if the keys do not match, any request to change a server variable is denied.
The NTP service reads keys from a keys file that is specified using the keys command in the configuration file. You can supply one or more keys from 1 to 15 in the keys file.
Key entries use the following format:
key-ID key-type key-value
The fields are:
pound sign (#)
Because this file contains authorization data, Compaq recommends that you limit read access to this file. In particular, you should disable world read access.
The following is a sample keys file:
# # 4 M DonTTelL 6 M hElloWrl 12 M ImASecrt
NTP provides several utility programs that help you manage and make changes to the NTP server. These utilities include:
The NTPDATE program sets the local date and time by polling a specified server or servers to determine the correct time. A number of samples are obtained from each of the servers specified, and a subset of the NTP clock filter and selection algorithms are applied to select the best samples. The accuracy and reliability of NTPDATE depends on the number of servers it polls, the number of polls it makes each time it runs, and the interval length between runs.
Run NTPDATE manually to set the host clock or from the host startup file to set the clock at boot time. It is useful in some cases to set the clock manually before you start NTP. NTPDATE makes time adjustments (called "stepping the time") by calling the OpenVMS routine SYS$SETIME.
NTPDATE will not set the date if an NTP server is running on the same host.
Table 12-3 describes the NTPDATE command options. To use these options, define the NTPDATE command, as follows:
Enter commands using the following format:
NTPDATE [option...] host [host...]
For example, the following command sets the clock based on the time provided from one of the specified hosts (BIRDY, OWL, or FRED):
$ NTPDATE BIRDY OWL FRED
NTP sets the date and time by polling the servers you specify as arguments to the command. Samples are obtained from each of the specified servers. NTP then analyzes the results to select the best server to use as a time source.
|-d||Changes the time and prints information useful for debugging.|
|-o version||Specifies the NTP version (1 or 2) for outgoing packets (for compatibility with older versions of NTP). Version 3 is the default.|
|-p n||Specifies the number of samples NTPDATE acquires from each server. The default is four. You can specify from one to eight.|
|-q||Specifies a query only; does not set the clock.|
Use the NTPTRACE utility to determine the source from which an NTP server obtains its time. NTPTRACE follows the chain of time servers back to the master time source.
To run NTPTRACE, define a foreign command as follows:
Use the following syntax when entering commands:
The following example shows output from an NTPTRACE. In this example, the chain of servers from the local host to the stratum 1 server FRED, which is synchronizing to a GPS reference clock.
$ NTPTRACE LOCALHOST: stratum 3, offset -0.000000, synch distance1.50948 parrot.birds.com: stratum 2, offset -0.126774, synch distance 0.00909 fred.birds.com: stratum 1, offset -0.129567, synch distance 0.00168, refid 'GPS'
All times are in seconds. The output fields on each line are as follows:
Table 12-4 describes the NTPTRACE command options.
|-d||Enables debugging output.|
|-n||Displays IP addresses instead of host names. This may be necessary if a name server is down.|
|-r retries||Sets the number of retransmission attempts for each host. The default is 5.|
|-t timeout||Sets the retransmission timeout (in seconds). The default is 2.|
|-v||Displays additional information about the NTP servers.|