Community discussions

MikroTik App
 
uldis
MikroTik Support
MikroTik Support
Topic Author
Posts: 3442
Joined: Mon May 31, 2004 2:55 pm

IEEE1588 PTPv2 support for CRS317

Thu Nov 21, 2019 11:31 am

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?
You do not have the required permissions to view the files attached to this post.
 
mistry7
Forum Guru
Forum Guru
Posts: 1476
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: IEEE1588 PTPv2 support for CRS317

Thu Nov 21, 2019 11:58 am

Nice feature for W60g,
always needed for Multi-Cell DECT and Video HD-SDI
 
User avatar
cdiedrich
Forum Veteran
Forum Veteran
Posts: 997
Joined: Thu Feb 13, 2014 2:03 pm
Location: Basel, Switzerland // Bremen, Germany
Contact:

Re: IEEE1588 PTPv2 support for CRS317

Thu Nov 21, 2019 12:50 pm

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.
 
tmichaud
just joined
Posts: 7
Joined: Fri Oct 14, 2016 10:06 pm

Re: IEEE1588 PTPv2 support for CRS317

Mon Feb 17, 2020 4:57 pm

Any update on progress with IEEE1588 PTPv2 support?
 
User avatar
hknet
Member Candidate
Member Candidate
Posts: 116
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: IEEE1588 PTPv2 support for CRS317

Sun Feb 23, 2020 10:19 am

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.
 
ste
Forum Guru
Forum Guru
Posts: 1922
Joined: Sun Feb 13, 2005 11:21 pm

Re: IEEE1588 PTPv2 support for CRS317

Tue Mar 10, 2020 10:35 am

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.
 
tmichaud
just joined
Posts: 7
Joined: Fri Oct 14, 2016 10:06 pm

Re: IEEE1588 PTPv2 support for CRS317

Tue Apr 07, 2020 8:26 pm

Any update on IEEE1588v2 support?
 
User avatar
daemontux
just joined
Posts: 4
Joined: Thu Dec 24, 2020 9:52 am
Location: Russsian

Re: IEEE1588 PTPv2 support for CRS317

Fri Dec 25, 2020 6:15 am

Most likely it is impossible to do this in software. It needs a dedicated ASIC and a crystal oscillator
 
pjinkcc
just joined
Posts: 12
Joined: Thu Aug 29, 2013 12:05 am

Re: IEEE1588 PTPv2 support for CRS317

Thu Jul 07, 2022 1:05 pm

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?
 
rounin
just joined
Posts: 20
Joined: Thu Mar 24, 2022 6:03 am

Re: IEEE1588 PTPv2 support for CRS317

Sat Jul 16, 2022 1:42 pm

(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.
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2541
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: IEEE1588 PTPv2 support for CRS317

Sat Jul 16, 2022 4:55 pm



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
 
rounin
just joined
Posts: 20
Joined: Thu Mar 24, 2022 6:03 am

Re: IEEE1588 PTPv2 support for CRS317

Sat Jul 16, 2022 9:00 pm

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.
 
pjinkcc
just joined
Posts: 12
Joined: Thu Aug 29, 2013 12:05 am

Re: IEEE1588 PTPv2 support for CRS317

Wed Jul 20, 2022 3:17 am



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.
 
mjezierski
newbie
Posts: 34
Joined: Mon Jul 01, 2019 3:50 pm
Location: Racing Capital of the World
Contact:

Re: IEEE1588 PTPv2 support for CRS317

Fri Sep 16, 2022 5:06 pm

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.
 
emunt6
newbie
Posts: 48
Joined: Fri Feb 02, 2018 7:00 pm

Re: IEEE1588 PTPv2 support for CRS317

Sat Dec 31, 2022 2:04 am

It is possible with extra SFP-modul:
> OSA 5401 - Small form-factor pluggable (SFP) GNSS receiver and PTP grandmaster clock.
 
mkx
Forum Guru
Forum Guru
Posts: 8926
Joined: Thu Mar 03, 2016 10:23 pm

Re: IEEE1588 PTPv2 support for CRS317

Sun Jan 08, 2023 2:10 pm

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

Who is online

Users browsing this forum: Largelos and 2 guests