Jump to content

Wanting to put audio on a separate subnet and use jumbo frames to improve SQ


Recommended Posts

1 hour ago, davewantsmoore said:
Quote

but did not work through roon but I could still connect by their window "name" .

I don't understand what you mean

Errrm, I was able to get access if I used the hostname but not using the IP address

 

1 hour ago, davewantsmoore said:

What didn't work

Even though I could access through the host name, roon was not able to find it

 

1 hour ago, davewantsmoore said:

If you manually assigned IPs to the computers, then releasing and renewing does nothing

Yes, am sure u r right but even after removing the subnet and the mac binding it didnt come back till next day ie automatic , even though I released renewed after I set it back. In the end may be  a moot point as essentially there is only one LAN port in use and every thing hangs off it. 

My next plan is to try a switch ? Router? down the end of the line where the audio stuff is. Haven't had time yet.....

 

 

Link to comment
Share on other sites



Start easy with the second subnet - create it, run DHCP, attach something that accept pings. Then try ping it from your other subnet.

 

This will give you some idea of it routing through correctly.

Link to comment
Share on other sites

19 hours ago, frednork said:

My next plan is to try a switch ? Router?

If you have two seperate networks .... then the only way they can communicate with each other is if a router passes traffic between them.    You only want to have one router.

 

If you want two seperate networks to travel down one single cable .... then you need to use "VLAN".    Typically you would connect a switch (that supports VLANs) to the end of the cable .... and then all the devices to the switch.

 

 

My suggestion is similar to Ric.    Setup the two subnets using the interface grouping of your router.   This will mean that everything (I understand including somethings you don't want) down the "far end of the house" are now on the new network....  That will have to do you for now.

 

Set it up with DHCP or manually assigned addresses, whatever.

 

Now, see what is working (or not).   You will need to methodically troubleshoot things.    eg. can the IPs on the "audio" network ping each other?   Can they ping IPs on the other network?.... can they get to the internet .... etc. etc.

 

Once you have that all working.    ie. everything can talk to everything  (there might be a number of issues to resolve, before it does) ..... then you can proceed to the next part, which is advertise BOTH networks down the cable to the far end of the house, and have your switch decode the VLAN IDs.

 

I don't know if/how Roon remotes/clients will behave like this ..... if it relies on "broadcast" to find each other ... then it won't work.  You may have to manually tell clients about the server, etc.

 

 

If you engage a professional you want.

 

Two LAN subnets configured on the router

VLAN configured on the router and switch

A "trunk" setup between the router and switch

Specific ports on the switch configured to be one (or the other) LAN

 

This should allow everything to work .... except for anything in one network which relies on "broastcast" to find things (which are in the other network).   That will need to be setup manually.     ie. on your ipad (or whenever) in the "not audio" network, it won't magically find your Roon player.   You'll need to tell the ipad about the roon device..

 

 

 

 

 

 

Link to comment
Share on other sites

4 hours ago, davewantsmoore said:

If you have two seperate networks .... then the only way they can communicate with each other is if a router passes traffic between them.    You only want to have one router.

 

If you want two seperate networks to travel down one single cable .... then you need to use "VLAN".    Typically you would connect a switch (that supports VLANs) to the end of the cable .... and then all the devices to the switch.

 

 

My suggestion is similar to Ric.    Setup the two subnets using the interface grouping of your router.   This will mean that everything (I understand including somethings you don't want) down the "far end of the house" are now on the new network....  That will have to do you for now.

 

Set it up with DHCP or manually assigned addresses, whatever.

 

Now, see what is working (or not).   You will need to methodically troubleshoot things.    eg. can the IPs on the "audio" network ping each other?   Can they ping IPs on the other network?.... can they get to the internet .... etc. etc.

 

Once you have that all working.    ie. everything can talk to everything  (there might be a number of issues to resolve, before it does) ..... then you can proceed to the next part, which is advertise BOTH networks down the cable to the far end of the house, and have your switch decode the VLAN IDs.

 

I don't know if/how Roon remotes/clients will behave like this ..... if it relies on "broadcast" to find each other ... then it won't work.  You may have to manually tell clients about the server, etc.

 

 

If you engage a professional you want.

 

Two LAN subnets configured on the router

VLAN configured on the router and switch

A "trunk" setup between the router and switch

Specific ports on the switch configured to be one (or the other) LAN

 

This should allow everything to work .... except for anything in one network which relies on "broastcast" to find things (which are in the other network).   That will need to be setup manually.     ie. on your ipad (or whenever) in the "not audio" network, it won't magically find your Roon player.   You'll need to tell the ipad about the roon device..

 

+1 this

 

Though being able to receive broadcast may in part defeat the point of what you're trying to achieve (it's extra traffic, albeit small). 

 

Step 1 IMHO - see if you can just get comms across the network. DHCP to start on each subnet, connect two PCs, let 'em ping each other and say hello. No echo, no bueno, and then you address why it's not routing. Pings should be 1ms or so for wired comms. Any additional thinking time and I'd be suspicious of what's goin' on.

 

Consumer-grade routers make this a bit tough - a prosumer/pro router doesn't cost anymore (and sometimes less) but lets you set things just so (steeper learning curve tho). 

 

You could use a separate router a the audio end of things. It's not elegant but it will work. VLANs are elegant, and you rely on the switch to rip out what's not required on a per-subnet basis. 

 

If you're not comfortable configuring the switch also, I'd just use a separate router. 

Link to comment
Share on other sites

On 21/11/2019 at 5:11 PM, rmpfyf said:

Though being able to receive broadcast may in part defeat the point of what you're trying to achieve (it's extra traffic, albeit small). 

Sorry, I wasn't implying to "setup BROADCAST manually" (ie. with some sort of "directed-boradcast" setting in the router/switch) ..... because that would begin to defeat the purpose.

 

What I mean was that connections between the devices which would normally find each other automagically, would need to be setup manually....  ie. don't expect all your devices on separate networks to be able to "just discover" each other.

 

 

Link to comment
Share on other sites



Hi again, I attempted to do your bidding but ended up not getting very far and then broke the second switch and bricked it. Have now reset and all is back to normal. 

 

Would you guys consider walking me through the steps in super simple fashion. doesnt have to happen too quickly. A few others have mentioned to me they would like to do the same but dont know how so should help more than me. Maybe the equipment is not suitable or whatever but would be good to get to the bottom of it.

Link to comment
Share on other sites

On a local 1GB LAN this is all a colossal waste of time and will only give you a headache to deal with down the track.

 

OP are you actually addressing an issue, or do you want to do this because 'you've heard it will improve SQ?"

 

Certainly, QOS for slower links, VLAN's for segregation of chatty devices and security - but neither are likely to exist on a home network. On a modern decent-quality switch that's working properly, sending the piffy amount of traffic that audio uses does not require this sort of a headache.

 

In fact creating a subnet will likely introduce performance issues, as your poor cheap router now needs to contend with routing traffic as opposed to your switch simply switching it about.  Your little layer-2 switch can bang traffic around your network a lot faster than your cheap internet router can.

Link to comment
Share on other sites

12 hours ago, frednork said:

Hi again, I attempted to do your bidding but ended up not getting very far and then broke the second switch and bricked it. Have now reset and all is back to normal. 

 

Would you guys consider walking me through the steps in super simple fashion. doesnt have to happen too quickly. A few others have mentioned to me they would like to do the same but dont know how so should help more than me. Maybe the equipment is not suitable or whatever but would be good to get to the bottom of it.

 

A big part of getting it working, will be trying things, getting it "half working" and then actively troubleshooting it to see exactly what is wrong.... but to actually tell you what to do (or if indeed your devices will play ball with VLANs) I'd need to go through the manuals, etc.

 

Do you have a spare computer that you can connect via Ethernet cable directly to the router?    If you do, then what we could begin with is getting that computer setup on a new subnet (on it's own) .... and then getting the router configure to route between the two subnets.    That way, for the time (could be a looong time) that it's not working, then the only thing in your house which doesn't work right is the computer that you've directly plugged into the router to test this out.

 

Once you have the multiple subnets routing correctly.... then it will be a quick/safe change to do it for an audio subnet.... and then move onto troubleshooting how to get apps working when the client and server are on different networks.

Link to comment
Share on other sites

34 minutes ago, TDK said:

On a local 1GB LAN this is all a colossal waste of time and will only give you a headache to deal with down the track.

 

OP are you actually addressing an issue, or do you want to do this because 'you've heard it will improve SQ?"

 

Certainly, QOS for slower links, VLAN's for segregation of chatty devices and security - but neither are likely to exist on a home network. On a modern decent-quality switch that's working properly, sending the piffy amount of traffic that audio uses does not require this sort of a headache.

 

In fact creating a subnet will likely introduce performance issues, as your poor cheap router now needs to contend with routing traffic as opposed to your switch simply switching it about.  Your little layer-2 switch can bang traffic around your network a lot faster than your cheap internet router can.

 

Really depends what router's being used here. A decent router needn't be expensive, it just won't be a consumer-grade product.

 

Can certainly be worth it.

Link to comment
Share on other sites

Just now, rmpfyf said:

 

Really depends what router's being used here. A decent router needn't be expensive, it just won't be a consumer-grade product.

 

Can certainly be worth it.

 

A switch will pound a router to death in the throughput performance stakes, unless you've got a very expensive one (router). If the OP wants some better performance on his LAN, then chances are putting more money into a decent switch will make it happen. Cheap switches, even though they state 1Gbps will fall over very quickly if they are smashed on too many concurrent ports.

 

Keep the setup simple, it's really not needed on a home network. Remember with Ethernet you have the whole collision detection / resend thing going on. 

 

Of course I won't dare argue the whole audiophile thing (that a packet resend introduces noise etc), that would be foolish of me. However what I will say is that once you enter the ethernet realm, unless your devices buffer's run dry (which they won't) you won't notice any difference in SQ at all.

 

I hear audioquest can sell you some great sounding jumbo packets :)

 

 

Edited by Guest
Link to comment
Share on other sites



2 minutes ago, TDK said:

 

A switch will pound a router to death in the performance stakes, unless you've got a very expensive one (router). If the OP wants some better performance on his LAN, then chances are putting more money into a decent switch will make it happen.

 

And keep the config simple, it's really not needed on a home network.


I hear audioquest can sell you some great sounding jumbo packets :)

 

 

My Mikrotik was sub-$200 new, sub-$90 when I bought it. It is not a particularly quick 'tik. 

 

Routes just fine managing multiple subnets, VPNs, custom scripts, WAPs, mega firewalling etc just fine. Ticks over under 5% CPU usage most of the time.

 

The audio PC does indeed sound different at different MTUs, speeds, etc. Once the router config's good to go, the rest is just cheap fun to play with.

Link to comment
Share on other sites

I really think that this is unnecessarily complicating your network setup for negligible benefit.  

 

Jumbo frames are used when interfacing network elements with high performance devices (like IP based SANs). Your goodput increases when running Jumbo frames, but you need something to drive an interface at near line rate for you to see any real benefit.  Audio gets transferred at low rates when compared to an interface bandwidth (1.4 Mbps for CD audio vs a 100 Mbps or gigabit interface).

 

Segregating your audio to another VLAN means you don't get other devices chatting on the network, but you are unlikely to be saturating your network with broadcast traffic.

 

OP is creating a lot of work for someone who is obviously not a networking specialist, trying to overcome problems that don't exist. 

I'll happily sell you a Layer 3 switch with your configuration request applied, jumbo frames turned on and with separate VLANs routing but it's not going to make a difference to sound or the integrity of the underlying data transferred. PM me if you're keen. 

  • Like 1
Link to comment
Share on other sites

13 minutes ago, recur said:

I really think that this is unnecessarily complicating your network setup for negligible benefit.  

 

Jumbo frames are used when interfacing network elements with high performance devices (like IP based SANs). Your goodput increases when running Jumbo frames, but you need something to drive an interface at near line rate for you to see any real benefit.  Audio gets transferred at low rates when compared to an interface bandwidth (1.4 Mbps for CD audio vs a 100 Mbps or gigabit interface).

 

Segregating your audio to another VLAN means you don't get other devices chatting on the network, but you are unlikely to be saturating your network with broadcast traffic.

 

OP is creating a lot of work for someone who is obviously not a networking specialist, trying to overcome problems that don't exist. 

I'll happily sell you a Layer 3 switch with your configuration request applied, jumbo frames turned on and with separate VLANs routing but it's not going to make a difference to sound or the integrity of the underlying data transferred. PM me if you're keen. 

Assuming you have tried this and not an unasked for "expert opinion"

  • Like 1
Link to comment
Share on other sites



Since you asked how to do it, and not whether it was a bad idea: 

 

WWW.CISCO.COM

This document provides a sample configuration for Maximum Transmission Unit (MTU) sizes supported across all of the Cisco Catalyst-series switches on Ethernet-based ports.

 

Skip to the:

 

Use the system mtu jumbo command to change the MTU for all Gigabit Ethernet interfaces. This command only affects Gigabit Ethernet Interfaces.

2970(config)# system mtu jumbo 9000
2970(config)# exit
2970# reload

Verify

Use the show system mtu command to view the MTU sizes after reload.

2970# show system mtu
System MTU size is 1998 bytes
System Jumbo MTU size is 9000 bytes

 

 

Plug all your audio devices into that switch. Don't change the vlan assignments. Don't plug in the TPLINK unless you can change a specific interface's MTU to match the 2960. Run it and see how it "sounds", and don't listen to those experts who poo poo the idea that unicorns stroke the binary as it flows through an audiophile switch. 

 

I'll be surprised if any of your audio kit actually supports a higher MTU than 1500, but I wish you the best of luck on your wonderful journey of learning.

 

 

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

29 minutes ago, recur said:

What would I know about networking anyway? 

I'm sure you are very good at what you do and if I read correctly between the lines congratulations on a great sale but the purpose here (as I understand it) is not to improve the capacity of the network. 

Link to comment
Share on other sites



Your proposed changes don't change the capacity of the network, they change how frames are sent and received by a switch port, or how to limit collision domains on an ethernet switched segment. The former won't give you anything unless your DAC or NAS start using jumbo frames (unlikely) and the latter is not likely to make a difference unless you have hundreds of chatty hosts on your network.

 

I'm all for people experimenting, but the only thing I'd do for audio is set up some sort of low latency queuing to ensure those packets get serviced first and have priority on the network.   This is implemented by quality of service functionality in your switch and router (router only if it needs to go across a network / VLAN boundary). 
 


Dicking around with networking can easily make things worse, not better.  If you want better, ask a networking specialist who knows what they are doing, don't just read a few posts on Audio Bacon and think they know what they are doing.

Link to comment
Share on other sites

Hilarity here.

 

The whole point concerns OS jitter at the receiving side. The variables concern Ethernet port usage. @recur you're looking at it from a networking perspective which isn't invalid - and yes, the effects are slight to negligible - what's intended here concerns the device receiving data. Would compile a kernel at the receive end with sufficient tracing giving rise to an effective OS jitter measurement to be able to check for anything.

 

Or simply - as always - pull the Ethernet cable/drop the interface during playback to hear what's what. 

 

He's got a NUC at the receiving end that will support a 9k MTU. Yes, he's unlikely to have everything else to support jumbo frames and so things are likely to get worse on that front.

 

Subnetting needn't involve VLAN If done at the edge. I'll send the OP a configured router free of charge when I find time (this week has been ridiculous, sorry @frednork). 

 

I'd similarly drop speed to 100Mbps.

 

Some find it audible, and some can debate it without colouration through talk of poo, unicorns and acquisitions.

 

It's super cheap to try, if only everything on this journey were so.

Link to comment
Share on other sites

@rmpfyf, the last thing I would suggest is to shunt time sensitive traffic over a software based router to be routed.

 

Any soho router like the Microtik's you speak of, are all just a software based CPU bound router. They use a CPU to route packets.  Every time you enter and egress the router, you're subject to additional latency from the route lookup. While this might be quick enough for a home, if you are absolutely gungho about traffic getting somewhere fast across a subnet boundary, you'd be using an ASIC based switch . These will route at (or near) line rate with all interfaces lit up, but are usually considered too noisy in a home unless you have your stuff in a rack in a separate room, out of sight.

 

Any Catalyst 3xxx series switch from Cisco with a L3 license from about 2000-ish on would do this on its ear. VLANs allocated to ports, hosts plugged into the right VLANs and a VLAN interface with an IP address per VLAN. eg a 3750g with 24 ports will do circa 32 Gbps of switching and will route at 37.5 Mpps (that's all ports routing on a 24 port switch, at line rate). That's a switch you could buy used for about $400. 

 

Optimising traffic between two endpoints isn't a new problem. Getting time sensitive applications (voice, video, high frequency trading data) between two points on a network was solved long ago. There are architectures and protocols that can be used to optimise transmission using QoS tagging, configurations like low latency queuing and VLAN segregation to maximise throughput in a LAN. 

I don't care for audio being treated any different to voice or video in terms of transmission. All you are doing is transmitting payload encapsulated with headers between two hosts, who then rip off the header and do something with the data inside. If we define what is interesting traffic (eg latency sensitive traffic containing audio), we can design compensating controls into the network to make sure that this traffic is always serviced first and is not queued behind other less critical traffic.

 

If you're focused on absolutely extreme performance from your NAS to your DAC or streaming device, run a dedicated cross over cable between the two. No network contention, no extra broadcast traffic to deal with, no need to route the traffic over a resource bound router. No need for a router, just two devices on the same unique subnet with different IP addresses at each end. It's much cheaper and easier than anything else you could try and will offer the optimal conditions for data to get between the two things you care most about. 

Link to comment
Share on other sites

@recur - on this you're right, of course.

 

Under no illusion about what a 'Tik is (though TBH the Cloud Core devices are impressive, and offer a serious level of performance per dollar). The SOHO devices are - both in intent and performance - just what you describe. I have a 2011 and a few 3011, 4011 and 915's in field... they do a great job for what they're intended. 

 

I can afford to give away a Mikrotik because it's software based and it's worth well under $100 new. Whilst the discussion is around separate subnets, the end intent could be done just as easily with a firewall. And what I'm doing effectively in setup is just limiting what can hit the audio device's Ethernet interface, diminishing how often something gets there. I can set the MTU up to whatever the ports will do (won't be 9k on this small, SOHO device - whether or not there are >standard packets through the system), limit what gets to the port an only broadcast 100Mbps support. Super easy, cheap thrills, and if it doesn't do anything serious or even observable for the owner the cost is so low it's practically no harm no foul. On a scheme of 'give it a shot' we have people advocating $300+ Ethernet cables as a place to start, and so 'I wonder what I can do with some spare equipment I have kicking around the house' is (relatively speaking) is IMHO a fairly laudable pursuit. 

 

And you're correct around the time sensitivity of things. QoS or otherwise, I've never run into serious latency issues with music on even a 100Mbps connection. Music is not a 32Gbps problem. People caring about such things will run a two-box solution with a crossover cable between them. People super serious and worried about the world will make that connection optical etc etc. Certainly it works. 

 

The challenge with PC-based playback (or anything with an OS or just using interrupts to process Ethernet on the same CPU/MCU intended for music playback) is really just one of OS jitter. It's not about getting traffic superfast across the subnet boundary (not at least for this level of traffic assuming the OP isn't running a data-heavy business out of his home), it's really just about OS jitter as a somewhat-direct-but-not-completely-so contributor to playback jitter.

 

Life'd be much easier if most playback devices did properly isolated reclocking at the playback end, and if what happened inside the upstream device had zero effect whatsoever. 

Link to comment
Share on other sites



  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...
To Top