[time-nuts] Timing on Ethernet

Neville Michie 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  
the ring...

Neville Michie

On 05/08/2007, at 5:01 AM, Jack Hudler wrote:

> 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.  
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ 
> time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list