|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Troubleshooting NTP on Solaris
You need to use a combination of tools, such as viewing system error logs and using
the snoop utility, to troubleshoot NTP.
Determining NTP Peers
The ntpq utility is the standard NTP query program. It is an
interactive program but it can also run command in batch mode using option -c. All
interactive commands are available with help command:
Commands available:
addvars associations authenticate cl
clearvars
clocklist clockvar cooked
cv debug
delay exit
help host
hostnames
keyid keytype
lassociations lopeers lpassociations
lpeers mreadlist mreadvar
mrl mrv
ntpversion opeers passociations
passwd peers
poll pstatus
quit raw
readlist
readvar rl
rmvars rv
showvars
timeout version
writelist writevar
Use the utility to
identify NTP peers on the network. For example:
myhost# ntpq -c peers
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(0) LOCAL(0) 3 l 36 64 377 0.00 0.000 10.06
224.0.1.1 0.0.0.0 16 --64 0 0.00 0.000 16000.0
ntpq>
ntpq> exit
myhost#
Solaris ntpd write messages to syslog /var/adm/messages
on start and stop:
Jan 7 13:04:24 myhost xntpd[177]:
[ID 866926 daemon.notice] xntpd exiting on signal 15
Jan 7 13:09:43 myhost ntpdate[24288]: [ID 774510 daemon.notice] step time
server 10.20
1.145.9 offset 318.644492 sec
Jan 7 13:09:43 myhost xntpd[24290]: [ID 702911 daemon.notice] xntpd
3-5.93e+sun 03/08/
29 1623:05 (1.4)
Jan 7 13:09:43 myhost xntpd[24290]: [ID 301315 daemon.notice] tickadj = 5,
tick = 1000
0, tvu_maxslew = 495, est. hz = 100
Jan 7 13:09:44 myhost xntpd[24290]: [ID 266339 daemon.notice] using kernel
phase-lock
loop 0041, drift correction 0.00000
If you set time forward ( a minute or two) on the system on which you are trying to debug, then log messages
will be generates as the system sends out its periodic NTP requests with the incorrect time. The
NTP servers should respond with the correct time and clocks should gradually
adjust.
Note: According to Sun, NTP can only sync time if it
is off by no more than 17 minutes. Furthermore, adjusting time being off by
seconds will take several minutes because NTP is architected to slowly adjust to
the NTP master's time.
Use the snoop utility when you attempt to track NTP activities on the
network.
To view NTP server multicast advertisements, use the snoop utility.
# /usr/sbin/snoop -d bge1 udp port
123
The following is an example of an NTP client multicast:
myclient -> 224.0.1.1 NTP client (Thu Dec 27 02:25:10 2001)
Samples of a snoop trace of the process follow:
1. The NTP client sends a message to an NTP server with its idea of the
local time.
myclient -> NTP client (Thurs December 27 02:16:03 2001)
2. The NTP server responds with the correct time.
-> myclient NTP server (Thurs December 27 02:14:51 2001)
3. This exchange between the NTP server and the NTP client repeats
many times. Eventually, the NTP client acknowledges that its time is
incorrect. The client will then take action to change its own time,
based on NTP time advertisements received from one or more NTP
servers. Information about the actions taken by the NTP client are
sent to the syslog utility for proper processing.
myclient -> NTP client (Thurs December 27 02:15:27 2001)
4. The NTP server responds again with the correct time.
-> myclient NTP server (Thurs December 27 02:15:27 2001)
The following is an example of an NTP server response:
-> 224.0.1.1 NTP broadcast (Thu Dec 27 02:25:33 2001)
The following is an example of an NTP client time request:
myclient -> NTP client (Thu Dec 27 02:26:19 2001)
The following is an example of an NTP server response:
-> myclient NTP server (Thu Dec 27 02:26:19 2001)
Note – Another easy way to monitor NTP traffic by using snoopis to use
the command: snoop -V port 123.
ISC provide pretty good description of basic
issues in Chapter 9
9. Troubleshooting NTP
Look at the contents of your syslog output file.
There is a good chance that ntpd has output some
information describing any problems it has encountered.
Many people have difficulties with using RESTRICT.
They want to set themselves up to be as secure as possible,
so they create an extremely limited default RESTRICT
line in their /etc/ntp.conf file, and then they
find that they can't talk to anyone.
If you're having problems with your server, in order to do
proper debugging, you should turn off all RESTRICT
lines in your /etc/ntp.conf file, and otherwise
simplify the configuration as much as possible, so that you
can make sure that the basic functions are working correctly.
Once you get the basics working, try turning back on various
features, one-by-one. When turning on the RESTRICT
features, make sure that you have read, understood, and followed
the instructions found in
AccessRestrictions.
The behavior of NOTRUST changed between versions
4.1 and 4.2.
Please note that most servers are not set up to do cryptographic
authentication. Therefore, if you use RESTRICT NOTRUST
in your configuration file, you will most likely be configuring
your machine to query one or more upstream servers but then
throw away any answer that they may send you. This may result
in your client sending out one or more packets per second to
each of your configured upstream servers, and that would be
considered to be "seriously unfriendly".
Many server operators would be likely to firewall themselves
off from you (and perhaps the rest of your network), to try
to protect themselves against this kind of abuse.
See the page at
Flawed Routers Flood University of Wisconsin Internet Time Server
to get an idea of how bad this can be, when a vendor mis-configures
commodity-grade hardware and causes all their devices in the
field to start bombarding time servers with a packet every second.
See
http://people.freebsd.org/~phk/dlink/ for a more recent
example.
Do NOT use RESTRICT NOTRUST unless
you know what it means and you know how to use it properly!!!
The first thing to do is to make sure that UDP port 123 is
open on all firewalls between you and the remote time servers
that you wish to synchronize to. See
9.8. On-line Troubleshooting Utilities for browser-based
tests.
When trying to debug problems using ntpdate
and ntpq, note that these utilities may use unprivileged
high-numbered ports, while ntpd requires full bidirectional
access to the privileged UDP port 123. So, ntpdate -u
may work, but ntpd may not. Or ntpq
may work, but ntpd may not. OpenNTPD also uses
high-numbered source ports so if it is able to synchronize but
ntpd is not, it is very probable that the incoming
UDP port 123 is blocked.
If you're going to run ntpd, you need to fix
your network/firewall/NAT so that ntpd can have
full unrestricted access to UDP port 123 in both directions.
However, this may not be allowed by your firewall administrators.
If this is not possible, you may need to run ntpd
on the firewall itself, so that it can have full unrestricted
access to UDP port 123 in both directions, and then have it
serve time to your internal clients. However, this may also
be disallowed.
If that's not possible, your only other option may be to
buy the necessary hardware to connect to one or more of your
own computers and run your own Stratum 1 time server (typically
$200-300 for the radio or GPS receiver hardware, plus the computer
to connect it to), or buy a pre-packaged Stratum 1 time server
(frequently $1000-2000 or more). With your own Stratum 1 time
server, you can sync your internal clients to it, it will get
its signal via a radio signal from WWV/WWVB/DCF77/CHU/etc...
(depending on where you live) or maybe a GPS or CDMA radio signal,
and no packets will be required to cross your firewall on UDP
port 123.
Only your management and your firewall administrators will
be able to tell you which options are feasible.
Run ntpq -p HOSTNAME, or one of the web-based
utilities at
9.8. On-line Troubleshooting Utilities, to see the status
of ntpd on HOSTNAME (without HOSTNAME the local host is queried). Check the official
documentation for a detailed description of
the
ntpq utility (http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html).
It will report something like this:
remote refid st t when poll reach delay offset jitter
==============================================================================
ff05::101 .MCST. 16 u - 64 0 0.000 0.000 4000.00
*example.site.co .PPS. 1 u 320 1024 377 1.955 -1.234 1.368
- The very first column
-
contains the "tally code" character. See the
ntpq page for more information.
- remote
-
the hostname or IP of the remote machine.
- refid
-
the identification of the time source to which the remote
machines is synced. May be (for example) a radio clock or
another ntp server)
- st
-
the stratum of the remote machine. 16 is "unsynchronized".
0 is the best value, that could be (for example) a radio
clock or the ntp servers private caesium clock (see
http://www.eecis.udel.edu/~mills/ntp/html/index.html#intro
for more information about ntp in general).
- when
-
how many seconds since the last poll of the remote machine.
- poll
-
the polling interval in seconds.
- reach
-
an 8-bit left-rotating register. Any 1 bit means that
a "time packet" was received.
- delay
-
the time delay (in milliseconds) to communicate with
the remote.
- offset
-
the offset (in milliseconds) between our time and that
of the remote.
- jitter
-
the observed jitter (in milliseconds) of time with the
remote.
The following on-line troubleshooring utilities are available
for testing an ntpd from an "outside" IP address:
-
Test the time server at the IP address you are browsing
from (time, peers, variables)
-
Test the time server at any IP address (time, peers, variables,
associations, versions AND trace)
If your /etc/ntp.conf is being automatically
overwritten, this may be due to DHCP. Either run your dhcpd
(dhcp server) with the dhcpd.conf option "option ntp-servers
<your ntp server>;", or run your dhcpcd (dhcp client) with the
-N arg to prevent ntp.conf from being
rewritten at all.
To synchronize ntp with a Windows server 2003 running w32time,
you have to install a hotfix on that server first, otherwise
ntp cannot reach (and therefore not sync with) that server.
This hotfix is available from Microsoft on request only,
see
http://support.microsoft.com/?kbid=830092
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 05, 2008
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
Andreas Höschler
ahoesch at smartsoft.de
Mon Nov 14 06:48:17 EST 2005
Hi all,
thanks to
"Jonathan Birchall" <Jonathan.Birchall at ins-sure.com>
Hutin Bertrand <Bertrand.Hutin at fr.Fujitsu.com>
> The config file is in the same place as the later Solaris,s - ie
> /etc/inet/ntp.conf.
>
> Check what dependencies xntp relies on - svcs -l
> svc:/network/ntp:default
> If all dependencies exist then
> svcadm enable svc:/network/ntp
> svcadm refresh svc:/network/ntp
> svcadm restart svc:/network/ntp
>
> This should start xntpd.
This is what I was looking for. I now get
svcs | grep ntp
online 12:31:24 svc:/network/ntp:default
Thanks a lot!
Regards,
Andreas
ntpdate– set the date and time by way of NTP/usr/sbin/ntpdate
[-bBdoqsuv] [-a key#] [-e authdelay]
[-k keyfile] [-m] [-o version]
[-p samples] [-t timeout]
[-w] server…
DESCRIPTION
The ntpdate utility sets the local date and time. To determine
the correct time, it polls the Network Time Protocol (NTP) servers on the
hosts given as arguments. This utility must be run as root on the local
host. It obtains a number of samples from each of the servers and applies
the standard NTP clock filter and selection algorithms to select the best of
these.
The reliability and precision of ntpdate improve dramatically
with a greater number of servers. While a single server may be used, better
performance and greater resistance to inaccuracy on the part of any one
server can be obtained by providing at least three or four servers, if not
more.
The ntpdate utility makes time adjustments in one of two ways.
If it determines that your clock is off by more than 0.5 seconds it simply
steps the time by calling
gettimeofday(3C). If the error is less than 0.5 seconds, by default, it
slews the clock's time with the offset, by way of a call to
adjtime(2). The latter technique is less disruptive and more accurate
when the offset is small; it works quite well when ntpdate is run
by cron every hour or two. The adjustment made in the latter case
is actually 50% larger than the measured offset. This adjustment tends to
keep a badly drifting clock more accurate, at some expense to stability.
This tradeoff is usually advantageous. At boot time, however, it is usually
better to step the time. This can be forced in all cases by specifying the
-b option on the command line.
The ntpdate utility declines to set the date if an NTP server
daemon like
xntpd(1M) is running on the same host. It can be run on a regular basis
from
cron(1M) as an alternative to running a daemon. Doing so once every one
to two hours results in precise enough timekeeping to avoid stepping the
clock.
OPTIONS
FILES
- /etc/inet/ntp.keys
- Contains the encryption keys used by ntpdate.
ntpq queries NTP servers which implement the recommended NTP mode
6 control message format, about current state. It can also request changes in
that state. The program can be run in interactive mode; or it can be controlled
using command line arguments. Requests to read and write arbitrary variables can
be assembled, with raw and pretty-printed output options
available. By sending multiple queries to the server, ntpq can also
obtain and print a list of peers in a common format.
If one or more request options are included on the command line, ntpq
sends each of the requests to NTP servers running on each of the hosts given as
command line arguments. By default, ntpq sends its requests to
localhost, if hosts are not included on the command line. If no request
options are given, ntpq attempts to read commands from the standard
input and execute them on the NTP server running on the first host given on the
command line. Again, ntpq defaults to localhost if no other
host is specified.
ntpq uses NTP mode 6 packets to communicate with an NTP server.
Thus, it can be used to query any compatible server on the network that permits
queries. Since NTP is a UDP protocol, this communication will be somewhat
unreliable, especially over large distances. ntpq makes one attempt
to retransmit requests; requests timeout if the remote host is not heard from
within a suitable period.
OPTIONS
Command line options are described below. Specifying a command line
option other than -i or -n causes the
specified query (queries) to be sent, immediately to the indicated host(s).
Otherwise, ntpq attempts to read interactive format commands from
standard input.
- -c
- Interpret the next argument as an interactive format command and add
it to the list of commands to be executed on the specified host(s).
Multiple -c options may be given.
- -i
- Operate in interactive mode; write prompts to standard output and
read commands from standard input.
- -n
- Output all host addresses in dotted-quad numeric format rather than
converting them to canonical host names.
- -p
- Print a list of the peers known to the server as well as a summary
of their state. This is equivalent to the peers interactive
command. See USAGE below.
USAGE
Interactive format commands consist of a keyword followed by up to four
arguments. Only enough characters of the full keyword to uniquely identify
the command need be typed. Normally, the output of a command is sent to
standard output; but this output may be written to a file by appending a
`>', followed by a file name, to the command line.
Interactive Commands
A number of interactive format commands are executed entirely within
the ntpq program itself. They do not result in NTP mode 6
requests being sent to a server. If no request options are included on
the command line, and if the standard input is a terminal device,
ntpq prompts for these commands. The interactive commands are
described below:
- ? [command_keyword ]
- A `?' by itself prints a list of all the command keywords known
to the current version of ntpq. A `?' followed by a
command keyword prints function and usage information about the
command.
- timeoutmilliseconds
- Specifies a time out period for responses to server queries. The
default is about 5000 milliseconds. Since ntpq retries
each query once after a time out, the total waiting time for a time
out is twice the time out value that is set.
- delaymilliseconds
- Specifies a time interval to be added to timestamps included in
requests which require authentication. This command is used to
enable (unreliable) server reconfiguration over long delay network
paths or between machines whose clocks are unsynchronized.
Currently, the server does not require time stamps in authenticated
requests. Thus, this command may be obsolete.
- hosthostname
- Set the name of the host to which future queries are to be sent.
Hostname may be either a host name or a numeric address.
- keyid #
- Specify of a key number to be used to authenticate configuration
requests. This number must correspond to a key number the server has
been configured to use for this purpose.
- passwd
- Allow the user to specify a password at the command line. This
will be used to authenticate configuration requests. If an
authenticating key has been specified (see keyid above),
this password must correspond to this key. ntpq does not
echo the password as it is typed.
- hostnames yes | no
- If “yes” is specified, host names are printed in information
displays. If “no” is given, numeric addresses are printed instead.
The default is “yes” unless modified using the command line
-n switch.
- raw
- Print all output from query commands exactly as it is received
from the remote server. The only formatting/filtering done on the
data is to transform non- ASCII data into printable form.
- cooked
- Causes output from query commands to be “cooked”. The values of
variables recognized by the server are reformatted, so that they can
be more easily read. Variables which ntpq thinks should
have a decodable value, but do not, are marked with a trailing `?'.
- ntpversion[ 1 | 2 | 3 ]
- Sets the NTP version number which ntpq claims in
packets (defaults is 3). Note that mode 6 control messages (and
modes, for that matter) did not exist in NTP version 1. There appear
to be no servers left which demand version 1.
- authenticate[ yes | no ]
- The command authenticate yes instructs
ntpq to send authentication with all requests it makes.
Normally ntpq does not authenticate requests unless they
are write requests. Authenticated requests cause some servers to
handle requests slightly differently, and can occasionally cause a
slowed response if you turn authentication on before doing a peer
display. addvars variable_name[=value]
[ ,. . . ] rmvars variable_name [ ,. . . ]
clearvars
The data carried by NTP mode 6 messages consists of a list of
items of the form
variable_name=value
where the “=value” is ignored, and can be omitted, in
requests to the server to read variables. ntpq maintains
an internal list in which data to be included in control messages
can be assembled, and sent. This is accomplished with the
readlist and writelist commands described below. The
addvars command allows variables and their optional values
to be added to the list. If more than one variable is to be added,
the list should be comma-separated, and it should not contain white
space. The rmvars command can be used to remove individual
variables from the list; the clearlist command removes all
variables from the list.
- debug[ more | less | off ]
- Turns internal query program debugging on and off.
- quit
- Exit ntpq.
Control Message Commands
Each peer known to an NTP server has a 16 bit integer
association identifier assigned to it. NTP control
messages which carry peer variables must identify the peer that the
values correspond to, by including its association ID. An association ID
of 0 is special. It indicates the variables are system variables, whose
names are drawn from a separate name space.
Control message commands send one or more NTP mode 6 messages to the
server, and cause the data returned to be printed in some format. Most
commands currently implemented send a single message and expect a single
response. The current exceptions are the peers mreadlist
and mreadvar commands. The peers command sends a
preprogrammed series of messages to obtain the data it needs. The
mreadlist and mreadvar commands, iterate over a range of
associations.
Control message commands are described below:
- associations
- Obtains and prints a list of association identifiers and peer
statuses for in-spec peers of the server being queried. The list is
printed in columns. The first of these is an index that numbers the
associations from 1, for internal use. The second column contains
the actual association identifier returned by the server and the
third the status word for the peer. This is followed by a number of
columns containing data decoded from the status word. Note that the
data returned by the associations command is cached
internally in ntpq. The index is then of use when dealing
with “dumb” servers which use association identifiers that are hard
for humans to type. For any subsequent commands which require an
association identifier as an argument, the identifier can be
specified by using the form, &index. Here index
is taken from the previous list.
- lassociations
- Obtains and prints a list of association identifiers and peer
statuses for all associations for which the server is maintaining
state. This command differs from the associations
command only for servers which retain state for
out-of-spec client associations. Such associations are normally
omitted from the display when the associations command is
used, but are included in the output of lassociations.
- passociations
- Prints association data concerning in-spec peers from the
internally cached list of associations. This command performs
identically to the associations command except that it
displays the internally stored data rather than making a new query.
- lpassociations
- Print data for all associations, including out-of-spec client
associations, from the internally cached list of associations. This
command differs from passociations only when dealing with
servers which retain state for out-of-spec client
associations.
- pstatusassocID
- Sends a read status request to the server for the given
association. The names and values of the peer variables returned
will be printed. Note that the status word from the header is
displayed preceding the variables, both in hexadecimal and in pigeon
English.
- readvar [ assoc ] [ variable_name[=value]
[ ,. . . ] ]
- Requests that the values of the specified variables be returned
by the server by sending a read variables request. If the
association ID is omitted or is given as zero the variables are
system variables, otherwise they are peer variables and the values
returned will be those of the corresponding peer. Omitting the
variable list will send a request with no data which should induce
the server to return a default display.
- rv [ assocID ] [ variable_name[=value]
[ ,. . . ] ]
- An easy-to-type short form for the readvar command.
- writevar assocID variable_name=value
[ ,. . . ]
- Like the readvar request, except the specified
variables are written instead of read.
- readlist [ assocID ]
- Requests that the values of the variables in the internal
variable list be returned by the server. If the association ID is
omitted or is 0 the variables are assumed to be system variables.
Otherwise they are treated as peer variables. If the internal
variable list is empty a request is sent without data, which should
induce the remote server to return a default display.
- rl [ assocID ]
- An easy-to-type short form of the readlist command.
- writelist [ assocID ]
- Like the readlist request, except the internal list
variables are written instead of read.
- mreadvar assocID assocID [
variable_name[=value] [ ,. . . ] ]
- Like the readvar command except the query is done for
each of a range of (nonzero) association IDs. This range is
determined from the association list cached by the most recent
associations command.
- mrv assocID assocID [
variable_name[=value] [ ,. . . ] ]
- An easy-to-type short form of the mreadvar command.
- mreadlistassocID assocID
- Like the readlist command except the query is done for
each of a range of (nonzero) association IDs. This range is
determined from the association list cached by the most recent
associations command.
- mrlassocID assocID
- An easy-to-type short form of the mreadlist command.
- clockvar [ assocID ] [ variable_name[=value]
[ ,. . . ] ]
- Requests that a list of the server's clock variables be sent.
Servers which have a radio clock or other external synchronization
respond positively to this. If the association identifier is omitted
or zero the request is for the variables of the “system clock”. This
request generally gets a positive response from all servers with a
clock. Some servers may treat clocks as pseudo-peers and, hence, can
possibly have more than one clock connected at once. For these
servers, referencing the appropriate peer association ID shows the
variables of a particular clock. Omitting the variable list causes
the server to return a default variable display.
- cv [ assocID ] [ variable_name[=value]
[ ,. . . ] ]
- An easy-to-type short form of the clockvar command.
- peers
- Obtains a list of in-spec peers of the server, along with a
summary of each peer's state. Summary information includes:
- The address of the remote peer
- The reference ID (0.0.0.0 if the ref ID is unknown)
- The stratum of the remote peer
- The type of the peer (local, unicast, multicast or
broadcast) when the last packet was received
- The polling interval in seconds
- The reachability register, in octal
- The current estimated delay offset and dispersion of the
peer, all in milliseconds.
The character in the left margin indicates the fate of this peer
in the clock selection process. The codes mean:
- SPACE
- Discarded due to high stratum and/or failed sanity checks.
- x
- Designated falsticker by the intersection algorithm.
- .
- Culled from the end of the candidate list.
- -
- Discarded by the clustering algorithm.
- +
- Included in the final selection set.
- #
- Selected for synchronization; but distance exceeds maximum.
- *
- Selected for synchronization.
- o
- Selected for synchronization, pps signal in use.
Since the peers command depends on the ability to parse
the values in the responses it gets, it may fail to work from time
to time with servers which poorly control the data formats.
The contents of the host field may be given in one of four forms.
It may be a host name, an IP address, a reference clock
implementation name with its parameter or, REFCLK(implementation
number, parameter). On “hostnames no” only
IP-addresses will be displayed.
- lpeers
- Like peers, except a summary of all associations for
which the server is maintaining state is printed. This can produce a
much longer list of peers from inadequate servers.
- opeers
- An old form of the peers command with the reference ID
replaced by the local interface address.
ntptrace– trace a chain of NTP hosts back to their master time source
/usr/sbin/ntptrace [-vdn] [-r retries]
[-t timeout] [server]
ntptrace determines where a given Network Time Protocol (NTP)
server gets its time from, and follows the chain of NTP servers back to
their master time source. If given no arguments, it starts with
localhost.
OPTIONS
EXAMPLES
Example 1 Sample Output From the ntptrace Command
The following example shows the output from the ntptrace
command:
% ntptrace
localhost: stratum 4, offset 0.0019529, synch distance 0.144135
server2.bozo.com: stratum 2, offset 0.0124263, synch distance 0.115784
usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid 'WWVB'
|
On each line, the fields are (left to right):
- The server's host name
- The server's stratum
- The time offset between that server and the local host (as measured
by ntptrace; this is why it is not always zero for
localhost)
- The host's synchronization distance
- The reference clock ID (only for stratum-1 servers)
All times are given in seconds. Synchronization distance is a measure of
the goodness of the clock's time.
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 05, 2008
