[time-nuts] Timing on Ethernet

Jack Hudler jack at hudler.org
Sat Aug 4 15:01:35 EDT 2007


I was thinking of timing protocol only without any Ethernet on the fiber
(Trying to think outside the box, which gets in more trouble than you
know!). I'm not sure why Ethernet was mentioned, maybe they wanted to piggy
back on the existing net. That scenario sounds like IT bureaucratic
nightmare that I'd want to stay away from.

If Pablo is going to design their own hardware, perhaps something like
1550nm transmission on a high grade single mode fiber that should a nice
loss budget for the splices on 27km. Then design/adapt a simple timing
protocol that would support their desires.

Anyway it sounds like a fun project!

Jack
-----Original Message-----
From: Magnus Danielson [mailto:magnus at rubidium.dyndns.org] 
Sent: Saturday, August 04, 2007 6:16 AM
To: jack at hudler.org
Cc: time-nuts at febo.com
Subject: Re: [time-nuts] Timing on Ethernet

From: "Jack Hudler" <jack at hudler.org>
Subject: RE: [time-nuts] Timing on Ethernet
Date: Fri, 3 Aug 2007 20:57:12 -0500
Message-ID: <013801c7d63a$c6d34410$5479cc30$@org>

> 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.

Cheers,
Magnus




More information about the time-nuts mailing list