[time-nuts] clock-block any need ?

Chris Albertson albertson.chris at gmail.com
Thu Dec 27 19:17:18 UTC 2012

On Thu, Dec 27, 2012 at 10:55 AM, Dennis Ferguson
<dennis.c.ferguson at gmail.com> wrote:
> I don't think I buy this.  It takes 70 milliseconds for a signal
> transmitted from a GPS satellite to be received on the ground, but
> we don't use this fact to argue that sub-70 ms timing from GPS is
> not possible.

We don't care how long it takes, we care about the uncertainty in the
length of time.  The speed of light through space is very, very
certain and
If you have a network of high-bandwidth routers and
> switches doing forwarding in hardware, and carrying no traffic other
> than the packets you are timing (I have access to lab setups that
> can meet this description) you can observe packet delivery times that
> are stable at well under the microsecond level even though the total
> time required to deliver a packet is much larger.

> If you add competing
> traffic, like real life networks, the packet-to-packet variability
> becomes much worse, but this is sample noise that can be addressed
> by taking larger numbers of samples and filtering based on the expected
> statistics of that noise.

This is what NTP does.  It looks at the clocks over a long period of time.
> That is, the level of noise effecting
> each individual sample entering the filter does not alone predict
> the noise level of the result coming out, the latter also depends on the
> number of samples and the quality of the model of the noise employed by
> the filter.  Note that I often see claims of time synchronization with
> PTP at the 10 ns level or better.  As this level of synchronization is
> usually achieved by the brute force method of measuring transit times
> across every network device on the path from source to destination I
> have no doubt that what NTP can do will necessarily be worse than this,
> but I don't know of a basis that would predict whether NTP's "worse"
> is necessarily going to be 10,000x worse or can be just 10x worse.
> Knowing that would require actually trying it to measure what can be
> done.

We know the numbers, many peole have done this.  I could be off by 10X
because maybe my memory is wrong or terminology does not match yours
but in principle we know these numbers.

We know what the best NTP servers using their built-in TTL oscillators
can do.  BSD based PCs connected to a good timing mode GPS get to 2
uSecond offsets from "true".   This seems to be the limit unless one
resorts to heroic efforts involving special built hardware.  But even
the best lab setups using Ethernet are not this good.   So my
conclusion was that if accurate client timing is the goal then it will
NOT help.  The Ethernet based NTP clients will still have mS level
timing (1000x worse than the GPS connected server) not matter how good
the server is.  Hence my advice to NOT bother with a special purpose
"clock block"

That was the bottom line, that a purpose built clock is not needed.

If good client timming is desired using NTP you are going to have to
distribute the PPS from GPS using some side channel, making the server
better is of no use.  Or use PTP and special purpose network equipment
(But I bet PPS distribution would be cheaper if you simply used the
extra unused twisted pairs inside most Cat-5 cable.)

The reason you can't distribute ns level time over a network to normal
NTP clients is because of the random queing that happens inside the
client's ethernet interfaces.  The normal installed base of ethernet
cards does not do time stamping.  So even uSec level timing is lost in
the typical client.

> What is certain, however, that if you want to measure this at the levels
> that might be possible you probably want nanosecond-level clock hardware
> in both the server, so that it can produce time of this quality, and in
> the clients, so that you can measure how well they do directly rather
> than attempting to have the NTP implementation grade its own homework.  I
> don't think this is a waste of time at all.  The best case is that the
> ability to measure at this level would lead to an understanding of what
> it would take to transfer time with NTP at this level, but even the worst
> case would be that one would be able to support one's assertions about what
> can't usefully be done with data, and that's not bad either.  If no one
> tries then no one will ever know.
> Dennis Ferguson
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.


Chris Albertson
Redondo Beach, California

More information about the time-nuts mailing list