Managed switch...best settings for optimal performance?

[plissken]

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

 

Properly implemented jumbo frames reduce the CPU over head of managing packet streams and shouldn't affect playback.

 

I run 9K frames with zero issue on my network. Windowing would take care of the rest as adapters should agree upon a frame size.

 

My wireless runs on the typical 1.5K frame BTW.

[plissken]

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

[ATTACH=CONFIG]29510[/ATTACH]

 

Are you showing me network related issues or Transcode issues? They aren't the same thing and transcoding doesn't apply to the context of buffering as spoken about in this thread.

[occamsrazor]

Properly implemented jumbo frames reduce the CPU over head of managing packet streams and shouldn't affect playback..

 

The difficulty in implementing Jumbo frames, if I remember correctly, is EVERY device on your network needs to support it, which I have always found difficult to do with some devices not supporting it.

[tboooe]

The difficulty in implementing Jumbo frames, if I remember correctly, is EVERY device on your network needs to support it, which I have always found difficult to do with some devices not supporting it.

In my case, all my hardware supports Jumbo but for some reason Roon did not like it at all. It would either not connect to my NAS or have a very hard time playing music. I am not sure why.

[plissken]

The difficulty in implementing Jumbo frames, if I remember correctly, is EVERY device on your network needs to support it, which I have always found difficult to do with some devices not supporting it.

 

You should have everything at the same size. Many shades of gray though. If you are using really good NIC and switch hardware the CPU's on these devices do all the heavy lifting anyways so jumbo frames may not net you anything on the computer CPU side of things.

 

For a home environment not a problem. My main LAN is 9K frames, the NAS is multi-homed, the 2.0 is on it's own VLAN and wireless with standard 1500 MTU.

[The Computer Audiophile]

You should have everything at the same size. Many shades of gray though. If you are using really good NIC and switch hardware the CPU's on these devices do all the heavy lifting anyways so jumbo frames may not net you anything on the computer CPU side of things.

 

For a home environment not a problem. My main LAN is 9K frames, the NAS is multi-homed, the 2.0 is on it's own VLAN and wireless with standard 1500 MTU.

Wouldn't it make sense to do the heavy lifting on machines / CPUs with the most horsepower?

 

I'm still doubtful that jumbo frames would make any positive difference in an audio / home network.

[plissken]

Wouldn't it make sense to do the heavy lifting on machines / CPUs with the most horsepower?

 

I'm still doubtful that jumbo frames would make any positive difference in an audio / home network.

 

Nope, let the NIC's and their silicon do all that. It's what they are intended to do. CPU's should be processing application and user requests.

 

Now with NIC's supporting RDMA, CPU's have a reduced need for performing memory management tasks. NIC's can setup Remote DMA and Xfer data into and out of RAM between machines over the network without getting the CPU involved.

 

It's a ZERO copy stack! No buffering.

 

No, I don't think you need Jumbo Frames on modern home networks. I have it implemented because I know how and it's a cakewalk for me.

[The Computer Audiophile]

Nope, let the NIC's and their silicon do all that. It's what they are intended to do. CPU's should be processing application and user requests.

 

Now with NIC's supporting RDMA, CPU's have a reduced need for performing memory management tasks. NIC's can setup Remote DMA and Xfer data into and out of RAM between machines over the network without getting the CPU involved.

 

It's a ZERO copy stack! No buffering.

 

No, I don't think you need Jumbo Frames on modern home networks. I have it implemented because I know how and it's a cakewalk for me.

OK cool. Thanks for the response.

[plissken]

OK cool. Thanks for the response.

 

It's why I don't get wrapped around specialty USB cables or USB cards with Femto clocks. The DAC's job is to cleanly extract data.

 

If I had a NIC that choke on doing the off load that it's supposed to be doing you have a poorly designed NIC. Get something else and stop throwing power supplies, esoteric cables, magic pebbles at it.

[plissken]

One thing Jumbo frames helps with is diagnostics. Basically you have 600% less packets to analyze and wade through.

[jabbr]

I think jumbo frames as well as the vast majority of features of managed switches, are not necessary in the typical home audio network

 

Perhaps playing back 4K video streams or editing video but there I go for 10g -- since we seem to have a number of photographers here [emoji6]

[lmitche]

While counterintuitive, I found disabling the NIC offload functions on my playerPC has increased sound quality. The only exception is for the IP checksum. Otherwise everything is disabled, including flow control.

 

As my playerPC boots from ISCSI, performance is important. With everything disabled the ISCSI boot drive performance tests at the full capacity of the 1gb connection. Music is stored on the same NAS and is served over a SMB connection. Roon and HQplayer work beautifully with upsampling to DSD512. The DAC is directly connected via USB so I do not run an NAA machine.

 

My NAS has two copper NICs so I use a virtual switch rather then a physical switch. One less power supply is a good thing.

[r_w]

I'm also using 9k frames, with no negative issues.

 

 

Properly implemented jumbo frames reduce the CPU over head of managing packet streams and shouldn't affect playback.

 

I run 9K frames with zero issue on my network. Windowing would take care of the rest as adapters should agree upon a frame size.

 

My wireless runs on the typical 1.5K frame BTW.