BlueCat Connector Latency 1024 samples (Can I do better?)

[Scotty]

Quick Update: I decided to test the same network and audio cards using Cubase Pro 14.10 to Cubase Pro 14.10. I used a demo project and added Connector Instances with the goal of sending 4 stereo audio streams without audio compression.

I adjusted all parameters and methodically tested. I was able to get 4 stereo Cubase busses streaming audio at 44.1K and 48K to Cubase. The buffers had to be set to 1024 on each of the receiving the instances of Connector and the packet sizes of the sending Connectors had to be adjusted to 512 (auto wouldn't cut it) .

I sent the streams from the Cubase project from 3 stereo busses (drums, synths and pads) and the master bus. I streamed the song several times and at those settings 2 of the 4 passes came through without any drop outs. I did try all 6 audio compression settings but even the highest lossy setting produced dropouts on some of the passes.

With that being said, this isn't reliable enough for me to use in the context. It is fine for monitoring at lower latencies if I don't mind the drop outs. I do have a way to capture the material on the sending computer at the same time. It has application, but I can't get it to work in the way I had hoped.

I have two more powerful computers and I plan to do the same testing using the 1gb router and the same project files. One is the Ryzen 5950x and the other is the MacBook Pro M1. It is possible that my 56 core and 28 core Xeon X99 systems that I used thus far have too low clocks speeds to make this work optimally. Both computers easily pass LatencyMon suitabiliy tests. I am just guessing now because there isn't a lot to go by.

BlueCat hasn't indicated the testing parameters by which they reported their latency settings in the comments above. We don't know the number of audio streams they sent, nor the duration of the test and any details regarding the computers and their optimizations( if any) which they used.

I am motivated to do a proper Youtube video documenting my experience and testing process as there isn't much information out there. I want to find out what can reasonably be expected from the software and under what conditions. I am spending a lot of time testing and I still can't be sure if there is a problem or limitation specific to my machines or is this as good as it gets.

[audiojunkie]

I would suggest determining for sure whether the problem is with your machine or not first before documenting it on youtube. I agree that there isn't much information out there. That said, I wonder if some things can affect it. There was some talk on one of the Audiogridder threads I was reading that there is a feature in network cards and switches that affect latency. If the feature isn't available and used on each device, it can cause significant slowdowns. I'll look and see if I can find information about that again. That may be a key point that is needed.

[audiojunkie]

@Scotty -- What type of ethernet cable are you using?

[Scotty]

Cables: I am using new Cat 6 cables. I was using Cat 5e cables . Using Cat 6 cables showed no changes though and 5e is capable of 1 gbps. I swapped them to the CAT 6 to eliminate the possibility that the cables are bad or under performing. It made no difference.

Yes the purpose of any youtube video would to be show my experiences and methods and not to finger point or rant. There are useable applications for the software as it stands and I would highlight that. I am hoping the mainstream computers will respond better although my Xeon systems are using realtek drivers on an intel chipset. All other testing is showing I am getting the expected throughput. I'll reserve judgment until I have time to test the AMD and Apple system configuration using the same project files and methods. My approach is to ask questions and not reach a conclusion other than for myself. There are a lot of variables.

I would suggest determining for sure whether the problem is with your machine or not first before documenting it on youtube. I agree that there isn't much information out there. That said, I wonder if some things can affect it. There was some talk on one of the Audiogridder threads I was reading that there is a feature in network cards and switches that affect latency. If the feature isn't available and used on each device, it can cause significant slowdowns. I'll look and see if I can find information about that again. That may be a key point that is needed.

[Scotty]

One unfortunate aspect of the the demo version of the software is that it deliberately inserts silence as part of the demo restrictions. That makes it difficult for someone to know if the software is working well on their machines before buying it.

To be clear, I did purchase the software and all my comments pertain to the authorized / activated version.

[audiojunkie]

Have you tried any of these settings?

Disable Interrupt Moderation Rate
Disable Flow Control
Disable Offload TCP Segmentation
Increase Transmit Descriptors
Increase Receive Descriptors
Increase RSS Queues

[audiojunkie]

Also consider:

1)Jumbo Frame Size: Enabling Jumbo Frames can increase the size of data packets and reduce latency. Go to the Device Manager, select Ethernet adapter, right-click and select "Properties," then go to the "Advanced" tab, select "Jumbo Packet," and change the value to "9014" or "16128".

2)Energy Efficient Ethernet (EEE): Disabling EEE can reduce latency by disabling a feature that puts the Ethernet adapter into a low-power state when there is no network activity. Go to the Device Manager, select Ethernet adapter, right-click and select "Properties," then go to the "Advanced" tab, select "Energy Efficient Ethernet," and change the value to "Off/Disabled."

3)Interrupt Moderation: Disabling Interrupt Moderation can reduce latency by reducing the amount of time it takes to process network interrupts. Go to the Device Manager, select Ethernet adapter, right-click and select "Properties," then go to the "Advanced" tab, select "Interrupt Moderation," and change the value to "Disabled."

[audiojunkie]

Also, are you in store+forward or cut-through mode?

Switches forward traffic based on what MAC address that frame is going to. In "store and forward" mode they receive an entire frame, look up where to send it and then send it. In "cut through" mode they will start sending the frame out as soon as they have the MAC address, while they are still receiving the rest of the frame on a different port. Cut through has lower latency than store and forward.

Note: cut-through only works when going from same speed interface. if the switch passes to a slower port anywhere store and foreward is used anyways.

--------------------------------

More bandwidth doesn't speed up processing of frames or the speed of light.

Most of the latency in close proximity LAN environments is switch processing time. You can short cut this by using switches that support cut-through forwarding. This reads the bear minimum of the frame header and begins forwarding the frame out before it's finished receiving it.

Most switches by default run in store and forward mode. Which buffers the whole thing before forwarding it on.

[audiojunkie]

Also consider connecting the two NICs directly to each other and bypassing the switch.

[audiojunkie]

I've been reading all day. I just discovered a relatively new, open technology that may be exactly what we are looking for. AVB/TSN. Most commonly known as simply TSN (Time Sensitive Networking) these days. TSN is a set of standards that enhance the ethernet specification. It is part of IEEE 802.1. Network switches and network interface cards, when all support TSN, provide transmission with very low latency and high availability. Applications include converged networks with real-time audio/video streaming and real-time control streams which are used in automotive applications and industrial control facilities.

I'm willing to bet that with a TSN switch and a TSN NIC, along with Blue Cat Audio's connector and/or Patchworks plugins, you could do really well! Supposedly, the speed is around 2ms.

[audiojunkie]

Here is some more information:

What is the difference between a TSN switch and an Ultra Low Latency switch?

A "TSN switch" specifically refers to a network switch that supports the Time-Sensitive Networking (TSN) standard, meaning it is designed to guarantee extremely low latency and deterministic data delivery for time-critical applications, while an "ultra low latency switch" is a broader term describing any switch optimized for minimal delay, with TSN being one way to achieve that level of performance; essentially, a TSN switch is a type of ultra low latency switch with added features to ensure precise timing and reliable data transmission in real-time scenarios.

Key points to remember:

TSN standard:
A TSN switch adheres to the IEEE 802.1 TSN standards, which include mechanisms like time-aware scheduling and frame preemption to prioritize critical data and minimize latency.

Beyond low latency:
While an ultra low latency switch focuses primarily on minimizing delay, a TSN switch additionally guarantees consistent and predictable data delivery with minimal jitter, crucial for applications requiring strict timing constraints.

Application areas:
TSN switches are typically used in industrial automation, robotics, medical devices, and other scenarios where precise timing is critical, while a general "ultra low latency switch" could be used in applications like high-frequency trading or real-time gaming where fast response times are key.

----------

What is the difference between a gaming switch and an Ultra Low Latency switch?

A "gaming switch" generally refers to any network switch designed to prioritize low latency for smooth gaming experiences, while an "ultra low latency switch" is a more specific term indicating a switch optimized to achieve the absolute lowest possible latency, often used in scenarios where even the slightest delay is critical, like high-frequency trading or real-time simulations, exceeding the typical performance of a standard gaming switch.

Key points to remember:

Focus:
A gaming switch prioritizes low latency for gaming needs, while an ultra low latency switch aims for the absolute lowest delay possible, often going beyond what's necessary for typical gaming.

Application:
Gaming switches are commonly used for home gaming setups, while ultra low latency switches are often found in specialized environments like data centers or high-performance trading systems.

Latency level:
While both prioritize low latency, an ultra low latency switch will generally boast significantly lower latency figures compared to a gaming switch.

[audiojunkie]

So, there is a hierarchy for switches and NICs in order of what is good for our usages as far as I can tell:

Fair: Normal Switch and NIC
Good: Gaming Switch and NIC
Great: Ultra Low Latency Switch and NIC
Excellent: TSN Switch and NIC

In other words, your network speed and latency is only going to be as good as your hardware.

[Scotty]

I am reading though all of your posts and I will look into all of the suggestions you've made. Some of the optimizations I have already tried. I did attempt the nic to nic connection but I couldn't get the Connectors to discover each other. I was under the understanding that you can use a basic ethernet cable like an Cat 5e or Cat 6 but perhaps you need a crossover cable to do this?

[Scotty]

The only reasonable option in that list is the FAIR or GOOD category. TSN Nics and Swiches and Ultra Low Latency Nics and Switches are very expensive. If we want audio over ethernet and have that kind of budget then we're looking at Dante.

[audiojunkie]

I am reading though all of your posts and I will look into all of the suggestions you've made. Some of the optimizations I have already tried. I did attempt the nic to nic connection but I couldn't get the Connectors to discover each other. I was under the understanding that you can use a basic ethernet cable like an Cat 5e or Cat 6 but perhaps you need a crossover cable to do this?

Yes, try a crossover cable!