Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

[Greg Troxel]

I think the notion of error bounds by stratum is sort of confused.  Two
big points:

  The NTP design does not really calculate useful error bounds.  Other
  time sync protocols have tried to do so (DTS, see ref in RFC1305:
    [DEC89] Digital Time Service Functional Specification Version
    T.1.0.5. Digital Equipment Corporation, 1989.
  A big part of the issue is that theoretical bounds are so much bigger
  than what actually happens that they aren't that practically
  interesting.

  The stratum really is a hop count.  What's more important are the
  quality of the refclock at s1, the local clock quality, and the delay
  variance in the network paths.  So you could have a s4 that's within
  5ms, and a s2 that's 100 ms off.


I would say that without local clock problems, synchronizing across a
path with 100ms of base delay, as long as it is reasonably symmetric, is
not likely to introduce more than 10 ms of error, and often much less.
However, many paths in the Internet are seriously asymmetric due to
peering policy, For example, my home server sees two servers as 31 ms
apart, with delays of 17ms and 83ms.  However, those two servers are
less than 2ms apart and see an offset of 9ms.  So that's 22ms of error
which I attribute to asymmetric delay.  A lot of the delay is in
verizon/cogent peering, as far as I can tell.

So really my concise point is that it's about local clock quality and
delay asymmetry and variance more than hop count.

pgp6IHMvp05sS.pgp
Description: PGP signature