HP-UX Reference (11i v2 07/12) - 1M System Administration Commands N-Z (vol 4)

x
xntpd(1M) xntpd(1M)
The next step is to be sure the RS232 messages, if used, are getting to and from the clock. The most reli-
able way to do this is with an RS232 tester and to look for data flashes as the driver polls the clock and/or
as data arrive from the clock. Our experience is that many of the problems occurring during installation
are due to problems such as miswired connectors or improperly configured device links at this stage.
If RS232 messages are getting to and from the clock, variables can be inspected using the
ntpq command
(see ntpq(1M)). First, use the
pe and
as commands to display billboards showing the peer configuration
and association IDs for all peers, including the radio clock peers. The assigned clock address should appear
in the
pe billboard and the association ID for it at the same relative line position in the
as billboard. If
things are operating correctly, after a minute or two samples should show up in the
pe display line for the
clock.
Additional information is available with the
rv and
clockvar commands, which take as argument the
association ID shown in the
as billboard. The
rv command with no argument shows the system vari-
ables, while the
rv command with association ID argument shows the peer variables for the clock, as well
as any other peers of interest. The clockvar
command with argument shows the peer variables specific
to reference clock peers, including the clock status, device name, last received timecode (if relevant), and
various event counters. In addition, a subset of the fudge parameters is included.
The
xntpdc utility program can be used for detailed inspection of the clock driver status. The most use-
ful are the clockstat file and the commands in xntpdc (see xntpdc(1M)).
Most drivers write a message to the clockstats file as each timecode or surrogate is received from the radio
clock. By convention, this is the last ASCII timecode (or ASCII gloss of a binary-coded one) received from
the radio clock. This file is managed by the filegen facility described above and requires specific com-
mands in the configuration file. This forms a highly useful record to discover anomalies during regular
operation of the clock.
Slew
Slew is not recommended by HP because it reduces accuracy and stability.
The NTP daemon has three regimes in which it operates:
offset below 128 milliseconds
This is the normal operating regime of NTP. A properly configured NTP hierarchy (with reasonable
networking) can operate for years without ever approaching the 128 millisecond upper limit. All time
adjustments are small and smooth (known as slewing), and nobody even notices the slew adjustments
unless they have a cesium clock or a
GPS clock and expensive instrumentation to make sophisticated
measurements (HP/Agilent makes the instruments).
offset above 128 milliseconds
This regime is often encountered at power-on because, those battery-backed real-time clocks they put
in computers are not too great. Because NTP is quite capable of keeping the offset below one mil-
lisecond all the time it is running, many users want to get into the normal regime quickly when an
offset above 128 millisecond is encountered at startup. So in this situation NTP will (fairly quickly)
make a single step change, and is usually successful in getting the offset well below 128 millisecond so
there will be no more of the disruptive step changes.
offset above 1000 seconds
This is so far out of the normal operating range that NTP decides something is terribly wrong and
human intervention is required. The daemon shuts down.
The catch is that the dispersion on a WAN is frequently much greater than 128 milliseconds, so you may
see (a lot of) the step changes, perhaps as large as 1000 milliseconds (depends on your network). But there
are customer applications that are quite allergic to the step changes, particularly backward steps (which
will happen about half the time). Databases and financial transaction systems are examples.
The good news is that NTP can be forced to never make a step, but instead slew the clock to drive the offset
to zero. This is accomplished with the -x option on the command line. This effectively removes the mid-
dle operating regime. You won’t get millisecond (or microsecond) precision with this method, but you prob-
ably can’t get that over a WAN anyway.
It is important to note that slewing is a cover-up for a more fundamental problem (poor connection to the
timesource), and it does not solve this problem. Slewing is not recommended by HP because it causes
reduced accuracy and stability, and it leads to anomalous behavior that can be quite confusing. For exam-
ple, you will see messages similar to this in the syslog:
: time reset (step) -411.093665 s
: synchronization lost
HP-UX 11i Version 2: December 2007 Update − 6 − Hewlett-Packard Company 685