[ntp:questions] How to get combined clock offset

David L. Mills mills at udel.edu
Tue May 10 23:54:23 UTC 2005


David,

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 wrote:
> 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
> 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 ]



More information about the questions mailing list