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!!
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
