KeithL
Administrator 
Posts: 10,256
|
Post by KeithL on Oct 9, 2018 11:28:03 GMT -5
I guess I'm a little confused about this whole question/issue.
In network terms, "bridging" is when you connect two networks together as part of the same network, without interposing a router between them; the "bridged networks" are topologically part of a single network...
What a switch does is bridging (as opposed to routing). In the old days, bridging was commonly used by cable modems.....
Your network, and those of your closest neighbors, were all connected to the same "network node", and your cable modem acted as a "bridge"... connecting your network to "the" network.
From the point of view of the main network, you and your neighbors were simply connected to one subnet.
And, yes, bridging is usually faster, and with lower latency, than routing.
However, once you reach that point, there are other considerations. For example, a cut-through switch will have lower latency than a store-and-forward type switch (but is more likely to create occasional bad packets). And all of this is so far "above" anything that matters for computer audio that it isn't even funny.
I read that article on Computer Audiophile:
It's interesting, but I seem to perceive a bit of a gap in understanding about how networks "work". (He seems to find things "interesting" that are really just "how networks work"... like having a sigle DHCP server service two networks which are bridged together into a single network.)
For example, the author expended significant effort in figuring out how to "bridge" the two Ethernet ports on his Mac Mini (all this means is that he configured them to be on the same subnet). It would have been much easier to connect one of those ports to an external Ethernet SWITCH. All of the ports on a switch are "bridged together", so they're all part of the same network, and the circuitry on most switches is crazy fast compared to the Ethernet circuitry inside a Mac.
Bridging the two ports on the Mac might provide a slightly faster network connection between the Mac and the network... but the Mac Mini isn't fast enough itself for that to be likely to matter.
And, to provide the fastest possible connections between other devices on the network, an external cut-through switch will be far and away the fastest - with the lowest latency.
(Most small Ethernet switches don't even mention whether they are store-and-forward or cut-through... because both are so fast that it's considered to be largely irrelevant.)
An update...I reached out to a friend very knowledgeable about computer networking as well as the crowd at Computer Audiophile. I got some suggestions from each and just finished trying them all. At 1 point, it looked like I was close - but...no cigar. I threw one last question back to the CA crowd and I will see if I get any additional advice from that. At this point in the thread, the main topic is about reclocking so nobody really seems interested in helping solve a bridging issue. Net, I doubt I'll get any more advice and will just punt if I don't. Mark |
|
klinemj
Emo VIPs 
Official Emofest Scribe
Posts: 15,083
|
Post by klinemj on Oct 9, 2018 13:19:29 GMT -5
I guess I'm a little confused about this whole question/issue. In network terms, "bridging" is when you connect two networks together as part of the same network, without interposing a router between them; the "bridged networks" are topologically part of a single network...
What a switch does is bridging (as opposed to routing). In the old days, bridging was commonly used by cable modems.....
Your network, and those of your closest neighbors, were all connected to the same "network node", and your cable modem acted as a "bridge"... connecting your network to "the" network.
From the point of view of the main network, you and your neighbors were simply connected to one subnet.
And, yes, bridging is usually faster, and with lower latency, than routing. Keith, I am by no means a networking expert, and I do question whether what they are doing actually improves sound. I would just like to try...any suggestions for how to get my bridge to work correctly would be appreciated. That said - it does appear you are confused re. their motives for bridging...it's not for speed. Here's my translation of what they are saying after reading through quite a bit there and learning a bit on my own. They are saying that when Roon communicates from 1 device to another using its underlying backbone (RAAT) that underlying communications protocols (which I assume to be the 7 layers of OSI comms) come into play. If Roon does not use those protocols - they claim sound is even better (and they claim major differences...I am very skeptical, as noted...but would like to hear for myself). Further, if one bridges 2 ethernet ports such that both are part of 1 virtual network adapter (such as can be done in Windows 10) then both ports have the same IP address. In their theory, in this case, one can have a PC connected to the internet via 1 of the sides of the bridges ports and something like my UltraRendu connected to the others, and Roon Core (on the PC) will send data directly to the ultraRendu without having the underlying comms protocols coming into play. Their theory may be complete BS, but I'd like to hear the sound for myself. Also, if you dig deep into their thread, you will find some thinking having the PC and the ultraRendu each connected to a switch would do the same thing, but others jump in and say that this is what they originally had prior to bridging ports but found the bridging sounded (a lot) better. So...that said - aside from debating their theory...any ideas why I can't even get the bridging to work? Mark |
|
DYohn
Emo VIPs
Posts: 18,485
|
Post by DYohn on Oct 9, 2018 13:50:41 GMT -5
cough... cough... cough... brilliant pebbles... cough...
|
|
klinemj
Emo VIPs
Official Emofest Scribe
Posts: 15,083
|
Post by klinemj on Oct 9, 2018 13:58:14 GMT -5
cough... cough... cough... brilliant pebbles... cough... yeah, I know...but what the heck...nothing ventured, nothing gained! I did get one last suggestion from the CA folks...will try once I can. Will take 15 minutes at most. Mark |
|
KeithL
Administrator
Posts: 10,256
|
Post by KeithL on Oct 9, 2018 14:37:54 GMT -5
Errrr.... what you said is actually sort of invalid.... You cannot assign two different devices the same IP address on the same network.
This is known as an address conflict - and causes excessive packet loss and indeterminate routing behavior.
(There are some very special situations, involving fail-over and load balancing, where this can be done... but that's not what they're talking about.)
I think I figured out what they're talking about...... although their explanation is somewhat obtuse. They're talking about configuring a SINGLE virtual port, which can then be accessed via both network cards.
This is certainly possible... although I'm dubious about the benefits.
They then want to enable Layer 2 communications between the ports. This would enable the two devices on the two ports to communicate directly at Layer 2. Doing it that way would bypass the several extra steps necessary to allow them to communicate via IP (which is Layer 3). The closest analogy would be two adjoining hotel rooms. Normally, to go from one to the other, you would have to go out into the hall. They want to open the adjoining door between the rooms. Normally, in order to do this, you would use a switch, which is FAR faster than the ports in a computer. However, they may be hoping to separate the types of traffic, allowing one protocol a direct path while still routing the others.
There may also be some benefit in their particular configuration by having the ports on the same computer as some of the software.
It sounds simple, but the details can get very messy. Note that I still fail to see any reason why this should in any way affect the sound quality of a network music player. While it's true that they may avoid certain complexities (in return for others).... Other than by improving either the throughput or the latency there's simply no way in which they can "make packets sound better". However, there is the possibility of "unintended consequences".
By forcing the devices to use certain specific protocols, they may cause OTHER specific configuration options to be chosen, which may somehow affect sound quality.
(For example, Roon may default to different packet sizes depending on which protocol is being used.) As to why you can't get it to work......
This sort of setup is rather complex, and requires using some "advanced configuration options" on the computer and network cards. It may work exactly as described with certain specific brands, but others may require slight adjustments to the configuration, or may simply not work at all on some.
I would look for specific differences in the capabilities of the hardware that people got to work and yours..... (most likely in the network cards).
As I said, I would consider this an interesting exercise in "cool things you can do on a network"...
But I'm extremely dubious that it would make an audible difference.
Assuming that their configuration ends up being equivalent to a switch I would expect the performance of the switch to be far better.
(If I was going to do this sort of thing, I think I'd be looking for a nice fast low-cost switch, instead of bothering with reconfiguring computer ports.)
I guess I'm a little confused about this whole question/issue. In network terms, "bridging" is when you connect two networks together as part of the same network, without interposing a router between them; the "bridged networks" are topologically part of a single network...
What a switch does is bridging (as opposed to routing). In the old days, bridging was commonly used by cable modems.....
Your network, and those of your closest neighbors, were all connected to the same "network node", and your cable modem acted as a "bridge"... connecting your network to "the" network.
From the point of view of the main network, you and your neighbors were simply connected to one subnet.
And, yes, bridging is usually faster, and with lower latency, than routing. Keith, I am by no means a networking expert, and I do question whether what they are doing actually improves sound. I would just like to try...any suggestions for how to get my bridge to work correctly would be appreciated. That said - it does appear you are confused re. their motives for bridging...it's not for speed. Here's my translation of what they are saying after reading through quite a bit there and learning a bit on my own. They are saying that when Roon communicates from 1 device to another using its underlying backbone (RAAT) that underlying communications protocols (which I assume to be the 7 layers of OSI comms) come into play. If Roon does not use those protocols - they claim sound is even better (and they claim major differences...I am very skeptical, as noted...but would like to hear for myself). Further, if one bridges 2 ethernet ports such that both are part of 1 virtual network adapter (such as can be done in Windows 10) then both ports have the same IP address. In their theory, in this case, one can have a PC connected to the internet via 1 of the sides of the bridges ports and something like my UltraRendu connected to the others, and Roon Core (on the PC) will send data directly to the ultraRendu without having the underlying comms protocols coming into play. Their theory may be complete BS, but I'd like to hear the sound for myself. Also, if you dig deep into their thread, you will find some thinking having the PC and the ultraRendu each connected to a switch would do the same thing, but others jump in and say that this is what they originally had prior to bridging ports but found the bridging sounded (a lot) better. So...that said - aside from debating their theory...any ideas why I can't even get the bridging to work? Mark |
|
|
|
Post by novisnick on Oct 9, 2018 14:38:38 GMT -5
cough... cough... cough... brilliant pebbles... cough... yeah, I know...but what the heck...nothing ventured, nothing gained! I did get one last suggestion from the CA folks...will try once I can. Will take 15 minutes at most. Mark Didn’t you make that claim a few weeks ago!LOL😏 |
|
DYohn
Emo VIPs
Posts: 18,485
|
Post by DYohn on Oct 9, 2018 14:39:45 GMT -5
"Not everything that can be measured matters..."
|
|
klinemj
Emo VIPs
Official Emofest Scribe
Posts: 15,083
|
Post by klinemj on Oct 9, 2018 15:35:47 GMT -5
I think I figured out what they're talking about...... although their explanation is somewhat obtuse. They're talking about configuring a SINGLE virtual port, which can then be accessed via both network cards.This is certainly possible... although I'm dubious about the benefits. They then want to enable Layer 2 communications between the ports. This would enable the two devices on the two ports to communicate directly at Layer 2. Doing it that way would bypass the several extra steps necessary to allow them to communicate via IP (which is Layer 3).The closest analogy would be two adjoining hotel rooms. Normally, to go from one to the other, you would have to go out into the hall. They want to open the adjoining door between the rooms. Normally, in order to do this, you would use a switch, which is FAR faster than the ports in a computer. However, they may be hoping to separate the types of traffic, allowing one protocol a direct path while still routing the others. There may also be some benefit in their particular configuration by having the ports on the same computer as some of the software. It sounds simple, but the details can get very messy. Note that I still fail to see any reason why this should in any way affect the sound quality of a network music player. While it's true that they may avoid certain complexities (in return for others)....Other than by improving either the throughput or the latency there's simply no way in which they can "make packets sound better". However, there is the possibility of "unintended consequences". By forcing the devices to use certain specific protocols, they may cause OTHER specific configuration options to be chosen, which may somehow affect sound quality. (For example, Roon may default to different packet sizes depending on which protocol is being used.) As to why you can't get it to work...... This sort of setup is rather complex, and requires using some "advanced configuration options" on the computer and network cards. It may work exactly as described with certain specific brands, but others may require slight adjustments to the configuration, or may simply not work at all on some. I would look for specific differences in the capabilities of the hardware that people got to work and yours..... (most likely in the network cards). As I said, I would consider this an interesting exercise in "cool things you can do on a network"... But I'm extremely dubious that it would make an audible difference. Assuming that their configuration ends up being equivalent to a switch I would expect the performance of the switch to be far better. (If I was going to do this sort of thing, I think I'd be looking for a nice fast low-cost switch, instead of bothering with reconfiguring computer ports.) The parts I bolded is what I was trying to say that they are doing - so...yes, you now "got it". And, the virtual port does indeed show up in my list of network adapters (with the physical ones showing "bridged" and the virtual on showing connected to my local network that my router controls). Again, I am skeptical on the benefits also. Re. whether a switch does the same thing or not - they insist it does not. But, if it does, this is exactly how I had it set up before: Router hard-wired port out to switch...switch port #1 to PC, switch port #2 to ultraRendu (which sounds awesome, by the way). I am indeed looking for differences in hardware that could explain theirs working and mine not. So far no "golden nugget" that explains it. Mark |
|
klinemj
Emo VIPs
Official Emofest Scribe
Posts: 15,083
|
Post by klinemj on Oct 10, 2018 16:19:02 GMT -5
I probed a bit more on Computer Audiophile, and I got more responses from more people but mostly nothing concrete. But, a comment from Andrew Gillis (of Sonore/small green computer fame) and what Keith said led me to some more searching.
While many of the CA users are convinced a switch does not do the same thing as a bridge as it relates to their "theory" - it sure looks like they do to me. I found 2 quotes I really liked that fit with some things Keith said but say it another way:
“An ethernet switch is a multiport ethernet bridge. A bridge is a device that splits collision domains but not broadcast domains. A switch is simply a bridge with lots of ports.”
...and...
“Switches perform forwarding in hardware, while bridges perform it in software“.
The article I found that in talked about the difference between them not being "what" they did but how they did it.
Net, I think that anything that keeps communications in the Level 2 (ideally) or Level 3 (but certainly out of layer 4, the "Transport" layer) of the OSI model should have the benefits the "bridge supporters" claim - regardless of what it's called. And, most switches do just that.
So - I am considering this experiment over.
Mark
|
|
|
|
Post by novisnick on Oct 10, 2018 16:24:44 GMT -5
I probed a bit more on Computer Audiophile, and I got more responses from more people but mostly nothing concrete. But, a comment from Andrew Gillis (of Sonore/small green computer fame) and what Keith said led me to some more searching. While many of the CA users are convinced a switch does not do the same thing as a bridge as it relates to their "theory" - it sure looks like they do to me. I found 2 quotes I really liked that fit with some things Keith said but say it another way: “An ethernet switch is a multiport ethernet bridge. A bridge is a device that splits collision domains but not broadcast domains. A switch is simply a bridge with lots of ports.” ...and... “Switches perform forwarding in hardware, while bridges perform it in software“. The article I found that in talked about the difference between them not being "what" they did but how they did it. Net, I think that anything that keeps communications in the Level 2 (ideally) or Level 3 (but certainly out of layer 4, the "Transport" layer) of the OSI model should have the benefits the "bridge supporters" claim - regardless of what it's called. And, most switches do just that. So - I am considering this experiment over. Mark Its been a fun ride Mark, thanks for the adventure. |
|
klinemj
Emo VIPs
Official Emofest Scribe
Posts: 15,083
|
Post by klinemj on Oct 10, 2018 16:49:15 GMT -5
I probed a bit more on Computer Audiophile, and I got more responses from more people but mostly nothing concrete. But, a comment from Andrew Gillis (of Sonore/small green computer fame) and what Keith said led me to some more searching. While many of the CA users are convinced a switch does not do the same thing as a bridge as it relates to their "theory" - it sure looks like they do to me. I found 2 quotes I really liked that fit with some things Keith said but say it another way: “An ethernet switch is a multiport ethernet bridge. A bridge is a device that splits collision domains but not broadcast domains. A switch is simply a bridge with lots of ports.” ...and... “Switches perform forwarding in hardware, while bridges perform it in software“. The article I found that in talked about the difference between them not being "what" they did but how they did it. Net, I think that anything that keeps communications in the Level 2 (ideally) or Level 3 (but certainly out of layer 4, the "Transport" layer) of the OSI model should have the benefits the "bridge supporters" claim - regardless of what it's called. And, most switches do just that. So - I am considering this experiment over. Mark Its been a fun ride Mark, thanks for the adventure. Thanks - it was educational, for sure...always good to learn more! Mark |
|
|
|
Post by brubacca on Oct 10, 2018 18:42:27 GMT -5
The only thing that looks mildly interesting to me that I learned recently is called Link Aggregation. I got NAS with (2) Ethernet Ports. It supports LA so if you also use a Switch that supports link aggregation then you can hook up both ports to the switch. They get ONE IP address and work together. If one port is overloaded the second port picks up the slack. If one port or cable fails then the other port works.
Form my research they said on the home environment the losses you get from this aggregation of the ports really reduces the effectiveness. In practice I have seen no difference in serving up data to my mR with two or one port.
Also the new 10GB standard is coming down to user level and this is where big leaps in network performance (speed) can be gained.
|
|
klinemj
Emo VIPs
Official Emofest Scribe
Posts: 15,083
|
Post by klinemj on Oct 10, 2018 19:10:48 GMT -5
The only thing that looks mildly interesting to me that I learned recently is called Link Aggregation. I got NAS with (2) Ethernet Ports. It supports LA so if you also use a Switch that supports link aggregation then you can hook up both ports to the switch. They get ONE IP address and work together. If one port is overloaded the second port picks up the slack. If one port or cable fails then the other port works. Form my research they said on the home environment the losses you get from this aggregation of the ports really reduces the effectiveness. In practice I have seen no difference in serving up data to my mR with two or one port. Also the new 10GB standard is coming down to user level and this is where big leaps in network performance (speed) can be gained. That's also known as "teaming" if I understand correctly...been around a while. Mark |
|
|
|
Post by kenj on Feb 20, 2019 0:55:37 GMT -5
|
|
KeithL
Administrator
Posts: 10,256
|
Post by KeithL on Feb 20, 2019 13:01:28 GMT -5
There are a few facts that are worth noting....
The network bandwidth required for digital audio is tiny... so, if you were ONLY using it for audio, even a really slow and outdated network would be plenty. However, no matter how fast your network is, if it is overly congested, or not set up properly, it can cause excessive network delays, which can impact audio performance. In many situations this simply means that, if you plan to download that 40 gB Blu-Ray bootleg, or do some serious video editing, you should do it overnight - when you're NOT listening to music.
Once you get past that part of it, however, the ONLY job of a network is to get packets from one device to another. Therefore, assuming things are working properly, and it isn't causing packet loss, or delays that cause other issues, no network is going to sound different than another. (A network may have problems, which may negatively affect sound quality, but there is no opportunity for a network WITHOUT problems to sound different than another network that is equally problem-free.) Unfortunately, when it comes to specific devices, it is quite possible that a specific service or device may work well with certain types of networks, and not so well with others. (There is nothing inherently better about a bridged or routed network, and both have advantages and disadvantages, but you may find that Roon's proprietary protocol works better or more reliably on one or the other.)
The other thing that complicates matters these days is that there is a lot of functional overlap between products... Even though a "basic switch" does bridging, many modern switches also perform some routing functions, some routers also perform some bridging functions, and many of both include some firewall functionality. (A typical "simple cable modem" really contains: a DocSIS modem, an Internet edge router, a multi-port switch, a WiFi router, a DHCP server, and often even a simple firewall.)
However, to go back to an earlier point, all of this complexity can make it tricky to get devices to talk to each other across a network... But, once you have network connectivity, unless there is a problem, none of those issues should have much if anything to do with audio quality. (You might as well suggest that your CDs sound better if you bring them home from the store in a Mercedes instead of a Volkswagen.)
Another sort of important thing to note is that many of the terms being discussed relate to NETWORK TOPOLOGY at the logical level. This is a nice way of saying that, for example, "bridging" describes how the network addresses are set up and where the packets end up. However, it often doesn't fully specify where the packets PHYSICALLY go - or how fast they get there. So, for example, a typical Ethernet switch performs bridging, and you can also set up a computer to bridge between two Ethernet cards...
However, you need to know that a hardware Ethernet switch is very fast because of how the hardware itself is set up....
But, even though the logical configuration may be the same, your computer is using two plain old Ethernet cards, and lacks the super-high-speed switching backplane used in hardware switches. And, because of this, the computer could be tens or even hundreds of times slower at bridging packets than a true hardware switch....
These days, even really cheap low end switches tend to be very fast, and have very low latency... whereas low-end routers do more "thinking" and tend to be much more subject to slowdowns... and that applies even more strongly to computers.
(This is why both what you use, and how you connect it together, can be important.)
In real commercial network installations, one would normally specify the required bandwidth, and perhaps the maximum acceptable latency, and the sorts of packets that need to be passed.... (And none of the other details would really matter.)
|
|
