Running ntp
version=ntpd 4.2@1.1541-o Mon Jan 19 15:18:44 UTC 2009 (1)
as reported by ntpq, on opensuse 11.1 Linux, if that matters.
I'm trying to make sense of the time offset numbers reported in
loopstats and peerstats files and by ntptrace.
The documentation is unclear on a few points, and ntptrace appears to
be broken:
1. peerstats:
the sign is unspecified in the documentation, but has been described
here as such that adding
the offset to the local clock should give time equivalent to the
remote peer; i.e. a positive offset
means that the local clock is early compared to the remote clock,
and a negative offset means
that the local clock is late.
Is that correct? If so, a clarification to the description in the
monopt documentation might be
helpful to others.
2. loopstats:
the distributed documentation is totally unclear. I have found a
Sun Microsystems document that
describes the offset as how much time (in seconds) the clock will
be adjusted by in the loop cycle.
a. Awkward wording notwithstanding, is that correct?
b. is the adjustment intended to remove the entire offset between
the local clock and the best-guess
estimate of UTC, i.e. can the loopstats offset field be
interpreted as the offset between the local
clock and the best-guess estimate of UTC? Or something else?
c. what about the sign in this case?
3. ntptrace output:
The man page (oddly enough, with version in the lower left as
4.1.1b-r5) gives an example:
% ntptrace localhost: stratum 4, offset 0.0019529, synch distance
0.144135
server2ozo.com: stratum 2, offset 0.0124263, synch distance
0.115784
usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993,
refid
[let's ignore the missing stratum 3 and the disappearing refid
value]
and text
On each line, the fields are (left to right): the host name,
the host stratum, the time offset between
that host and the local host (as measured by ntptrace ; this is
why it is not always zero for localhost )...
This is completely baffling:
a. what does it mean for the local host to have a time offset from
itself?
b. are the offset values cached or determined from cached data [if
I run ntptrace twice a couple of
seconds apart, I get offset values identical from one run to
the next down to the last reported digit,
while the synchronization distances vary significantly]?
c. is it intended that the offset reported by ntptrace bear no
resemblance to that reported by ntpq -p
and in peerstats?:
# ntpq -p
remote refid st t when poll reach delay
offset jitter
=
LOCAL(0).LOCL. 10 l 17 64 377
0.0000.000 0.004
+fastener.blilly 192.168.99.703 u 37 64 377
2.8440.722 0.093
*megatron.blilly 18.26.4.105 2 u 27 64 377
2.9270.296 0.122
+wally.blilly.ne 18.103.0.198 2 u 61 64 377
3.0361.352 0.171
# ntptrace
localhost: stratum 3, offset 0.000802, synch distance 0.030442
megatron.blilly.net: stratum 2, offset 0.002120, synch
distance 0.024161
bonehed.lcs.mit.edu: stratum 1, offset 0.03, synch
distance 0.001072, refid 'CDMA'
Note that ntpq reports an offset of 0.296 milliseconds from the
local host to its system peer, while
ntptrace reports an order of magnitude larger offset!
The most recent relevant peerstats line is:
54948 73944.514 192.168.99.73 9444 0.000318644 0.002920157
0.004549365 0.57198
which compares reasonably well to ntpq (offset around 300
microseconds, delay around 2.9
milliseconds).
Should I really believe what ntptrace says, viz. that the
local host is offset from a remote
stratum 1 server by a mere 3 microseconds in spite of orders
of magnitude larger values of
jitter (and that from a program that says the local host is
offset from itself by hundreds of
microseconds!)?
Ultimately I'm trying to do a couple of things:
1. determine if the loopstats offset value can be correlated to
something informative about the
system time of the local host, such as an estimate of the local
clock offset from UTC.
2. determine the best-guess estimate of the offset of a given peer
from UTC.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
