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?

Nice feature for W60g,
always needed for Multi-Cell DECT and Video HD-SDI

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.

Any update on progress with IEEE1588 PTPv2 support?

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?

from a provider point-of-view - this is nice to have, but honestly I'd prefer other chip-features implemented available on crs317 hardware.

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.

Any update on IEEE1588v2 support?

Most likely it is impossible to do this in software. It needs a dedicated ASIC and a crystal oscillator

According to: https://help.mikrotik.com/docs/display/ ... e+Protocol

PTPv2 is Supported on:

• 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?

(feature request)

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.

I am wondering though... if the CRS326 is compatible, would the CSS326(switch only version) be also?

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.

I am wondering though... if the CRS326 is compatible, would the CSS326(switch only version) be also?

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

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.

It is possible with extra SFP-modul:
> OSA 5401 - Small form-factor pluggable (SFP) GNSS receiver and PTP grandmaster clock.

Do all of the switches from end-to-end need to support IEEE1588?

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:

1. 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).
2. 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).