Jump to content
IGNORED

Ethernet Cables - which are the most important?


Recommended Posts

I'm in the process of upgrading my Ethernet cables from the current mixture of Belkin Cat6 and Chord C-Stream and would appreciate some advice.

 

My question is, which connections are the most critical and where I should focus my money, and which are lower priority? I'm looking at going down the AudioQuest route of Vodka and Cinnamon.

 

My system is as follows -

 

CISCO C2960 switch connecting

  • Small Green Computers - sonicTransporter i7 (Roon Core)
  • SONORE microRendu
  • NAS
  • iMac (running HQPlayer)

 

All the above require short cables i.e 0.75m other than the iMac which needs circa 8m

 

Any experience/feedback would be much appreciated.

 

Thanks

 Innuos Zenith SE (Roon Core) > Curious USB/Upton ISO REGEN +LPS-1/USPCB> Chord Hugo TT > ATC SCM 40A

Link to comment

Despite what people will tell you, as long as they provide a reliable connection, Ethernet cables make no difference whatsoever. Cat 5e is good for gigabit speeds over at least 100 feet. While there are cheap cables that don't quite meet the specs, Belkin is perfectly fine. Stick with them and spend your money where it matters, such as on music.

Link to comment
I'm in the process of upgrading my Ethernet cables from the current mixture of Belkin Cat6 and Chord C-Stream and would appreciate some advice.

 

My question is, which connections are the most critical and where I should focus my money, and which are lower priority? I'm looking at going down the AudioQuest route of Vodka and Cinnamon.

 

My system is as follows -

 

CISCO C2960 switch connecting

  • Small Green Computers - sonicTransporter i7 (Roon Core)
  • SONORE microRendu
  • NAS
  • iMac (running HQPlayer)

 

All the above require short cables i.e 0.75m other than the iMac which needs circa 8m

 

Any experience/feedback would be much appreciated.

 

Thanks

 

The only thing I might suggest is buying a bulk roll of CAT 5e or CAT 6 and learning how to crimp the connectors so you can have matching cables that are all the exact right length. Applying some cable management won't make your system sound any different, but a nice looking wiring closet is very satisfying.

Link to comment
I'm in the process of upgrading my Ethernet cables from the current mixture of Belkin Cat6 and Chord C-Stream and would appreciate some advice.

 

My question is, which connections are the most critical and where I should focus my money, and which are lower priority? I'm looking at going down the AudioQuest route of Vodka and Cinnamon.

 

My system is as follows -

 

CISCO C2960 switch connecting

  • Small Green Computers - sonicTransporter i7 (Roon Core)
  • SONORE microRendu
  • NAS
  • iMac (running HQPlayer)

 

All the above require short cables i.e 0.75m other than the iMac which needs circa 8m

 

Any experience/feedback would be much appreciated.

 

Thanks

 

I've been slinging Cisco equipment since 2000. I actually picked up a ~$350 Vodka cable and there isn't one iota of difference in audio. This is because they are DATA cables and not audio cable's.

 

Before that I was installing NLE audio and Video edit suites. Some in the $250,000 - $500,000 range (for broadcast). So I've been involved professionally in both the data and audio aspects of this.

 

My last Cisco implementation was 6 Cisco 4000 ISR's in a partial mesh all rolling out to a multi-vlan switch stack. We are talking encryption end to end, AAA servers, VOIP. The entire enchilada.

 

Here is what I can tell you: the Vodka was experiencing higher BER than some $8 cables that passed CAT6a spec running 10GBe.

 

If you want to pay astronomical prices for a cable that exhibits poor BER (most likely to disappear at 1GBe) then the AQ is your best bet.

 

This audiophile business with Ethernet cables is 100% BS. Anyone tells you different you let them know I have $2000 that says they are full of shit.

 

Here is a link to my test setup and it lays out the challenge:

Link to comment
I've been slinging Cisco equipment since 2000. I actually picked up a ~$350 Vodka cable and there isn't one iota of difference in audio. This is because they are DATA cables and not audio cable's.

 

Before that I was installing NLE audio and Video edit suites. Some in the $250,000 - $500,000 range (for broadcast). So I've been involved professionally in both the data and audio aspects of this.

 

My last Cisco implementation was 6 Cisco 4000 ISR's in a partial mesh all rolling out to a multi-vlan switch stack. We are talking encryption end to end, AAA servers, VOIP. The entire enchilada.

 

Here is what I can tell you: the Vodka was experiencing higher BER than some $8 cables that passed CAT6a spec running 10GBe.

 

If you want to pay astronomical prices for a cable that exhibits poor BER (most likely to disappear at 1GBe) then the AQ is your best bet.

 

This audiophile business with Ethernet cables is 100% BS. Anyone tells you different you let them know I have $2000 that says they are full of shit.

 

Here is a link to my test setup and it lays out the challenge:

 

Audioquest ethernet cables are great, please send me $2000.

 

In all fairness I haven't tried them but your offer was too generous to pass up.

Link to comment

Instead of "audio" Ethernet cables, I've recently invested in Blue Jeans Cable Cat5e & Cat6 cables for audio networking use. BJC cables are reasonably priced, and each cable ordered comes with a 1-page test report showing spec compliance and margins from limits. The shortest cable length that can be ordered is 1 foot. I particularly like their use of bonded pair Belden cable stock, which yields more consistent impedance for better signal waveform integrity.

 

For normal networking use, even cheap Cat5e cables will most often get the job done. Cables can differ in BER numbers, but unless the BER is really awful the imperfections of a cheap cable is often masked and non-obvious. However, for audio use, I suspect things are a bit more complex. A streamer receiving audio over Ethernet may deliver worse SQ if the incoming Ethernet signal waveform is not good. Basically the receiver portion of the Ethernet PHY has to work harder to retrieve the data payload carried by the incoming Ethernet signal, thus generate more electrical noise which can contaminate the rest of the circuitry (clocks, USB interface, etc.) It's the same concept that enables a REGEN to clean up USB signal quality entering a DAC for better sound.

 

Even the length of Ethernet cables can impact SQ to some extent, but I won't go into that here.

Link to comment
A streamer receiving audio over Ethernet

 

Streamers receive data over Ethernet.

 

may deliver worse SQ if the incoming Ethernet signal waveform is not good

 

No, they won't behave in an analog fashion. You will experience drop outs.

 

Basically the receiver portion of the Ethernet PHY has to work harder to retrieve the data payload carried by the incoming Ethernet signal, thus generate more electrical noise which can contaminate the rest of the circuitry (clocks, USB interface, etc.) It's the same concept that enables a REGEN to clean up USB signal quality entering a DAC for better sound.

 

Again incorrect. Ethernet PHY's always run at full tilt. They are designed for this. A 1GB connection transferring 95MB/S, which is about the max depending on protocol overhead, is no more over or under taxed if it's just getting 9.5MB/S from a 100MB connection from somewhere on the network.

 

The only thing the retransmission (if any) is effectively reduced your band-width. It never made the PHY or buffers work any harder than they did when they were successfully delivering data at 95MB/s. They just stayed transferring data for a bit (like nano-seconds) longer.

 

Even the length of Ethernet cables can impact SQ to some extent, but I won't go into that here.

 

Please DO go into it here.

 

I'll tell you what:

 

I have a Cisco 2811, 3725, and 2600 sitting here with either G or Fa cards. I'll setup a quick OSPF routed network between them.

 

I'll run 300 foot from multi-homed server to SW1<> R1<>R2<>R3 <>SW3 to multi-homed client computer with J-River. That is 300 foot on EACH segment. That is 1500 foot of cabling.

 

Then I'll run ~ a 12 foot cable direct from the other NIC in the server directly to the client computer. All I ask is that you pay for the cabling if you can't tell the difference on some headphones out the DAC (Emotiva DC-1). Just hit 11 out of 12 coin flips.

Link to comment
Streamers receive data over Ethernet.

 

 

 

No, they won't behave in an analog fashion. You will experience drop outs.

 

 

 

Again incorrect. Ethernet PHY's always run at full tilt. They are designed for this. A 1GB connection transferring 95MB/S, which is about the max depending on protocol overhead, is no more over or under taxed if it's just getting 9.5MB/S from a 100MB connection from somewhere on the network.

 

The only thing the retransmission (if any) is effectively reduced your band-width. It never made the PHY or buffers work any harder than they did when they were successfully delivering data at 95MB/s. They just stayed transferring data for a bit (like nano-seconds) longer.

 

 

 

Please DO go into it here.

 

I'll tell you what:

 

I have a Cisco 2811, 3725, and 2600 sitting here with either G or Fa cards. I'll setup a quick OSPF routed network between them.

 

I'll run 300 foot from multi-homed server to SW1<> R1<>R2<>R3 <>SW3 to multi-homed client computer with J-River. That is 300 foot on EACH segment. That is 1500 foot of cabling.

 

Then I'll run ~ a 12 foot cable direct from the other NIC in the server directly to the client computer. All I ask is that you pay for the cabling if you can't tell the difference on some headphones out the DAC (Emotiva DC-1). Just hit 11 out of 12 coin flips.

Yes, I meant streamers receiving data packets of digital audio over Ethernet. There is no audio timing information whatsoever carried in the Ethernet data packets.

 

I agree that the Ethernet PHY will always run at negotiated link speed, be it gigabit or 100Mbps. However, even assuming there are no TCP packet re-tranmissions occurring to reduce throughput, I suspect the power consumption of the Ethernet PHY within a streamer may vary to some degree depending on the quality of the differential signal waveform arriving at the receiver. The Ethernet PHY is a sophisticated block of logic capable of extracting the data payload from the incoming signal which may have signal integrity that's far from ideal, but the amount of switching activity within the PHY can depend on how clean the incoming waveform is. To determine if my hypotheses is valid, the power (current) consumption of the Ethernet PHY will need to be measured and correlated with various levels of signal integrity (also measured with an oscilloscope with a differential signal probe). Using a better quality Ethernet cable should help reduce power consumption (and thus noise contribution) of the Ethernet PHY within the streamer. Unfortunately I currently do not have the means to do such measurements.

 

Regarding cable length, a 6'/2m cable may sound better than a 1' cable, as the latter is long enough to delay any partial signal reflections (due to impedance imperfections in cable twisted pairs, RJ45 connectors, etc.) within the cable in time to not get sampled by the PHY. In other words, the effects of any signal reflections up & down the cable are minimized if the cable is long enough. When my friend mentioned this to me, it sounded counterintuitive, as I thought a longer cable may pick up more ambient noise and carry it into the streamer. However, actual listening tests we did comparing different cable lengths has favored the 6'/2m cable, though the SQ difference is admittedly somewhat subtle though detectable.

Link to comment
I suspect the power consumption of the Ethernet PHY within a streamer may vary to some degree depending on the quality of the differential signal waveform arriving at the receiver. The Ethernet PHY is a sophisticated block of logic capable of extracting the data payload from the incoming signal which may have signal integrity that's far from ideal, but the amount of switching activity within the PHY can depend on how clean the incoming waveform is.

 

Do you have anything better than a suspicion to support this idea? It would seem easier to design a PHY to always operate the same way rather than somehow adapt to signal quality.

Link to comment

 

I agree that the Ethernet PHY will always run at negotiated link speed, be it gigabit or 100Mbps. However, even assuming there are no TCP packet re-tranmissions occurring to reduce throughput, I suspect the power consumption of the Ethernet PHY within a streamer may vary to some degree depending on the quality of the differential signal waveform arriving at the receiver. The Ethernet PHY is a sophisticated block of logic capable of extracting the data payload from the incoming signal which may have signal integrity that's far from ideal, but the amount of switching activity within the PHY can depend on how clean the incoming waveform is.

 

What switching activity? These are fixed rate devices.

 

Each PHY only powers it's transmit pair. This means the TX pair feeding the endpoint, be it streamer or client computer, is determined by the network switch.

 

From the endpoint view there isn't much going on on it's TX pair. Most of the time it is spent consuming data.

 

To determine if my hypotheses is valid, the power (current) consumption of the Ethernet PHY will need to be measured and correlated with various levels of signal integrity (also measured with an oscilloscope with a differential signal probe). Using a better quality Ethernet cable should help reduce power consumption (and thus noise contribution) of the Ethernet PHY within the streamer. Unfortunately I currently do not have the means to do such measurements.

 

What possible home networking environment is going to rate such an issue where the maximum, in spec run, is 328 feet?

 

My longest run in the house is for POE through the basement, up an interior wall through a hole I drilled in a prelam header across the ceiling, back down a wall to feed my HTPC. It's ~75 feet.

 

 

Regarding cable length, a 6'/2m cable may sound better than a 1' cable, as the latter is long enough to delay any partial signal reflections (due to impedance imperfections in cable twisted pairs, RJ45 connectors, etc.)

 

The PHY's are impedance matched. They won't be swamped by a correctly constructed cable. Again you are ascribing analog effects into a digital system.

 

These systems are not zero copy stacks either. The packets are sent over the wire and then assembled, buffered on NIC, and then copied again into memory set aside by the CPU and then copied again, most likely be the audio application, samples arranged, then into another buffer before the USB bus gets to fulfilling the request by the DAC or PCIe bus.

 

Anything that went on with the networking side of things became a non issue many, many copies ago.

 

I posted, more than a year ago, the wire shark output of music that I had left playing over my wireless NIC. I had one error in 258 albums worth of playback and it was a recovered error (i.e. re-transmit). All over a $5 802.11n adapter and a $40 Asus router.

 

within the cable in time to not get sampled by the PHY. In other words, the effects of any signal reflections up & down the cable are minimized if the cable is long enough. When my friend mentioned this to me, it sounded counterintuitive, as I thought a longer cable may pick up more ambient noise and carry it into the streamer. However, actual listening tests we did comparing different cable lengths has favored the 6'/2m cable, though the SQ difference is admittedly somewhat subtle though detectable.

 

Again, these are impedance matched systems... You friend doesn't know what they are talking about. They are indeed terminated at each end like old school SCSI was.

Link to comment
Each PHY only powers it's transmit pair. This means the TX pair feeding the endpoint, be it streamer or client computer, is determined by the network switch.

 

Gigabit Ethernet actually sends and receives on all four pairs at the same time. Not that it matters for this discussion.

Link to comment
What switching activity? These are fixed rate devices.

 

Each PHY only powers it's transmit pair. This means the TX pair feeding the endpoint, be it streamer or client computer, is determined by the network switch.

 

From the endpoint view there isn't much going on on it's TX pair. Most of the time it is spent consuming data.

 

 

 

What possible home networking environment is going to rate such an issue where the maximum, in spec run, is 328 feet?

 

My longest run in the house is for POE through the basement, up an interior wall through a hole I drilled in a prelam header across the ceiling, back down a wall to feed my HTPC. It's ~75 feet.

 

 

 

 

The PHY's are impedance matched. They won't be swamped by a correctly constructed cable. Again you are ascribing analog effects into a digital system.

 

These systems are not zero copy stacks either. The packets are sent over the wire and then assembled, buffered on NIC, and then copied again into memory set aside by the CPU and then copied again, most likely be the audio application, samples arranged, then into another buffer before the USB bus gets to fulfilling the request by the DAC or PCIe bus.

 

Anything that went on with the networking side of things became a non issue many, many copies ago.

 

I posted, more than a year ago, the wire shark output of music that I had left playing over my wireless NIC. I had one error in 258 albums worth of playback and it was a recovered error (i.e. re-transmit). All over a $5 802.11n adapter and a $40 Asus router.

 

 

 

Again, these are impedance matched systems... You friend doesn't know what they are talking about. They are indeed terminated at each end like old school SCSI was.

I was thinking the impedance imperfections are in the cable, especially cheap ones. A poorly constructed Ethernet cable can fail near-end crosstalk and return loss specs (for whatever grade the cable is rated at, e.g. Cat5e, Cat6) but still manage completely error free data transmission in actual use. Ethernet by design is robust enough to tolerate even cables that are not completely spec compliant.

 

What's surprised my friend and I are how things like a single Ethernet cable change can alter the sound we hear out of his system. The SQ change cannot possibly be the result of a difference in Ethernet data transmission integrity, but then what is the cause? Other things like adding an EMO Systems EN-70HD Ethernet isolator (rated at gigabit) should in theory make no difference in Ethernet transmission integrity and throughput, so how is the SQ improvement explained? My hypotheses are unfortunately just that, since I currently have no way of backing them up with measurements, so if anyone has better explanations I would be open to subscribe to them.

Link to comment
Gigabit Ethernet actually sends and receives on all four pairs at the same time. Not that it matters for this discussion.

 

Correct. Fast Ethernet is only one pair. But the sender is still lighting up the pairs with voltage to transmit so my point still stands. The end point is mostly consuming data.

Link to comment
Do you have anything better than a suspicion to support this idea? It would seem easier to design a PHY to always operate the same way rather than somehow adapt to signal quality.

Unfortunately, no. I was largely going by my understandings on the USB side (w/ REGEN, W4S RUR, etc.) where a cleaner USB signal waveform entering the DAC yields sonic payoffs, and suspect a similar case for Ethernet. Ethernet PHY designs by definition must adapt to a certain range of incoming signal quality. The part I don't have clarity on is how much the PHY power consumption varies (if at all) depending on incoming Ethernet signal integrity. Perhaps John Swenson with his extensive Ethernet PHY design experience can chime in here.

Link to comment
I was thinking the impedance imperfections are in the cable, especially cheap ones. A poorly constructed Ethernet cable can fail near-end crosstalk and return loss specs (for whatever grade the cable is rated at, e.g. Cat5e, Cat6) but still manage completely error free data transmission in actual use. Ethernet by design is robust enough to tolerate even cables that are not completely spec compliant.

 

What's surprised my friend and I are how things like a single Ethernet cable change can alter the sound we hear out of his system. The SQ change cannot possibly be the result of a difference in Ethernet data transmission integrity, but then what is the cause? Other things like adding an EMO Systems EN-70HD Ethernet isolator (rated at gigabit) should in theory make no difference in Ethernet transmission integrity and throughput, so how is the SQ improvement explained? My hypotheses are unfortunately just that, since I currently have no way of backing them up with measurements, so if anyone has better explanations I would be open to subscribe to them.

 

Poorly implemented PHY on the streamer. Chris has another thread where GBe introduced all sorts of issues and it's coming to light that audio engineers don't make the best network engineers when it comes to implementing networking.

 

I use a computer as a client so I don't have to worry about some guy, that while perhaps a brilliant audio engineer, happens to think it translates to networking.

 

The Sonore microRendu lists "utilizes a proprietary printed circuit board". A potential issue for you is that both of you may be failing to adequately consider all permutations to the issue at hand. You wouldn't be the first customer that blames the wrong component.

Link to comment

What's the buffer size on the microRendu? Can you start playback and unplug the cable and still have audio for a few seconds? I have my system good for ~20 seconds.

 

I would be curious as to what would happen. A properly implemented PHY will be immune to cables that meet CAT5/5E/6/6A spec.

 

If your cable doesn't meet spec then it's not a CAT# cable for what ever spec it doesn't pass.

Link to comment
Poorly implemented PHY on the streamer. Chris has another thread where GBe introduced all sorts of issues and it's coming to light that audio engineers don't make the best network engineers when it comes to implementing networking.

 

I use a computer as a client so I don't have to worry about some guy, that while perhaps a brilliant audio engineer, happens to think it translates to networking.

 

The Sonore microRendu lists "utilizes a proprietary printed circuit board". A potential issue for you is that both of you may be failing to adequately consider all permutations to the issue at hand. You wouldn't be the first customer that blames the wrong component.

Ethernet PHY is usually part of an Ethernet controller chip, so a streamer board-level designer only gets to choose the brand/model of the Ethernet chip. I suppose a bad Ethernet chip choice can doom the streamer design, though streamers are essentially audio-dedicated single-board computers, so it's a bit hard for me to imagine a computer board designer badly botching the Ethernet subsystem design, though I suppose anything is possible in this crazy world.

 

I will admit it is distinctly possible I may be blaming the wrong component. As an audiophile I learn to trust my ears, but my engineering background makes me troubled whenever an audible SQ change (better or worse) cannot be technically explained or backup up by actual measurements. Without any equipment to quantitatively measure things like noise levels, eye patterns, jitter, etc. I am reduced to doing empirical experiments in pursuit of better sound.

Link to comment
What's the buffer size on the microRendu? Can you start playback and unplug the cable and still have audio for a few seconds? I have my system good for ~20 seconds.

 

I would be curious as to what would happen. A properly implemented PHY will be immune to cables that meet CAT5/5E/6/6A spec.

 

If your cable doesn't meet spec then it's not a CAT# cable for what ever spec it doesn't pass.

 

I have no idea. I'll need to do the "unplug Ethernet cable while playing audio" to the microRendu, Aries Femto and Aries Mini and report the results. Aries models with 4.0 firmware or later has implemented RAM playback, so I expect the music to keep playing quite a bit longer vs. the microRendu after the Ethernet cable is unplugged.

 

 

These days I prefer to use Blue Jeans Cable Ethernet cables, as each cable ordered is shipped with a 1-page test report showing spec compliance as well as graphs showing margin for NEXT and RL. It is BJC who claims to have measured various CAT6 cables and found spec violations:

 

Is Your Cat 6 Cable a Dog? -- Blue Jeans Cable

 

I frankly don't believe those spec violations are as serious as BJC has claimed in practice for general networking use (again since Ethernet is so robust), but I'm willing to believe they can be more significant for digital audio streaming over Ethernet, in terms of SQ delivered by the streamer.

Link to comment
Ethernet PHY is usually part of an Ethernet controller chip, so a streamer board-level designer only gets to choose the brand/model of the Ethernet chip.

 

The PHY is usually a separate chip, actually.

 

I suppose a bad Ethernet chip choice can doom the streamer design, though streamers are essentially audio-dedicated single-board computers, so it's a bit hard for me to imagine a computer board designer badly botching the Ethernet subsystem design, though I suppose anything is possible in this crazy world.

 

I've seen many badly botched board layouts.

Link to comment

I would be curious to know how many streamer designs use discrete PHY chips as opposed to MAC+PHY chips. If the SoC has an integrated Ethernet MAC then the design would need only a discrete PHY chip.

 

What would be an example of a badly botched Ethernet layout? PCB traces/stackup not meeting Ethernet differential impedance spec?

 

 

Sent from my iPhone using Computer Audiophile

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...