Re: Reading time offset from ntp variables using ntpq

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!!


No, that doesn't matter. Different devices are expected to have not only
different temperatures but also different clock accuracies,
fluctuations, etc.

And interesting variation on having NTP discipline your clock, you could
instead use it to measure the temperature fluctuations of your clock!

Danny
_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions

.

Relevant Pages

  • Re: Reading time offset from ntp variables using ntpq
    ... 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. ... I would guess that the transmit timestamp would provide the best accuracy if you have to measure over a short interval. ...
    (comp.protocols.time.ntp)
  • Re: Windows clock update frequency
    ... When using NTP, the clock may gap forward or backward. ... The resolution of the timestamp you are looking for is on the same ...
    (microsoft.public.development.device.drivers)
  • Re: Hardware SNTP server
    ... Directly connecting our SNTP server and passing through ... We also have a remote experiment site, where we use a cesium clock ... the fraction of a timestamp is culculated from this 250MHz count. ... the NTP response is sent from the same GbE port. ...
    (comp.protocols.time.ntp)
  • Re: requestors time; transmit timestamp?
    ... > In an NTP request which timestamp carries the requestor's notion ... Transmit Timestamp ... To calculate the roundtrip delay d and local clock offset t relative ...
    (comp.protocols.time.ntp)
  • Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday
    ... Uses NTP to modify the clock frequency value rather then just ... > adjustment, which should be applied every f cycles. ... Your design seems to suggest keeping an NTP calculated reference time ...
    (Linux-Kernel)