[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