[time-nuts] Timing on Ethernet (Magnus Danielson)
Pablo Alvarez Sanchez
Pablo.Alvarez.Sanchez at cern.ch
Fri Aug 3 12:25:58 EDT 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.
More information about the time-nuts