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.000 0.000 0.004 +fastener.blilly 192.168.99.70 3 u 37 64 377 2.844 0.722 0.093 *megatron.blilly 18.26.4.105 2 u 27 64 377 2.927 0.296 0.122 +wally.blilly.ne 18.103.0.198 2 u 61 64 377 3.036 1.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.000003, 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.000057198 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