[time-nuts] Timing on Ethernet
magnus at rubidium.dyndns.org
Sat Aug 4 07:16:06 EDT 2007
From: "Jack Hudler" <jack at hudler.org>
Subject: RE: [time-nuts] Timing on Ethernet
Date: Fri, 3 Aug 2007 20:57:12 -0500
> Thanks Magnus, I guess I was dating myself :).
Jack, no worries! :-)
> Pablo, is this going to be used for timing throughout the entire CERN site
> or just instrumentation on 27km LHC?
> If it's just the LHC then what about using an open fiber/copper ring to
> distribute timing signals from both ends.
> Then you should be able to monitor propagation delay and compensate at each
> distribution node.
He would need to have active nodes on a continous basis regardless. The
distance you get from 10Base-T or 100Base-T is not sufficient. Each node would
not only need to regenerate signals put also redo the two-way-transfer. For a
27 km ring you probably would like to consider fiber as a real option unless
the spacing between points is dense enought. Multi-mode fiber would maybe do
the trick (up to about 2 km), but single-mode would do it easilly. GE SFP
modules is fairly cheap and should work well. If you don't stress the distansce
too much you can't fail. Only thing to care about is not to feed it a too hot
signal on the receiver side when you have a small distance, but that is only
a concern for short stretches with long-shot modules.
> I would think timing at less than 1ns would be easily obtainable using a
> consistent material for transmission.
The problem for these distances is mostly in the end terminal design. Getting
a sufficienly high resolution on the TICs, canceling biases, avoiding
ambiguities. The underlying math is however trivial.
What I would do is to steal some of the capacity (not bandwidth!) and have a
repeating ping going down the line with all the necessary info and measure the
carrier on the preamble end of that package. In order to create the slot for it
a "false" collision is created in the maxmimum package time justbefore the
time the test-packet is sent. Then the packet can be sent on an even clock
multiple of the base clock (40 MHz or whatever). Just after the test package
is sent normal traffic is allowed again. The Ethernet bitclock is locked up to
the base clock (locking a 25 MHz crystal to a 40 MHz is trivial in this game).
Locking of the bitclock removes the temperature-induced relative wandering. A
clear lock also removes the beating between the clocks. Depending on how the
TIC interpolation is intended to be done this may or may not be a good thing.
One very dirty method is simply to lock them slightly off so they have a
continous beat pattern. Considering however that we normally have a +/- 100 ppm
control range on a +/- 50 ppm clock we can only use a maximum of +/- 50 ppm for
our deliberate adjustment of the mark. It is however sufficient to keep the
integration times fairly short and to some degree act like an analog
interpolator. The interpolator design does not have to be advanced to get some
useable depths of resolution.
When one builds a network, one must recall that the resolution in the pseudo-
range measures and thus the roundtrip will translate to the one-hop resolution
and that the multi-hop systematic error growns linearly with it. The
measurement noise will cause the traditional square-root-of-hop increase.
If you going to do a 5 hop network with 1 ns bounds, then each node can't
contribute with more than 200 ps of systematic error.
More information about the time-nuts