How to get combined clock offset
David Lyons
NTP Version 3.
It seems that the NTP system state variable "theta", the combined clock
offset, would be the variable we need.
Can this, or equivalent variable, be obtained programatically by sending a
"Read System Variables Command" to xntpd?
If so, what would be the response data field <identifier>=<value> that
would identify this variable?
Thanks,
David Lyons
Raytheon Company
DD(X) Application Services
Tewksbury, MA
(978) 858-9064
David Woolley
David Lyons <David...@Raytheon.com> wrote:
> We need to get a measurement of "Time Quality" for our node. We are using
> NTP Version 3.
Why are you interested in quality but using an obsolete version?
> It seems that the NTP system state variable "theta", the combined clock
> offset, would be the variable we need.
Overall theta is offset in loopinfo (ntpdc) and the individual thetas
are the offsets in the peers displays. It's not a quality indicator.
If ntpd where confident of the value of theta, it would have corrected
the local clock by that amount, so theta would be reduced until it was
no longer confident in the value. In fact, I think that there isn't
really an overall theta, but rather theta for the most recently selected
reference clock, at the time it was polled.
What would be a good measure depends on what you mean by quality.
ntpd's main quality measure is root dispersion, which is the worst case
error, assuming that the ultimate reference is a real reference clock and
not someone's local clock (basically it assumes that all the propagation
delay could be in one direction and that the clock has drifted at the
maximum reasonable rate since the last measurement).
David L. Mills
By design the two error metrics are root synchroniztion distance
(rootdelay / 2 + rootdispersion + jitter) and combined jitter (weighted
by synchronization distance). The former is the maximum error, the
latter the estimated error. There are tricky little details in the error
budget that have changed over the versions, but the original intent remains.
Please do not use ntpdc as error indicator; it is seriously flawed. Use
ntpq and the rv billboard for the rootdelay, rootdispersion and jitter
displays. Note the jitter display, which includes both peer jitter and
selection jitter, is probably the best indicator of expected time
quality. Read this as follows: the best estimate of the server time is
the offset in the rv display, with jitter as the uncertainty about that
value.
That's all that can be said about the statistics. A more thorough
analysis would have to use the loopstats and compute the distribution
function, such as displayed in the briefings on the NTP project page.
Dave
David Woolley
> By design the two error metrics are root synchroniztion distance
> (rootdelay / 2 + rootdispersion + jitter) and combined jitter (weighted
It was my mistake to exclude rootdelay. For some reason I had thought
that root dispersion included root delay even though peer dispersion
doesn't. The parameter I described was rootdelay / 2 + rootdispersion.
I'm on dialup so didn't have a live ntpd to look at typical values.
However, the questioner is using version 3 and, in any case, the last
time I looked, there wasn't a specification for version 4. I looked
for some sort of RMS error measure in the PDF equivalent of RFC1305
(on paper) but there is certainly no such parameter exposed on the
diagnostic interface and I can find no such internal value either.
If RFC 1305 had had some form of jitter measure, I would have suggested
that might match one possible definition of quality. (I think it might
be buried in Greek letters and exposed only as part of the overall
rootdispersion in NTP v 3.) (Incidentally, looking at the PDF RFC1305,
appendix F seems to the only part that might benefit from not being
plain text.)
> Please do not use ntpdc as error indicator; it is seriously flawed. Use
ntpdc was proposed as an easy way of getting the final theta value,
although I also said it almost certainly wasn't the desired parameter.
(Originally I failed to find capital-THETA's calculation, because it is
hidden in an appendix, but it looks as though it is not even indirectly
exposed in the RFC 1305 diagnostic interface.)
> ntpq and the rv billboard for the rootdelay, rootdispersion and jitter
For the worst case, I would have thought that the dispersion parameter
required was pkt.rootdispersion, which is only transmitted in the
non-diagnostic packets, as far as I can tell.
> quality. Read this as follows: the best estimate of the server time is
> the offset in the rv display, with jitter as the uncertainty about that
> value.
Only to the extent that there isn't a systematic error (e.g antenna
cable delay for a reference clock or asymmetric transmission rates over
a network).
David L. Mills
First, rfc1305 and xntpd are completely cold, dead and gone. The rfc1305
continues as a description of most aspects of NTPv4, but the detailed
algorithms have evolved as described in the journal articles and white
papers at the NTP project page linked from www.ntp.org. The NTPv4 spec
is under way and documented in the briefings at the NTP project page.
The architecuture briefing lays out the error budget in some detail.
Dave
David Lyons
Specification.
In my context "Time Quality" is the time offset of the local node's time
relative to the time
server.
When I display the ntpq rv billboard I see, e.g.
... , phase=0.742, ...
Would this be the last offset relative to the reference source? What are
its units (milliseconds?).
In NTPv3 I don't see any "offset" or "jitter" values.
Thanks,
Dave L.
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
David Woolley
David Lyons <David...@raytheon.com> wrote:
[ BROKEN NEWS POSTING, References LOST - Attempting to reconstruct ]
Our system deploys NTPv3, possibly due to status of NTPv4 Protocol
Specification.
> In my context "Time Quality" is the time offset of the local node's time
> relative to the time
> server.
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
phase noise.
> 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 ]
David L. Mills
Your idea of propagating the server offsets upstrata has been suggested
before. The problem is, the client gets the immediate downstratum time
at the time the packet is sent, not the time when the server was last
synchronized. This can result in a large delay between the primary
server read of the reference clock until the client hears from the
immediate downstratum server. Concidering the entire NTP subnet is one
huge herd of coupled oscillators operating as a huge phase-lock loop,
the long delays would result in certain system instability and eventual
meltdown. The image of a pinball machine would be accurate.
There is another reason not to carry the offsets upstratum. Some links
in the subnet can be rather noisy; however, in the current design each
stratum amounts to a lowpass filter and smoothes the jitter. To the
extent that the clock filter, clustering, combining and loop filter can
reduce the jitter, you get better time than if you propagated the offsets.
Dave
David Woolley
> Your idea of propagating the server offsets upstrata has been suggested
> before. The problem is, the client gets the immediate downstratum time
I think you were reading more into what I wrote than I intended. I was
really trying to say that offset is probably not the measure that he
wanted, but that if he did want to use such a measure, what he would
want would be the estimated error from the reference clock, not that
from the immediate upstream server.
I strongly suspect though, that he's using the local clock on the
immediate upstream server as his reference clock (hence "the server", is
the root server and is the reference clock), as, although unsupported,
that seems the most common configuration used by people asking
questions here. That's also why I stressed UTC.
If there was an implied proposal, it was more to do with the issue that
is quite often possible for a human observer to make a better guess
at the true offset during startup or after a loop disturbance (heating
going on etc.) than the daemon and there may be ways of automatically
getting below the phase and frequency noise quicker than at present.
They may, of course, make other situations worse.