[time-nuts] clock-block any need ?

Attila Kinali attila at kinali.ch
Fri Dec 28 21:37:53 UTC 2012


On Fri, 28 Dec 2012 11:54:53 -0800
Dennis Ferguson <dennis.c.ferguson at gmail.com> wrote:

> 
> > 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?
> 
> I've measured it for large routers, but the numbers are not mine.  In
> a former life I helped design forwarding path ASICs.
> 
> I'm interested in what that guess is based on, however, since I can't
> imagine where 1-10us of self-generated jitter from an ethernet switch
> would come from, if not from competing traffic.

Routing table lookups. These things are getting more and more optimized
torwards cheap and troughput. These can and often will be (partially)
offloaded to an ARM or MIPS core running right next to the switch matrix
itself. The switch matrix itself is pretty fast. I wouldnt expect more than
a couple 100ns jitter from that.. if it even gets as high as 100ns.


> Even if 1-10us was observed for individual samples, however, that is
> still missing the point.  The interesting number is not the variability
> of individual samples, it is the stability of the measure of central
> tendency derived from many such samples (e.g. the average, if the
> variation were gaussian) that is the interesting number.

Yes, and that's where the statistics of the packet arrival time distribution
enter the game.

 
> ?? NTP is a two-way time transfer.  We directly measure how long the
> cumulative queue lengths are for the round trip for each sample, and we
> hence directly measure how this changes from sample to sample.  There are
> also good statistical models for the average behaviour of such queues when
> operating at traffic levels where packet losses are rare and where the
> bandwidth is not being significantly consumed by a small number of large,
> correlated, flows, which is the usual operating state for both local
> networks and Internet backbones (it is usually access circuits that are
> the problem) and there are heuristics one can use to determine when the
> statistics are not likely to be so nice; these are of use when designing
> the thing which has the queues.

Yes, but these statistics are based on stady state conditions, which
you dont have in real networks. Something is changing every second.
And if you say that these changes are part of the statistics, then
you must measure over a long period of time, that is measured in minutes
if not hours and then derive your statistics from that.

>  What we haven't had is hosts and servers
> capable of making precise measurements either of packet arrivals and
> departures (why is a ping round trip reported to be 200 us or 400 us
> when the packet spends less than 50 us in the network between the machines?),
> nor of external reference time sources like GPS nor, really, any good
> way to measure, and hence improve, the quality of the end result we
> want, which is the time on the client's clock.

That's the other big issue. But IIRC PHK mentioned a GBit or 10GBit card
a couple of months ago, that contains time stamping hardware for 1588.
So we might end up with consumer grade cards that support this soonish.
(As yo have written)


> Since we're now starting to see computers with peripherals which address
> some of these measurement problems really well (hardware time stamping
> for packets, hardware PPS timestamp capture) at the small 10's of
> nanoseconds level, what bothers me is the argument that there is no
> use trying to make use of this, other than for timenut bragging purposes,
> since NTP can't operate at anywhere near that level.  To me this argument
> is near perfect in its circularity.

I dont really get what you are hitting at, here.


> > 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
> 
> Yes, NTP will never match a properly implemented PTP, but then again the
> claims for what a properly implemented PTP can do still leave a lot of
> room between there and a microsecond.
> 
> While PTP was originally conceived as a consumer networking thing,

Oh..kay... And i thought it was for measurement instruments being
synced up trough the ubiquitus ethernet links instead of running
and additional coax.

> note that
> the major use of PTP, and one driving its design, has turned out to be in
> telecommunications networks where the replacement of traditional, finely-clocked,
> carrier circuits with ethernet for backhaul has deprived the thing at the far
> end of the backhaul circuit (say, a GSM/UMTS base station) of the frequency
> reference it formerly relied on.  The requirements for this application are
> stringent enough that the failure of 1588v1 to meet them cannot be construed
> as saying anything of practical importance about the ability of something
> that works like 1588v1 to set your computer's clock, other than it won't do
> as well as a well done 1588v2.

Interesting piece of information. Dou you have links of stuff i could
read up on this?


> >> 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.
> 
> So how did you compute the 200 us guess?  I know of no basis for that
> prediction.

>From the data ntp gives me in the networks i manage.
I hardly get any jitter number below 1ms, even with unloaded network
and unloaded hosts. The 200us comes from the "usual" rtt time measurements
on PCs.


> There are still many things to learn here.

Arent we here because for exactly this reason? :-)

			Attila Kinali

-- 
There is no secret ingredient
         -- Po, Kung Fu Panda



More information about the time-nuts mailing list