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

David L. Mills mills at udel.edu
Fri Feb 17 02:50:51 UTC 2006


Richard,

Well, I wrote 1305 fourteen years ago when I was just a kid. The on-wire 
  >draft< protocol spec for NTPv4 now on the project page at 
http://www.eecis.udel.edu/~mills/database/brief/flow/ntp4.pdf is 
hopefully much more explicit.

Dave

Richard B. Gilbert wrote:
> Dave,
> 
> 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