); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY From: "Jack Hudler" <[EMAIL PROTECTED]> Subject: RE: [time-nuts] Timing on Ethernet Date: Fri, 3 Aug 2007 20:57:12 -0500 Message-ID: <[EMAIL PROTECTED]>
> 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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.