[time-nuts] Timing on Ethernet
namichie at gmail.com
Sat Aug 4 17:39:17 EDT 2007
Thinking outside the square....
What you need is a low frequency transmitter exactly in the middle of
On 05/08/2007, at 5:01 AM, Jack Hudler wrote:
> I was thinking of timing protocol only without any Ethernet on the
> (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
> 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!
> -----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
>> distribution node.
> He would need to have active nodes on a continous basis regardless.
> distance you get from 10Base-T or 100Base-T is not sufficient. Each
> not only need to regenerate signals put also redo the two-way-
> transfer. For
> 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
> too much you can't fail. Only thing to care about is not to feed it
> a too
> 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.
> 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
> carrier on the preamble end of that package. In order to create the
> slot for
> 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
> the base clock (locking a 25 MHz crystal to a 40 MHz is trivial in
> Locking of the bitclock removes the temperature-induced relative
> 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
> 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
> control range on a +/- 50 ppm clock we can only use a maximum of
> +/- 50 ppm
> 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
> useable depths of resolution.
> When one builds a network, one must recall that the resolution in the
> range measures and thus the roundtrip will translate to the one-hop
> and that the multi-hop systematic error growns linearly with it. The
> measurement noise will cause the traditional square-root-of-hop
> If you going to do a 5 hop network with 1 ns bounds, then each node
> contribute with more than 200 ps of systematic error.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/
> and follow the instructions there.
More information about the time-nuts