[ntp:questions] How to get combined clock offset
david at djwhome.demon.co.uk
Tue May 10 19:13:01 UTC 2005
In article <mailman.0.1115748112.91305.questions at lists.ntp.isc.org>,
David Lyons <David_Lyons at raytheon.com> wrote:
[ BROKEN NEWS POSTING, References LOST - Attempting to reconstruct ]
Our system deploys NTPv3, possibly due to status of NTPv4 Protocol
> In my context "Time Quality" is the time offset of the local node's time
> relative to the time
As I already said, if ntpd knew that, it would be able to subtract it
from the local clock time and reduce that part of the discrepancy to zero.
It would also do that for upstream servers and have a zero error from UTC.
Note that ntpd only tries to synchronise with its immediate upstream
servers as a way of synchronising with UTC time. If it could synchronise
exactly to UTC time whilst maintaining an offset from the upstream server,
it would do so.
Possibly still missing a few terms, the error from UTC time is normally
bounded by offset - tolerance and offset + tolerance, where tolerance
is normally much larger than offset and, for v3 is something like
root delay / 2 + root dispersion + local clock resolution + time since
last update * worst case assumed residual slew rate.
On ntp4, most of the time, although I don't know the percentile, it will
be within offset - jitter and offset + jitter.
One can argue that during loop capture it might be able to reduce the offset
faster than it does, but in the steady state, the systematic part of the
offset ought to have been eliminated and the remaining part is just
> When I display the ntpq rv billboard I see, e.g.
> .... , phase=0.742, ...
I don't think there is a lower case phase in RFC 1305. Uppercase PHASE is
a loop parameter not a process variable. In any case, if you want the
offset from a particular, immediate upstream, server (noting that in
proper usage you are interested in UTC time, not the adjacent server time)
you need to read the variables for that association. There is a peer.offset,
although I don't know if it is exposed. I'd need to read the source code
to work out what phase is in this display.
> In NTPv3 I don't see any "offset" or "jitter" values.
NTPv3 doesn't have jitter. I don't think Dave Mills is going to answer
questions about NTPv3, though, so you are in the same position as me,
you need to read RFC 1305.
[ The other thing that is broken here is that the Subject didn't begin with
Re:, which means that newsreaders will assume a new thread given that
References is missing. Note the References problem is due to a broken
mail to news gateway - if possible use the USENET interface directly ]
More information about the questions