[time-nuts] clock-block any need ?

Magnus Danielson magnus at rubidium.dyndns.org
Thu Dec 27 23:13:47 UTC 2012

On 12/27/2012 08:28 PM, Attila Kinali wrote:
> On Thu, 27 Dec 2012 10:55:12 -0800
> 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.  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.
> I'm not sure about this. Knowing about how switches work internally,
> i'd guess they have "jitter" of something in the range of 1-10us, but
> i've never done any measurements. Have you any hard numbers?

Switches and routers can contribute significant amount of time.
On GE, a full-length packet is about 12 us, so a single packets 
head-of-line blocking can be anything up to that amount, multiple 
packets... well, it keeps adding. Knowing how switches works doesn't 
really help as packets arrive in a myriad of rates, they interact and 
cross-modulate and create strange patterns and dance in interesting ways 
that is ever changing in unpredictable fashion.

The GPS situation with ionosphere and troposphere is benign in 
comparison, yet challenging in their own right.

>>   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.
> Here lies the big problem. While with GPS we pretty much know what
> the time is that the signal takes to reach earth, we have no clue
> with network packets in a loaded network. We don't even have an
> idea what the packet transmit distribution is in the moment we are
> doing our measurements. Neither the queue length in the router/switch
> nor anything else. And the loading of a switch changes momentarily
> and this in turn changes the delay of our packets. You can of course
> apply math and try to get rid of quite a bit of noise, but you will
> never get rid of it down to ns levels.

A challenging thing, indeed.

> If i'm not mistaken, IEEE1588v1 had exactly that problem. They tried to
> use "normal" switches and hoped the jitter would be predictable enough to
> get compensated for. This didnt work out, so v2 now demands that all
> switches act as border clocks

The irony of it being that 1588v2 aware switches can work worse than 
dirt cheap switches, since the extra packet-handling is taking a slow an 
painful route through the switch.

>>   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.
> You can guestimate that getting below 200us is not easy in a normal
> network, but sub-1ms should be possible unless the network is very loaded.

The trouble is that you milage will vary on a typical network, these 
delays keeps shifting and you can get a good idea by measuring it for a 
few weeks, but you can't reliably predict it, just the overall shape of it.

Doing ~200 us for a non-trival network with real data on it sound about 

What kills many assumptions is that the noise-forms fail most of the 
normal assumptions about "noise". It's not zero mean, it does not have a 
static mean, it does not have a static variance, it is not symmetric, it 
is not independent of other traffic, it is not "just another service".


More information about the time-nuts mailing list