Clocking
To be accurate
The use of atomic clock is highly controversial even among the sound engineers. Some say that as long as the DAC has a good clock, it doesn’t really matter as jitter is only a problem at D/A conversion.
Well, theory is theory, but when you have a chance to listern to a good master clock at work and pick 100% in a blinded A/B test, you will spend the money. For me, since I am running a few digital component at the same time, I have one more reason – to get synchronized.
Moving on to use AOIP, the clocking device will also have to be changed. instead of word clock, I moved to use PTPv2 network clock. There is one company that makes a clock for the Ravenna network. But I suspect any PTPv2 clock should work.
This Sonifex clock is connected to the switch and the clocking signal is distributed to the whole Ravenna network. So only one Cat 7 cable connection is enough. Gone with the days when I needs so many Coax cable and worried about signal reflections etc.
The above 3 screen is coming from the Advanced page user guide
Here is some more information
Information about E2E Vs P2P
https://tekron.com/news/release/end-to-end-versus-peer-to-peer/
Introduction
When using Precision Time Protocol (PTP), there are two methods of calculating delay within the network: End to End and Peer to Peer delay mechanisms. This refers to how the delay on a time signal is calculated, so we'll discuss that here. Before reading this article we recommend you are first familiar with the basics of how PTP works.
What is End to End?
End to End means the latency through the network is calculated directly between master and slave. This allows for PTP to operate over networks with Transparent clocks, non-PTP aware network switches, or a combination of both. The slaves sends delay requests upstream to the master, the master responds, and the network latency is calculated. The calculation is then applied by the slave to the received Sync message.
Why use End to End?
The advantage of this method is that the network nodes do not need to be PTP compliant, which reduces the limitations on hardware that can be used in the network. As end to end is measuring the delay between the master and slave any delay added to the system by the network nodes will be accounted for. However; the accuracy achieved through a network implementing End to End delay mechanism, will not be as good as the same topology implementing Peer to Peer delay mechanism with transparent clocks. Also note that End to End delay mechanism generates a larger volume of network traffic when multiple slaves being present on the network.
What is Peer to Peer?
Peer to Peer operates by calculating the delay between egress of the upstream node to the ingress of the downstream node (i.e. the delay down the wire) rather than the whole network at once. As sync, announce and follow-up messages are sent down the network, residence delay is accounted for in each node through the correction field, and downstream devices compensate for the delay down the wire. The difference is with the requests and response messages, which are only sent between two connected devices and are not used for calculating the delay past those devices.
Why use Peer to Peer?
Peer to peer is more efficient and is less affected by asymmetry within the network. When multiple slaves are present in a network, peer delay packets are only sent to the nearest node, not all the way upstream to the master. Lastly, if the network is to suddenly change due to a fault or similar, recovery time is reduced as not all delay calculations will be affected.
Now here is the clock at the Hapi terminal. You can see that there are a lot more jitter at this location. May be it is due to the way that it is connected. The signal from the Cisco switch is connected via the SPF+>optical cable and then the receiving end is a optical > RJ45 converter. I will try to see if using Lan cable can solve this problem. The other way to solve the problem is of course using a PTP aware switch
This is another view of the Hapi delta
Trying to correct this problem, I managed to find a fibre format converter that is PTP aware. This is probably the only one that is available on market right now. The model is EMCON 200 from OMICRON
My current setup using Cisco switch has been having glitches every now and then. If I look at the clock jitter, it is pretty high considering that I am using a PTP clock already. After some research, it may be due to the fact that Cisco SG300/350 switch is not PTPV2 aware and I have to use E2E protocol to pass the time signal down. (E2E protocol can work with PTP unaware switch to a certain extent) I have a very elaborate system and that can cause some jitter. I am now planning to change the switch to a PTP aware switch and options are Netgear M4300 or Gigacore 20T. I have just placed an order for Gigacore 20T.
Here are some information from Luminex https://www.luminex.be/improve-your-timekeeping-with-ptpv2-2/
In Nov 2023, my Gigacore 20t has finally arrived, it is a PTP aware switch so my configuration is a bit different now. The Sonifex Grandmaster clock is now set to P2P with the rest unchanged. All my Merging device are kept with Master Manual unchecked. This can be found in the PTP page.
