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

David L. Mills mills at udel.edu
Fri Feb 17 21:24:01 UTC 2006


Been there. Type the command except the CR. Listen to WWV and swiggle 
the second finger to the tick. At the long tone poke the CR. I can get 
it to within 20 ms. Can anybody else do better?


David Woolley wrote:

> In article <N8GdnTnGn4MPC2nenZ2dnUVZ_s6dnZ2d at comcast.com>,
> Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>>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.)
> Reference time is the time on the *server* when the last change in best
> offset measurement happened.  It can be relatively far in the past and is
> useless for the current purpose.  It is not a time on the local machine.
>>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
> The measurement takes a finite time to make (delay I think, but it might
> be twice delay).  Basically it takes between Originate and Originate + delay
> (the client receive time isn't recorded here).  Therefore you cannot state
> one specific time at which the measurement was made.  Using any of the
> latter 3 should be OK as long as you always use the same one.  Note that,
> as the clock isn't being disciplined, Originate may differ drastically 
> from Receive and Transmit (i.e. by offset).
> I think you asked how I measured the standing frequency error to calibrate
> to 30 seconds a year.  At the time, the office didn't have internet
> access, so I used a radio controlled wristwatch and ran the command
> "netdate localhost" on an exact second.  To get the exact second, I typed
> all of the command except for the carriage return, then got my finger
> tapping lightly in time with the seconds, and, once I had the rhythm, did
> one final hard tap.  That seemed to be repeatable to better than 100ms.
> (I think I first forced the watch to update.)
> The final fine tuning was done over about a week.  I'd now do ntpdate
> over a baseline of about a week.  In that case, I then set the drift 
> value, so subsequent calibrations were of the residual error.  Nowadays,
> I use ntptime, to set the kernel parameters, and don't run ntpd at all.
> When I'm correcting phase, I make sure my modem is idle before issuing
> the ntpdate command.  I don't use ntpd in one shot mode because I don't
> want the frequency disturbed.

More information about the questions mailing list