... | ... | @@ -117,7 +117,45 @@ the WR switch is open, there may in due time be more [producers of White |
|
|
Rabbit
|
|
|
switches](/Switch#commercial-producer).
|
|
|
|
|
|
-----
|
|
|
### Q: I was wondering if WR has plans to use SyncE as a standard for clock recovery, or if the custom clock recovery core in WR is as accurate (or better) for clock recovery? if WR meets the jitter SyncE specifications, what is the difference in the clock recovery method?
|
|
|
|
|
|
A: SyncE and WR are very similar in terms of clock recovery. What WR
|
|
|
does additionally is to implement a phase shift on the recovered clock
|
|
|
signal in the slave. This shift tracks changes in delay in the medium,
|
|
|
so as to guarantee constant (ideally zero) phase with respect to the
|
|
|
master clock signal. With SyncE, if the transmission delay in your fiber
|
|
|
changes, the phase of the clock signal you recover also drifts with
|
|
|
respect to that in your master.
|
|
|
|
|
|
The SyncE standard comprises of two elements:
|
|
|
|
|
|
1. slow protocol to configure the frequency distribution hierarchy in
|
|
|
the network
|
|
|
2. specification of timing characteristics of synchronous Ethernet
|
|
|
equipment (e.g. ITU-T G.8262)
|
|
|
|
|
|
In WR, the protocol (1) is not used which is rather uncommon in SyncE
|
|
|
networks but it is allowed by SyncE. The timing characteristics (2) of
|
|
|
SyncE have a lot of legacy burden (compatibility
|
|
|
with SDH). Consequently, SyncE equipment must be tolerant to quite "bad"
|
|
|
clock input. WR is not tolerant to the corner-cases required by SyncE,
|
|
|
see the report on [SyncE Characteristics of a White Rabbit
|
|
|
Switch](https://www.ohwr.org/project/white-rabbit/uploads/6de0c67da6a12f470af5a921279711ce/WR-SyncE-characteristics-report.v3-2015-02-27.pdf)
|
|
|
. Making WR PLL tolerant to clock characteristics required by ITU-T
|
|
|
G.8262 might result in deterioration of WR performance (e.g. requires
|
|
|
change in PLL bandwidth) or require much more expensive oscillator.
|
|
|
|
|
|
ITU-T itself recognized that the SyncE specification is outdated and
|
|
|
most of SyncE equipment can do much better than the specifications.
|
|
|
Therefore, ITU-T is working on enhanced SyncE
|
|
|
([eEEC](http://www.itu.int/itu-t/workprog/wp_item.aspx?isn=10340)).
|
|
|
There is some consultation between ITU-T and WR on the eEEC, though with
|
|
|
low priority, at the moment it seems that eEEC will not be directly
|
|
|
usable with WR.
|
|
|
|
|
|
??Authors: Javier Serrano, Maciej Lipinski,
|
|
|
[CERN](http://cern.ch??)
|
|
|
\---
|
|
|
|
|
|
## Switch management
|
|
|
|
... | ... | @@ -439,7 +477,7 @@ Additionally, wrs\_dump\_shmem will report ID's in fields calib.sfp.\* |
|
|
|
|
|
-----
|
|
|
|
|
|
11 May 2015
|
|
|
11 January 2016
|
|
|
|
|
|
|
|
|
|
... | ... | |