[time-nuts] Timing on Ethernet (Magnus Danielson)
magnus at rubidium.dyndns.org
Fri Aug 3 12:48:09 EDT 2007
From: "Pablo Alvarez Sanchez" <Pablo.Alvarez.Sanchez at cern.ch>
Subject: Re: [time-nuts] Timing on Ethernet (Magnus Danielson)
Date: Fri, 3 Aug 2007 18:25:58 +0200
Message-ID: <42A60383A3EA19429E22C122E276B2F48C4AE3 at cernxchg44.cern.ch>
> First of all thanks a lot for your answers.
> > For a facility like CERN, I think that normal cabel
> > assymetries will be sufficiently low such that they would not
> > require explicit handling, unless you have higher
> > synchronisation demands, but in that case I would strongly
> > suggest a different solution.
> You are right. Most of our aplications just demand ~1ms accuracy. Right
> now our requirement is only 1us accuracy, which is actually not so bad
> if you consider we have a 27Km accelaretor to monitor. But this is a
> long term project, so we have to try to do it as good as possible. I
> think ~1ns is nice goal.
~1 ns should be acheivable without too much hazzle if one pays some attention
> > Looking at the IEEE 1588 while implementing in your own FPGA
> > seems like an odd choice. It is an option, but you could
> > fairly easy cook up something which fits your needs. It is
> > not too hard actually.
> We may also connect to this network some "foreing" equipment like PLCs.
> Then IEEE 1588 would be quite helpful.
Certainly. But you can also see that as long as those see a IEEE 1588
interface you don't have to use that internally to the system. Double systems
add cost, but the benefit may be there anyways.
> > The most important issue is what kind of performance do you need?
> > Maximum time-errors?
> Not defined yet
> > Stability requirements?
> What does this really mean?
Stability of a node during continous tracking.
Maximum drift during holdover is another aspect.
For your kind of operation I would consider redundancy in links and nodes.
Not necessarilly within the nodes.
> Free running drift if we unplug the cable. 1ms over 30 minutes is ok.
> But I would go for something like ~30us.
Should be manageable. +/- 1E-6 in frequency error.
> Jitter between home made modules ~100ps rms
That is large. But if that is sufficient, I won't argue with it.
> > Full UTC time or only UTC coordinated PPS?
> Full UTC. We use UTC to tag external events and for Post Mortem
> analysis. If there is anything wrong around the machine, a pulse is sent
> to our receivers and time tagged. With this we can reconstruct the
> situation that originated the problem.
> > 10 MHz clock?
> Right now we use a 40MHz clock in our receivers. We can delays using
> this clock, or start counters with external clocks.
Sounds reasnoble. Gives 25 ns resolution without any interpolators. Just a
simple interpolator can give you significant improvement, but so will
More information about the time-nuts