We plan to introduce IEEE1588 PTPv2 feature for some of the CRS317 series switches.
At the moment we plan to add support for the IEEE1588 PTPv2 Boundary clock which can be operated by transport layer2/udp4 and possibility to choose the delay-mode end-to-end/peer-to-peer.
Support for the 802.1AS (gPTP) will be also added.
Note that the clock is not synchronised to the system clock.
Maybe you could give us some feedback if you would like to use that feature in our CRS switches?
What additional options you would like us to add for this feature?
That is great news.
Just thinking further - together with GPS it could become a really nice Master clock or even grand master…
And it could open the CRS range for use with AVB.
First make this a reliable switch. Connecting 10G and 1G is still a mess. We get packet loss and vpls tunnels with sporadic outages. I cant even see if flow control is negotiated? How do you test this switch without this information? We consider to remove all our CRS317 at the moment.
CRS326-24G-2S+ supported only on Gigabit Ethernet ports
CRS328-24P-4S+ supported only on Gigabit Ethernet ports
CRS317-1G-16S+ supported on all ports
CRS326-24S+2Q+ supported on SFP+ and QSFP+ interfaces
CRS312-4C+8XG supported on all ports
CRS318-16P-2S+ supported only on Gigabit Ethernet ports
Looking to get one of these to test with my MOTU 828es AVB audio interface with another AVB audio device to expand audio I/O with just my local studio/office switch.
I am wondering though… if the CRS326 is compatible, would the CSS326(switch only version) be also?
It seems the switches in the RB5009 (88E6393X) and CCR2116 (98DX3255) have some support for PTP 1588v2 - I would be interested in using them as a transparent clock. Are these similar enough to the switches in the CRS317 that they could be enabled?
I have a GPS / OCXO PTP grandmaster and am currently using an IGS-6325-8UP2S2X as a transparent clock in a video acquisition synchronization project. I need more ports : ). If the CCR2116 or rb5009’s switch could also participate in 1588v2 distribution it would help a lot.
keep in mind CSS switches has almost no CPU and or Memory to run additional software features, thanks tho this there are cheaper, but fitted for more basic use
keep in mind CSS switches has almost no CPU and or Memory to run additional software features
For boundary clock, this is essentially a hardware feature. The switch chips corrects the 1588v2 timestamp as it flows though the switch (or gets stuck in a egress queue). Not much software really runs besides turning on the hardware.
That’s fine, it would be connected to my main Mikrotik router and not need to do any routing, filtering, etc. Just basic local office switching. So it would seem to be perfect. As long as it can switch AVB audio packets. I want to test this soon.
Do all of the switches from end-to-end need to support IEEE1588? I am in the need for possibly supporting IEEE1588 at the network edge, I have existing CRS317-1G-16S+ switches (currently running SwOS but can change to ROS if required) within the core with another vendor GPS device that can serve as GM, but also acquired a CRS328-4C-20S-4S+RM as a distribution switch to the perimeter. I’m considering utilizing NetPower 16’s (CRS318-2S+16P) at the edge to serve the last mile to the endpoints.
So the network path would be GM ↔ CRS317 ↔ CRS328 ↔ NetPower 16P ↔ Endpoint
As of now no video is going through this network, strictly audio.
From technical point of view: no. From precission point of view: yes. The main point of running IEEE1588 (as opposed to plain NTP) is to give OC accurate information about delay between GM and itself. Delay is mainly due to two reasons:
physical link delay
This delay is on most links constant and is sum of delay on physical port (parallel to serial conversion, etc.) and delay on link itself (due to signal speed which is finite).
This delay is configuration property of each link and can be different in each direction (e.g. higher parallel to serial delay in slower direction on lines with asymmetrical speeds).
delay on active equipment
This delay can vary a lot due to how device handles packets (e.g. queuing) and support for IEEE1588 on these devices improves precission as delay of each individual timing packet can be accurately determined (and set or added to already present delay info) on egress.
If there’s non-IEE1588 equipment in the path between GM and OC, then lack of accurate delay measurements will reduce accuracy of timestamps received. If the non-IEEE1588 device is not congested in any way, so that delay of packets passing from GM towards OC is pretty constant, then it is possible to add that delay to link between adjacent IEEE1588 devices and then accuracy will be mostly fine (worse than if all devices were IEEE1588 but not much). OTOH if the non-IEE1588 device does see congestion now and then, the precission of timing information drops on the floor (and is then not much better than plain NTP).
This feature would be useful! May I make some additional suggestions to make PTP even more useful?
PPS or 10MHz input for the GM. I’d like to connect my GPS direct to the 317 if I’m going to use it as a GM. Otherwise, will you consider making a dedicated device to act as GM using the Open Time Server as a reference design?
You can try MiCLK from RAD. It almost same device as OSA5401, with WEB interface and about 30% cheaper. But it have some think, we go to use ADVA - the MiCLK doesn’t begin operate as GM, before it will be once locked. ADVA can operate on its Stratum 3 clock.
Finally, i have setup CRS326-24S+2Q+ as fronthaul 5G SA base station with PTP support. The 4 RU’s operates MIMO 4x2 (4T2R) with DU synced with ADVA OSA5401 works fine.
The switch setup is not clear as other switches, but it possible. Some issues with PTP implementation:
L2 GM packets not isolated in bridge. So if PTP destination is forwardable mac (01-1B-19-00-00-00), the all PTP packets spread to all bridge ports, and slave devices also see GM packets, and could choose GM. If i change PTP destination to non-forwardable mac (01-80-C2-00-00-0E), the announce and sync packets not forwarded, but switch send delay_request to (01-1B-19-00-00-00) and ADVA also answered to (01-1B-19-00-00-00), so these packets also spread to all ports. There are no possibilities to add VLAN to PTP traffic, and switch rules also doesn’t work for me. The only way i found - create dedicated bridge for GM.
The PTP slaves ports also not isolated, so all multicast PTP traffic pass thru all PTP ports. This is less problem, but usually BC switches isolate every PTP traffic by its port.
The PTP implementation have one bug: when GM in already locked switch suddenly change TOD to huge value (hours, month, years), the switch newer will come to sync state. These can happen when GPS signal of GM is lost, GM lost power, etc… If Mikrotik use ptp4l, it better to add step_threshold 0.002 to the setting.
I’m really waiting for 100G Mikrotik switches with PTP support. The 10G already go out from communication segment.
Maybe anyone could help me with setting routing to PTP bridge? The GM have static IP from same management network, and i need get access to SSH, TELNET, logs and NTP of GM.
