[time-nuts] clock-block any need ?
attila at kinali.ch
Thu Dec 27 19:28:07 UTC 2012
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?
> 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.
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
> 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
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.
There is no secret ingredient
-- Po, Kung Fu Panda
More information about the time-nuts