[ntp:questions] Re: Reading time offset from ntp variables using ntpq

Richard B. Gilbert rgilbert88 at comcast.net
Fri Feb 17 01:07:28 UTC 2006


In that case, I think RFC 1305 needs some clarification.  Page 100 
refers to these times as "T1, T2, T3, and T4" and they are not otherwise 
defined.  Page 50 defines the timestamps in the NTP packet as Reference, 
Originate, Receive, and Transmit.  The reader is left to guess where
T1 - T4 come from.  I guessed wrong.  Sorry about that.

Yes, I have read the darned thing though a lot of the math is over my head.

David L. Mills wrote:

> Richard,
> The reference timestamp is not one of the four timestamps used to 
> calculate offset and delay. It is intended for use when calculating the 
> maximum error should some other method than dispersion be used to 
> determine it. the next three timestamps you mention are struck at the 
> times you mention; however, the fourth (destination) timestamp is struck 
> upon arrival of the message at the client. I can understand your 
> confusion, since there are four timestamps in the header; however, the 
> various briefings and RFCs are very clear on which four are intended, 
> and that's why I suggested Daniel see the briefing.
> Dave
> Richard B. Gilbert wrote:
>> Daniel Kabs wrote:
>>> Hello David!
>>>  > As to which timestamp is "correct" you will need to read the
>>>  > architecture briefing on the NTP project page.
>>> That's not fair. I just wanted to use NTP as a tool to measure the 
>>> time drift of my system clock and now you pull the dreaded "read the 
>>> architecture briefing" weapon on me. What have I done to you to 
>>> deserve this? :-)
>>>  > While at it, understand
>>>  > the raw offset measurement does not reflect the actual clock offset,
>>>  > as the latter is determined by the clock discipline algorithm
>>>  > described in  the briefings on the project page. [...]
>>> You are talking about "clock discipline". That's confusing me as I am 
>>> running ntpd using option "disable ntp" which (according to your 
>>> implementation documentation) should disable time and frequency 
>>> discipline.
>>> Cheers
>>> Daniel
>> You could probably use any of the four time stamps if you measure over 
>> a long enough period.
>> The four timestamps are:
>> Reference: the time the local clock was last set. (This makes no sense 
>> to me but that's what the RFC says!  It would make more sense if it 
>> were the time the reply was received by the client.)
>> Originate: the time the request packet left your system
>> Receive: the time the request packet arrived at the server
>> Transmit: the time the reply packet departed the server
>> I would guess that the transmit timestamp would provide the best 
>> accuracy if you have to measure over a short interval.  Since the 
>> drift of your local clock is changing constantly, if slowly, I would 
>> recommend measuring over an interval of at least twenty-four hours.
>> If the environment in which your devices are used is not similar in 
>> temperature and temperature variation, the whole effort is probably a 
>> waste of time!!

More information about the questions mailing list