[ntp:questions] toward ubiquitous high precision time-stamps

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sun Jul 1 13:25:17 UTC 2007

In article <DUL1WNEXCN02GXix4A200000674 at dul1wnexcn02.vcorp.ad.vrsn.com>,
trutkowski at verisign.com (Tony Rutkowski) wrote:

> For example, if the time-stamp included the
> most recent NTP query information such as the

This sort of information is available by diagnostic mode requests, but is 
generally blocked by anyone with a paranoid security consultant as revealing
too much information about the server.

> NTP reference clock URI, last local clock offset

There is no URI scheme for reference clocks, but given that even a stratum
1 server may be using an average of the data from multiple reference
clocks, I'm not sure that there is any meaningful value other than the
already implied "UTC Time".

The last clock offset should be statistically random, probably Gaussian and
should be very much larger than the intrinsic error in the time on the server,
so I'm not sure what real use it is.  It may not be from the upstream source
that has the greatest contribution to the server's estimate of the time, or,
if one restricts it to that source, the relative weights of that source and
another source might be something like 60:40, so it might cause a significant
contribution to the time estimation error to be completely ignored.

> and jitter, and current drift rate, much greater

I had a feeling that something close to jitter was already transmitted, but
I might be wrong.

Drift rate is useless in this context unless you are monitoring how it changes
from sample to sample from the same server, in which case jitter might be a
better measure.  Any drift rate between about -450ppm and +450ppm, as long as
it is stable, indicates the server has no problems.

> precisions could be effected.  Any work being
> done along these lines?

Could you provide some concrete algorithms, and indicate why they couldn't be 
used, locally, by the server, to improve its own timekeeping.

[ This article appears to be a thread root, but is threaded into a thread
  with at least two other articles.  That thread is "Peering and synching with
  multiple interfaces and subnets".  I'll truncate the References,
  but the damage has largely already been done, as newsreaders can chain the
  thread together with only one reference per article. Anyone who has killed
  the other thread won't even see this one.  ]

> References: <7FC0CE00FF1F3048A8D00B1F89B27120C7AFF4 at BLGN165202.mail.banverket.root.local> <46871E8C.5070005 at ntp.isc.org>

More information about the questions mailing list