[time-nuts] Timing on Ethernet (Magnus Danielson)

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>

Hi Pablo,

> First of all thanks a lot for your answers. 

Thanks.

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

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

OK.

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

Cheers,
Magnus



More information about the time-nuts mailing list