Managed switch...best settings for optimal performance?

[gregs1104]

I found this presentation by Audinate that explains really well some of the advanced features my managed switch has. I started messing around with QoS yesterday a bit to ensure priority is given to certain data streams. I am not sure if it makes a difference but its good piece of mind for me to know I am optimizing as much of my audio chain as I can.

 

QoS and features like VLANs add extra processing complexity and latency inside of the switch's internal processing logic. If you must have those things to keep network congestion under control, they're a miracle. When you don't need them, you can just as easily detune your system when you turn them on. That's why the Dante guys say not to use QoS on small systems.

 

I think a chunk of the audiophile community that's chasing after low latency is staring at half of the problem. When audio is flowing over a packet based network, latency by itself doesn't mean anything. 1ms, 10ms, as long as it's a constant number everything will be received with the same timing as it was transmitted. The problem that impacts audio is variation in latency. That's usually correlated with total latency, but they're not guaranteed to line up. You can have a low latency magnitude but a lot of latency variation; that's technically a worse switch for audio than a high latency one with low latency variation.

 

The advanced features like QoS and VLANs all drive latency variation up because now the switch has more decisions to make, and that means more code paths with different lengths to each one. The ideal switch for audio takes exactly the same amount of time to deliver every packet because there are no decisions to be made.

[plissken]

QoS and features like VLANs add extra processing complexity and latency inside of the switch's internal processing logic. If you must have those things to keep network congestion under control, they're a miracle. When you don't need them, you can just as easily detune your system when you turn them on. That's why the Dante guys say not to use QoS on small systems.

 

I think a chunk of the audiophile community that's chasing after low latency is staring at half of the problem. When audio is flowing over a packet based network, latency by itself doesn't mean anything. 1ms, 10ms, as long as it's a constant number everything will be received with the same timing as it was transmitted. The problem that impacts audio is variation in latency. That's usually correlated with total latency, but they're not guaranteed to line up. You can have a low latency magnitude but a lot of latency variation; that's technically a worse switch for audio than a high latency one with low latency variation.

 

The advanced features like QoS and VLANs all drive latency variation up because now the switch has more decisions to make, and that means more code paths with different lengths to each one. The ideal switch for audio takes exactly the same amount of time to deliver every packet because there are no decisions to be made.

 

Actually VLAN's are used to improve performance of the switch fabric and any internal logic is actually based on a simple subnet mask and traffic is simply not sent to the VLAN because it represents a broadcast boundary.

 

So VLAN's in a nutshell improve performance along broadcast domains.

 

Switches work on CAM and two separate VLANs will have their own CAM tables.

 

Besides we are talking about re-production and not production. These terms represent unique implementation best practices with re-production really needing no special treatment on a home network for 99% of use cases.

 

Audinate's documentation makes sense for production environments but isn't applicable to simple playback.

[plissken]

I think a chunk of the audiophile community that's chasing after low latency is staring at half of the problem. When audio is flowing over a packet based network, latency by itself doesn't mean anything. 1ms, 10ms, as long as it's a constant number everything will be received with the same timing as it was transmitted.

 

Most audiophiles have zero idea what they are reading and then parroting. There is NO timing over IEEE 802.1X Ethernet. There is NO clock on Ethernet. It's asynch.

 

As long as the playback buffer is fed and not under-run, latency could be 1ms then 100, then 1000, then back to 1ms and constantly do this as long as the buffer never empties out.

 

The application will have no idea that this is going on the network side of stuff. Non-real time protocols are buffered ecosystems.

[craighartley]

Error ]. Just Vlan it,.

 

'Just VLAN it...'

 

How?

[occamsrazor]

I ended up buying 3 GS108T switches around 2011 or 2012 because they were one of the cheapest management switches around, and I was already a long time user of their unmanaged switches. They have been very hit or miss for me. Never had any issues on the performance, they've always been fast and easy to manage when they're working.

 

Just to say I have a couple GS108Tv2 switches in my home network, as well as a GS110TP that is my main switch used with both copper and fiber ethernet. Both have been rock-solid and i wouldn't hesitate to recommend them.

[plissken]

'Just VLAN it...'

 

How?

 

Read the documentation that came with your switch. The commands or UI for a switch are going to vary from manufacturer to manufacturer.

 

What you need to take away from the thread is that you most likely don't need to do any of this for simple music play back.

[The Computer Audiophile]

Read the documentation that came with your switch.

said like only someone with the proper skills can say :~)

[gregs1104]

As long as the playback buffer is fed and not under-run, latency could be 1ms then 100, then 1000, then back to 1ms and constantly do this as long as the buffer never empties out.

 

That's the theory. If you actually test it, when the buffer empties significantly the catch-up work puts some extra strain you can measure on the CPU and on memory. And the application will feel that disruption in the timing sensitive part that's feeding data to a DAC. (I work on latency instrumentation for database engines, there a big CPU/disk monster called a checkpoint is a regular source for "playback" threads starving)

 

Now, I'm with you that this shouldn't ever become actually audible in the trivial cases. But I'm the kind of skeptic who is skeptical of the other skeptics. There's a real cause and effect here that I know exists in this type of network application. There are reports that it's audible. If that's wrong, I want to squeeze the claims on all sides until the truth pops out.

[plissken]

said like only someone with the proper skills can say :~)

 

Anyone else is welcome to come in and help him. If it was a Cisco or HP switch I could simply post an example configuration. I don't know how his switch implements VLAN's.

 

I also ended the post with stating that it's pretty much not needed on home network because it isn't. But that part wasn't paid attention to or read.

[The Computer Audiophile]

Anyone else is welcome to come in and help him. If it was a Cisco or HP switch I could simply post an example configuration. I don't know how his switch implements VLAN's.

 

I also ended the post with stating that it's pretty much not needed on home network because it isn't. But that part wasn't paid attention to or read.

Said like only someone who thinks they know everything can say :~)

 

Of course I read your entire post and paid attention to it. I also agree with you. Perhaps you missed my smiley face at the end? :~)

[plissken]

That's the theory. If you actually test it, when the buffer empties significantly the catch-up work puts some extra strain you can measure on the CPU and on memory. And the application will feel that disruption in the timing sensitive part that's feeding data to a DAC. (I work on latency instrumentation for database engines, there a big CPU/disk monster called a checkpoint is a regular source for "playback" threads starving)

 

Now, I'm with you that this shouldn't ever become actually audible in the trivial cases. But I'm the kind of skeptic who is skeptical of the other skeptics. There's a real cause and effect here that I know exists in this type of network application. There are reports that it's audible. If that's wrong, I want to squeeze the claims on all sides until the truth pops out.

 

I understand this but we aren't talking data center. I don't apply typical data intensive business environments to home networking applications.

 

While SQL implementations can be very multi-threaded we are talking 1411 Kbps data for most users and even if we talk about 9000Kbps 24/192 it's still trivial for modern CPU's. All anyone need to is fire up Perfmon on their Server and Playback computers and we can setup another thread for what performance counters to consider using to see how low the utilization is actually going to be.

 

I'm willing to listen to actual evidence to the contrary but yet to see it.

[plissken]

Said like only someone who thinks they know everything can say :~)

 

Of course I read your entire post and paid attention to it. I also agree with you. Perhaps you missed my smiley face at the end? :~)

 

I guess I'm not getting the context of your post. I don't know everything but I teach the CCNA and CCNP courses for side money.

[The Computer Audiophile]

I guess I'm not getting the context of your post. I don't know everything but I teach the CCNA and CCNP courses for side money.

I'm trying to joke with you more than anything.

 

I agree that almost nobody needs a very custom config of a managed switch on their home network.

[craighartley]

Anyone else is welcome to come in and help him. If it was a Cisco or HP switch I could simply post an example configuration. I don't know how his switch implements VLAN's.

 

I also ended the post with stating that it's pretty much not needed on home network because it isn't. But that part wasn't paid attention to or read.

 

The TP-LINK documentation mentions 3 types of VLAN, by which point I'm already lost.

 

http://static.tp-link.com/res/down/doc/Easy_Smart_Configuration_Utility_UG.pdf

 

Saying something is 'most likely' or 'pretty much' not needed may be true but does not help anyone decide whether it is needed in their specific case.

[plissken]

The TP-LINK documentation mentions 3 types of VLAN, by which point I'm already lost.

 

http://static.tp-link.com/res/down/doc/Easy_Smart_Configuration_Utility_UG.pdf

 

Saying something is 'most likely' or 'pretty much' not needed may be true but does not help anyone decide whether it is needed in their specific case.

 

What is your specific case then? What symptoms are you experiencing? Do they lead you to believe they are addressable at layer 3?

[jabbr]

Haha, look if you read my sig you'll see that I have more vlan capabilities at home that you care to imagine, and that's only a fraction of my equipment (40gb switches etc) -- in any case there is very little to zero need to fool with vlans at home -- moreover good NICs can communicate with switches with very little CPU overhead -- my Xeon gets its cache stuffed by the card directly, for example (DDIO data direct I/O) -- in any case 99.9% of the people here don't need to do any advanced configuration -- and if you do, you know that [emoji6]

[plissken]

The TP-LINK documentation mentions 3 types of VLAN, by which point I'm already lost.

 

If you are going to setup a VLAN then you will do port based.

 

The TP Link manual is the typical, technically correct answer, on the various VLAN types but does the typically poor job of explaining it.

 

MTU Vlans are this: When you have a large switch fabric that hosts multiple, unrelated, private business networks. Where you need VLans to control broadcast boundaries, make use of provided IPV4 numbers in an efficient manner, but still keep each businesses traffic private from each other. That is the issue that MTU Vlans solve.

 

The Tagged VLAN's are needed when you need VLAN information as part of the Ethernet Frame. It's an extension to Port VLAN's.

 

I didn't look but you will want to see if your TPLink does intervlan routing.

[plissken]

Haha, look if you read my sig you'll see that I have more vlan capabilities at home that you care to imagine, and that's only a fraction of my equipment (40gb switches etc) -- in any case there is very little to zero need to fool with vlans at home -- moreover good NICs can communicate with switches with very little CPU overhead -- my Xeon gets its cache stuffed by the card directly, for example (DDIO data direct I/O) -- in any case 99.9% of the people here don't need to do any advanced configuration -- and if you do, you know that [emoji6]

 

We setup 80GB of RDMA linkage to our iSCI cluster. It cut CPU utilization by a factor of 4. Awesome stuff.

[The Computer Audiophile]

Hi @plissken - What's your take on jumbo frames in an home audio environment? Keep in mind that the maximum data rate many people use at home is 22.5Mbps (quad DSD / DSD256) and some people will be increasing that as they resample to DSD512 with HQPlayer and NAA.

 

In my experience, jumbo frames hasn't made a difference that I care about and can actually cause more issues than it "solves."

[craighartley]

If you are going to setup a VLAN then you will do port based.

 

The TP Link manual is the typical, technically correct answer, on the various VLAN types but does the typically poor job of explaining it.

 

MTU Vlans are this: When you have a large switch fabric that hosts multiple, unrelated, private business networks. Where you need VLans to control broadcast boundaries, make use of provided IPV4 numbers in an efficient manner, but still keep each businesses traffic private from each other. That is the issue that MTU Vlans solve.

 

The Tagged VLAN's are needed when you need VLAN information as part of the Ethernet Frame. It's an extension to Port VLAN's.

 

I didn't look but you will want to see if your TPLink does intervlan routing.

 

Thanks very much for explaining that. I'm pretty sure I don't need VLAN. But I get some stuttering when my Mac Pro upsampled to DSD 512 in HQPLayer, and Miska suggested at one point that it may be a network issue. So I simply want to understand if there is a way I can do anything that improves the network. I abandoned the managed switch recently because I thought I was doing more good than harm. But then I read in this thread that the best plan would be a managed switch with the default settings. However, I can't deduce what the default settings should be in all cases,nor whether the switch is actually implementing many of its unnecessary functions, without me knowing it. Which is pretty much how this thread started.

[Jud]

Craig: Dead simple way to tell if your occasional stutter is network based is to connect your DAC directly to the computer running HQP if you can, using all the same settings (other than NAA and/or Roon of course) and see whether the stutter still occurs.

[The Computer Audiophile]

@craighartley - What device is your NAA endpoint?

[gregs1104]

we are talking 1411 Kbps data for most users and even if we talk about 9000Kbps 24/192 it's still trivial for modern CPU's. All anyone need to is fire up Perfmon on their Server and Playback computers and we can setup another thread for what performance counters to consider using to see how low the utilization is actually going to be.

 

Yes. I've done that. Every comment I've made was with the entirety of that context. I only mentioned the SQL stuff I do to explain for why I know all the tools for Linux to look at the problem. I'm also using Linux for playback.

 

This week I'm playing on the i3-6100U of my Gigabyte NUC-clone with Jriver MC21 on Ubuntu 16.04. Right now I'm seeing about 13% CPU usage decoding 24/192 files. I'm also transcoding single rate DSD files to send to the DAC at 24/96. That spikes CPU usage to about 33%. (Note that the latest MC22 from them switches to the SOX library for upsampling, so these numbers aren't reflective of the current generation product)

 

The numbers aren't high enough that I'm personally worried about network overhead, but I wouldn't call them trivial either; only 16/44.1 playback is trivial. With some people using Raspberry Pi systems for playback and others trying to do double rate or higher DSD, they're easily going to hit CPU levels where memory and CPU cache contention becomes an issue. I personally am heading toward real-time speaker correction at 24/96, and one reason I dug into this is to handicap the odds I will be able to do it with just this mini i3-6100U system.

 

Here's a picture of the DSD transcoding example to show I'm not just pulling numbers out of the air here. (My computers are named after favorite albums with neat covers, this one's inspired by "Time Loves a Hero")

[craighartley]

@craighartley - What device is your NAA endpoint?

 

One of these with Windows 10 Pro.

[craighartley]

Craig: Dead simple way to tell if your occasional stutter is network based is to connect your DAC directly to the computer running HQP if you can, using all the same settings (other than NAA and/or Roon of course) and see whether the stutter still occurs.

 

Thanks Jud. Yes I should try that again; I haven't tried it since changing DAC and NAA. Takes a bit of furniture moving though....