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

Pablo Alvarez Sanchez Pablo.Alvarez.Sanchez at cern.ch
Fri Aug 3 16:25:58 UTC 2007


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.

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


> 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?
Free running drift if we unplug the cable. 1ms over 30 minutes is ok.
But I would go for something like ~30us. 
Jitter between home made modules ~100ps rms

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



> 
> There are several ways to "hack" Ethernet with diffrenent benefits.


> 
> Cheers,
> Magnus


Pablo 




More information about the Time-nuts_lists.febo.com mailing list