On 12/27/2012 08:28 PM, Attila Kinali wrote:
On Thu, 27 Dec 2012 10:55:12 -0800
Dennis Ferguson<[email protected]> 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
right.
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".
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
