[ntp:hackers] Further to the timestamping issue

David L. Mills mills at udel.edu
Tue Jun 17 15:08:58 UTC 2008


It might not be clear from the documentation, as most folks might 
consider it an overly pedantic issue, but there is a serious formal 
model here. I consider three disciplined oscillators with respect to a 
primary server. First is the remote source, such as the WWV antenna. 
Second is the local reference oscillator in the GPS receiver or in the 
WWV case the audio codec. Third is the system clock disciplined by NTP. 
The device driver interface design is intended to allow contributions 
from the first two sources to be budgeted.

For example, the refclockproc structure includes reference timestamp, 
offset, dispersion and jitter intended to be inherited from the 
reference clock driver and its source. The delay is bugeted from the 
fudgetime values. The driver can budget these items either with respect 
to the receiver oscillator or the other end of the link, as does the WWV 
driver. The intent is to allow the driver to be as pedantic as 
justified. The intent is that a client in the high stratum desert know 
the delay and dispersion to the primary source, whether it be in 
Boulder, Mainflingen or a GPS receiver. For most drivers the distinction 
might not be significant, but the capability is there.


Poul-Henning Kamp wrote:

> In message <48572897.7030607 at udel.edu>, "David L. Mills" writes:
>> P-H,
>> On reflect, I don't know whether your discain for the NTP statistics
>> budget is due to a conclusion that the maximum error and expected error
>> statistics are not useful and/or confusing or that my calculation of
>> them is faulty. It would be useful to find out what your replacements
>> might be.
> Stratum 1 admins don't pay any attention to calibrating them correctly.
> And since they are uncalibrated, their values have no or little
> relation to the actual metrics.
> Thus: Useless in practice.
> But I don't know if they are by definition useless in theory: The
> latest definitions I have been able to find are:
> Root Delay (rootdelay): Total round trip delay to the reference
> clock, in NTP short format.
> Root Dispersion (rootdisp): Total dispersion to the reference clock,
> in NTP short format.
> But it is not obvious what is meant by "reference clock".
> Is that the piece of hardware connected to the S1 server, or is it
> the far-away atoms which governs the output of that piece of hardware ?
> If they only measure back only to the S1 server, then they are
> indeed useless in theory: You would need to query the S1 server
> to see where it lives and what refclock it uses, so you can compensate
> for the diurnal changes in propagation delay in case it is a VLF
> receiver, and for the jitter in case they used a cheap serial
> alarm-clock type receiver.
> If they refer back to the distant atoms, then 99% of all VLF based
> S1 servers on the net are badly uncalibrated (up to tens of
> milliseconds) and most of the rest merely trivially uncalibrated
> (tens of microseconds).
> In that case, they are possibly not useless in theory, but because
> the majority of servers are uncalibrated, we cannot know for sure.
> Since there is no way to get all the servers out there to shape
> up, any remedy would entail new fields with usable data, for
> servers which are calibrated, and a pass-note from uncalibrated
> servers.
> Poul-Henning

More information about the hackers mailing list