HP-UX Reference (11i v2 03/08) - 1M System Administration Commands N-Z (vol 4)
x
xntpd(1M) xntpd(1M)
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 (seexntpdc(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
commands in the configuration file. This forms a highly useful record to discover anomalies during regu-
lar 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 adjust-
ments 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
middle operating regime. You won’t get millisecond (or microsecond) precision with this method, but you
probably 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 example, you will see messages similar to this in the syslog:
: time reset (step) -411.093665 s
: synchronization lost
: synchronized to 15.13.115.194, stratum=1
: Previous time adjustment incomplete; residual -0.022223 sec
: Previous time adjustment incomplete; residual -0.020624 sec
: Previous time adjustment incomplete; residual -0.020222 sec
HP-UX 11i Version 2: August 2003 − 6 − Hewlett-Packard Company Section 1M−−923