I’m trying to transport Dante audio through a VPLS tunnel. Setup:
The two RB2011s are running RouterOS 6.45.5. Dante Endpoints are AVIO input and outputs, based on the Ultimo chipset. Audio is routed as unicast, only the Dante control and PtPv1 clocking are multicast.
There is a direct (gigabit ethernet) connection between the two RB2011s.
In Dante controller I see that the network latency is usually around 2 miliseconds, but occasionally spikes to over 100ms. This results in a slight drop of audio. Dante controller reports no out of sync issues, the output device is clock master.
Bandwidth is 3-4Mbit/sec.
The VPLS tunnel is setup based on the guidelines in the following article: https://wiki.mikrotik.com/wiki/Transparently_Bridge_two_Networks_using_MPLS
I started this config out of a freshly resetted router, but created a separate bridge where the VPLS tunnel interface and ethernet ports to the Dante devices are in.
Does anyone have any ideas what is causing the occasional hickup in the network?
I’ve been doing more investigation into this topic.
I expanded the bridge on the first 2011 with an extra ETH port, and connected the Dante TX, RX and controller all to the same routerboard.
With this simple configuration, there is still the occasional latency issue.
It seems that the VPLS tunnel isn’t the cause of the latency, but the bridging in the Routerboard.
Why VPLS? From your network topology and addressing I can’t see any benefit in using it?
For your needs, what I would setup instead is a simple bridged network, making sure the ports are setup in an optimal way:
1.- Lay out ports on that will be communicating the most on the same switch chip. RB2011 has two switch chips. One comprises ether1-5 and SFP and the other ether6-10.
From your diagram, I’d link the two 2011’s using ether7, or ether10, so that they’re linked by ports on same switch chip where ports communicate with AVIO input/output.
This way, RB2011 CPU won’t be used when traffic is flowing between ports on same switch chip. Otherwise, RB2011 CPU will be used with traffic from switch chip 1 ↔ switch chip 2.
Thanks for your reply.
Why VPLS? Well, for educational purposes. Due to the current corona-situation I’m locked at home with some equipment, and I’m willing to learn more about it.
Final plan would be trying to transport Dante over the wireless point-to-point links I use quite often. (I have SXTsq 5 ac devices for that). My thoughts would be setting up 2 pairs of point-point links, using OSPF to create a semi-full-duplex setup, and then transport the Dante over it encapsulated in VPLS.
I know that it behaves perfectly fine in a hardware-based L2 setup, but I was already trying to get one step closer to the final desired setup.
Well. Pro-audio is very sensitive to latency and jitter. Often switches with PtP/IEEE1588 is used to maintain syncronization.
VPLS on RouterOS is done in CPU (as in software) hence it will introduce some latency and jitter, especially under load. It’s probably not an issue for regular VoIP or SIP.
Unlike protocols like AES67 or AVB, PtP v2 is not used by Dante. Dante uses PtP v1, which does not require any special timestamping hardware in the switch.
The only thing that Dante requires is QOS (diffserv) with strict priority in at least 4 queues. I suppose this mechanism is not supported on software bridges in Mikrotik routers?
While MPLS/VPLS (L2.5) can provide a performance between pure switching and L3, as mada3k pointed CPU is still used.
My advice is using a more modern RB with more CPU power, HeX/PowerBox family could be great candidates.
Tips:
Leave the wireless PTP links in L2, do MPLS from routers only.
Try nstreme on PTPs. nstreme provided consistently the lowest latency and jitter in my tests in the past, (at the cost of bandwidth where nv2 wins). framer-policy=none usually provides the best and most consistent latency.
If the links won’t be shared for other uses, start w/o QoS. If they will be, use HTB to priorize traffic accordingly at the routers.
When you are planning to use wireless, you should be prepared for jitter figures like that. When a wireless packet is lost due to interference, it is re-transmitted and this takes time, making 100ms jitter quite typical on a wireless link.
I did some work on synchronized audio over UDP (not using any of those standards) and in my implementation I have a feedback loop that adjust the amount of buffering depending on the measured peak latency.
In my implementation all systems are time-synchronized to a GPSDO (1PPS signal controls the system time via chrony) and each packet contains a 100ns-resolution timestamp which is compared to current time on the receiver, the calculated propagation time is averaged in a fast-attack slow-decay manner, a safety margin is added, and the resulting total latency is used to calculate the buffer length.
This copes quite well with links that have varying latency with occasional spikes, but of course when the latency spikes are rare and long, there still are cases where a packet arrives too late.
Thanks for the suggestion, those HeX devices surely pack a lot of processing power for an amazing price! Just ordered two, and a mAP, because it looks cute
I just want to let you guys know it works brilliantly using hEX routers! I’m transporting Dante over a 50m wireless point point link made of 4 SXT SQ5 ACs, using OSPF for redundancy. On each side is a hEX that does the OSPF and VPLS encapsulation.
ToDo: find a bigger garden to try longer distances.
