Nordost Heimdall 2 Ethernet Cable Review

[GryphonGuy]

I am not sure what you are trying to prove here but as usual in hi-fi audio, everything makes a difference. I am not in this for the argument of which is best. I am simply noting my observations. Oh and why record at 32 bit? 24-bit is ample for our human needs.

 

The 315 track has mids and highs smeared. Some say in other reviews that musical notes have air around them. Well in this case there is no "air" or separation of the notes. The sounds are all smeared together to create a "wall" of sound.

 

The nordost track has this "air" and seems to have more "air" than the original until you realise that the low level note decays in the original are missing in the nordost. The transients in the nordost do seem quite close to the original. As one previous contributor said that highs are "harder" or even "louder". I observed this too and I think this is because the original low level sounds are not there. Now whether this was the cable or the recording equipment is anybody's guess. I did note a for few instances of clicks and pops on this sample. Not sure if you were plugging things in/out or clicking switches etc on the RME etc but there were some odd non-audio sounds captured.

 

I actually have this album in the 352.8kHz at 24 bit. So I am familiar with its sounds.

 

You are a brave soul to experiment like this for the benefit of others. Bravo and cheers.

[AnotherSpin]

I had most of my cables from Nordost some time. No ethernet though, only interconnects, USB and speaker. Not anymore, I had more than a single chance to hear much budget cables (for instance Supra USB vs. Nordost Blue Heaven USB) sounds better in my system. Cables do sound different, imho, and expensive ones not neccessarily better than more budget. Nordost gives quite unique sound, imho again, and I believe I became little tired with it over time.

[plissken]

On 9/28/2017 at 5:41 AM, GryphonGuy said:

I am not sure what you are trying to prove here but as usual in hi-fi audio, everything makes a difference. I am not in this for the argument of which is best. I am simply noting my observations. Oh and why record at 32 bit? 24-bit is ample for our human needs.

 

The 315 track has mids and highs smeared. Some say in other reviews that musical notes have air around them. Well in this case there is no "air" or separation of the notes. The sounds are all smeared together to create a "wall" of sound.

 

The nordost track has this "air" and seems to have more "air" than the original until you realise that the low level note decays in the original are missing in the nordost. The transients in the nordost do seem quite close to the original. As one previous contributor said that highs are "harder" or even "louder". I observed this too and I think this is because the original low level sounds are not there. Now whether this was the cable or the recording equipment is anybody's guess. I did note a for few instances of clicks and pops on this sample. Not sure if you were plugging things in/out or clicking switches etc on the RME etc but there were some odd non-audio sounds captured.

 

I actually have this album in the 352.8kHz at 24 bit. So I am familiar with its sounds.

 

You are a brave soul to experiment like this for the benefit of others. Bravo and cheers.

 

I still have the tracks. I'll randomize them for you. Good luck. What is going to be demonstrated is that everything you just typed is going to disappear. 

[fillerf]

funny test  :-)

we where just discussing this cable at work ....  

I assume the traffic in the cable is pure  TCP/IP ???

so if the sound would be different , then the data in the packets would have to be changed and fit to make the sound different when decoded...  very simplified  there is a checksum field  used in the header of every packet to detect corrupted packets. it also keep track of the order of the packets and detects lost packets, also send  an acknowledge back to the sender..

the bandwidth used here for transfer the data   is low compared what we often see in server data center traffic. 

For most people 1 meter is often enough in an audio setup.

a  undamaged standard cat5e/6  cable corrupting packets or  loosing packets is highly unlikely .

If damaged  You could get a weak signal strength and that way corrupt things , but changing the tone or details in the music  well.... no...   

Transmission would basically fail or be so slow because of a lot of retransmission of packets that streaming would fail if it data transfer becomes slower than is the needed minimum 

You can also look at the port statistics on switches and see what type of errors going on. 

most errors we se are packet loss  due to  problem with a damaged cable or interface problem.

Corruptions of packets , sync errors , protocol errors and similar are more often caused by faults in the devices connected to the cables

So if a standard cat5e or cat6 changes packets without being noticed then  these cables would be useless in the IT business and would corrupting  data everywhere. 

 

 

 

[jolon]

1 hour ago, fillerf said:

funny test  :-)

we where just discussing this cable at work ....  

I assume the traffic in the cable is pure  TCP/IP ???

so if the sound would be different , then the data in the packets would have to be changed and fit to make the sound different when decoded...  very simplified  there is a checksum field  used in the header of every packet to detect corrupted packets. it also keep track of the order of the packets and detects lost packets, also send  an acknowledge back to the sender..

the bandwidth used here for transfer the data   is low compared what we often see in server data center traffic. 

For most people 1 meter is often enough in an audio setup.

a  undamaged standard cat5e/6  cable corrupting packets or  loosing packets is highly unlikely .

If damaged  You could get a weak signal strength and that way corrupt things , but changing the tone or details in the music  well.... no...   

Transmission would basically fail or be so slow because of a lot of retransmission of packets that streaming would fail if it data transfer becomes slower than is the needed minimum 

You can also look at the port statistics on switches and see what type of errors going on. 

most errors we se are packet loss  due to  problem with a damaged cable or interface problem.

Corruptions of packets , sync errors , protocol errors and similar are more often caused by faults in the devices connected to the cables

So if a standard cat5e or cat6 changes packets without being noticed then  these cables would be useless in the IT business and would corrupting  data everywhere. 

 

 

 

You may not be aware but there has been an ongoing "bits are bits" debate in the audiophile community for a number of years.

 

The key point is the sound can change even if the bits don't. Audio systems are ultimately analogue. And digital is a concept we have invented but in reality it can be a very noisy system. You can read more about it elsewhere.

 

[plissken]

32 minutes ago, jolon said:

The key point is the sound can change even if the bits don't. Audio systems are ultimately analogue. And digital is a concept we have invented but in reality it can be a very noisy system. You can read more about it elsewhere.

 

Actually he can read about it here at CA. I've posted links to T.I's Radiated Emissions and 10/100 LAN cabling and Siemens' "The Antenna Myth". Both easy to digest. 

 

The effective bit from the Siemens paper is even UTP CAT6 cabling is noise immune up to 30Mhz. The T.I. paper is that the Achilles heal of networking is the unbalanced nature of power. 

 

Ethernet isn't an Audio cable. In your measurements you give no dBfs for the graphs you posted. For all I know you could be so zoomed in that the output would change just based on moving the DUT around the room. 

 

 

[fillerf]

hi Jolon

 

I am very aware of those discussions about bits and bits  , but this test is basically  a test of an ethernet cable running data in a tcp protocol

the bits will be the same  when it comes out in the other end  , its not a one way transfer that that can change a few zeros here and there

if that happens, the the checksum  will not be correct and the packet resent, if its lost it will be resent.

its actually not music when it transferred, just data encapsulated in tcp packets

Its a bit like  sending a real  sealed packet with and address  and description outside on the box ,  plus a tracking number 

and if something is not correct or the packet did not arrive , you ask for a new one 

then You open the package and you find piano sheets music,  then You play the the music (you are the DAC)

if You are a goold player it will sound great, and if You are a bad one then it sounds .........

 

its is basically about moving an amount of data from A to B and the TCP take care of that in safe matter. 

All traffic on the internet , computer networks  , data centers and many calculation clusters uses this standardized protocol that got first documented in 1981. 

The ethernet cable cannot "color" the music. it cannot change the data in the packets to make the sound warmer or colder or clearer.

Yes  a tcp protocol can be interfered/broken, and packet with data can get lost or corrupted  but  the effect  would not be  "coloring" of the music

However after the data has reached the other side and to be handled by chipsets    that is going to make thing go analog again , then things can happen for sure.

 

 

 

 

 

[jolon]

1 hour ago, fillerf said:

hi Jolon

 

I am very aware of those discussions about bits and bits  , but this test is basically  a test of an ethernet cable running data in a tcp protocol

the bits will be the same  when it comes out in the other end  , its not a one way transfer that that can change a few zeros here and there

if that happens, the the checksum  will not be correct and the packet resent, if its lost it will be resent.

its actually not music when it transferred, just data encapsulated in tcp packets

Its a bit like  sending a real  sealed packet with and address  and description outside on the box ,  plus a tracking number 

and if something is not correct or the packet did not arrive , you ask for a new one 

then You open the package and you find piano sheets music,  then You play the the music (you are the DAC)

if You are a goold player it will sound great, and if You are a bad one then it sounds .........

 

its is basically about moving an amount of data from A to B and the TCP take care of that in safe matter. 

All traffic on the internet , computer networks  , data centers and many calculation clusters uses this standardized protocol that got first documented in 1981. 

The ethernet cable cannot "color" the music. it cannot change the data in the packets to make the sound warmer or colder or clearer.

Yes  a tcp protocol can be interfered/broken, and packet with data can get lost or corrupted  but  the effect  would not be  "coloring" of the music

However after the data has reached the other side and to be handled by chipsets    that is going to make thing go analog again , then things can happen for sure.

 

 

 

 

 

If you are "very aware" of the bits are bits debate, can you explain to me the other side of the debate?

[barrows]

@fillerf,  There are enough people reporting actual differences with Ethernet cables that first we should respect their findings, and secondly, why not consider possible causes.  This is speculation, nonetheless:  While I agree that there is not data loss, there may be dropped packets, and those will need to be resent.  The more packet loss, the more resends, the more processor activity, and the more processor activity, the more noise is caused.  The other possibility is that a different cable may have different noise transfer characteristics, perhaps delivering additional noise to the receiver end.

While I agree that these are (potential) problems which should be considered second order in nature, I accept the possibility that the additional noise could upset a connected DAC.

Clearly, more purposeful testing needs to be done in this area.  The mere fact that Networks can differ so much from one another also suggests that such effects would likely be highly Network dependent

[One and a half]

@fillerf, further to Barrows post, the transport of TCP data is an electrical signal, a voltage. Even though the receiver may have isolation transformers, they are not perfect and the voltage is of course data and noise. This noise can travel to the DAC or renderer with little resistance. 

 

How well the noise is transmitted is a function of the cable, source noise and receiver susceptibility. Different format and hardware, but kindred technology to standard audio systems and how they are interconnected. 

 

[plissken]

1 hour ago, jolon said:

If you are "very aware" of the bits are bits debate, can you explain to me the other side of the debate?

 

The other side of the debate is that a high cost boutique cable somehow represents a lower noise voltage therefore causing the PHY on the receiver to require less power to decode the pre-amble.

 

The other argument made is that a high cost boutique cable is somehow less susceptible to outside noise.

 

Fortunately both are specious arguments. Even your own measurements support what I'm saying. Please provide the equivalent dBfs for the 1Khz and 7Khz that the CAT5 and AQ CAT7 exhibited. Also please explain if the noise you measured is in a level audible to humans why 7Khz, which we are more sensitive to, is desirable than the 1Khz on the CAT5.

 

Also why no certifications for either cable so we can know that the cable pass their rated spec. I now know of 3 AQ Vodka cables that don't pass 6A even though they are advertised as 7. Why no certified CAT6 STP and UTP that cost just pocket change to acquire?

 

How do you explain away that a 3 meter cable out of 100 meters that meets spec and is like constructed makes the PHY work harder. In the case of the AQ Vodkas the real argument is since they are marginal for their claimed spec they would actually do worse than a truly certified cable.

 

How does a SCC patch cable improve the SI or lower the 'noise floor'?

[plissken]

2 hours ago, barrows said:

@fillerf,  There are enough people reporting actual differences with Ethernet cables that first we should respect their findings, and secondly, why not consider possible causes.  This is speculation, nonetheless:  While I agree that there is not data loss, there may be dropped packets, and those will need to be resent.  The more packet loss, the more resends, the more processor activity, and the more processor activity, the more noise is caused.  The other possibility is that a different cable may have different noise transfer characteristics, perhaps delivering additional noise to the receiver end.

While I agree that these are (potential) problems which should be considered second order in nature, I accept the possibility that the additional noise could upset a connected DAC.

Clearly, more purposeful testing needs to be done in this area.  The mere fact that Networks can differ so much from one another also suggests that such effects would likely be highly Network dependent

 

I dug into some of the switch stats that we have on our Azure hosted MS Hyper-V cluster running 300 VM's running behind a load balancer.

 

In 192 hours we've transferred 8.1  Exabytes with zero lost packets and 27 re-transmits.

 

In a typical home environment, especially with affordable high throughput wireless it's simply not an issue. I have a 240GB WireShark packet capture over my Wifi with 1 retransmit and zero dropped packets.

 

 

[plissken]

1 hour ago, One and a half said:

@fillerf, further to Barrows post, the transport of TCP data is an electrical signal, a voltage. Even though the receiver may have isolation transformers, they are not perfect and the voltage is of course data and noise. This noise can travel to the DAC or renderer with little resistance.

 

How well the noise is transmitted is a function of the cable, source noise and receiver susceptibility. Different format and hardware, but kindred technology to standard audio systems and how they are interconnected.

 

 

Any sources of information for a $700 3 foot cable being lower noise? The SNR of PAM 16 is 30dB. by audiophile standards it's a disgrace.

 

The reason you don't hear it is it's 125MHz.

 

I look forward to any data about noise on the Ethernet cable that is in the 20Hz to 20kHz range.

 

 

 

 

[barrows]

Why do you think noise transmitted to the receiving end has to be within the audible range to upset things at the DAC?  That is surely not the mechanism which I am referring to.

Personally I have not had time to audition any "audiophile" Ethernet cables, I have always used BJC CAT 6A as a reliable, quality choice.  But considering the number of people who are reporting differences, I do believe this area deserves further exploration.

Additionally, i do not understand all this talk about 1 meter cables, etc.  I use a much longer Ethernet run to my endpoint, as one of the main reasons to use Ethernet connected audio in the first place is to get the noisy commercial computer gear well away (both from an electric and broadcast RFI POV) from the audio system.

[One and a half]

4 hours ago, plissken said:

 

 

Any sources of information for a $700 3 foot cable being lower noise? The SNR of PAM 16 is 30dB. by audiophile standards it's a disgrace.

 

The reason you don't hear it is it's 125MHz.

 

I look forward to any data about noise on the Ethernet cable that is in the 20Hz to 20kHz range.

 

 

 

 

 

Oh. Higher frequencies can and do affect audio frequency reproduction, ya not know that? 

[plissken]

5 hours ago, One and a half said:

 

Oh. Higher frequencies can and do affect audio frequency reproduction, ya not know that? 

 

No they don't. You show me a measurement of a harmonic offshoot of 125Mhz.

 

 

[plissken]

7 hours ago, barrows said:

Why do you think noise transmitted to the receiving end has to be within the audible range to upset things at the DAC?  That is surely not the mechanism which I am referring to.

Personally I have not had time to audition any "audiophile" Ethernet cables, I have always used BJC CAT 6A as a reliable, quality choice.  But considering the number of people who are reporting differences, I do believe this area deserves further exploration.

Additionally, i do not understand all this talk about 1 meter cables, etc.  I use a much longer Ethernet run to my endpoint, as one of the main reasons to use Ethernet connected audio in the first place is to get the noisy commercial computer gear well away (both from an electric and broadcast RFI POV) from the audio system.

 

We only hear the range that we can hear in. What DAC's are having their outputs affected by 125Mhz symbol rate? I'd like to avoid those.

 

What about all the other busses in your rendu? CPU, RAM, PCIe, L1/L2 Cache, USB? How do we know all that noise isn't upsetting the output of the DAC. 

 

What mechanism are your referring to exactly?

[barrows]

2 hours ago, plissken said:

What about all the other busses in your rendu? CPU, RAM, PCIe, L1/L2 Cache, USB? How do we know all that noise isn't upsetting the output of the DAC. 

We pay particular attention in the design implementation of the Rendu products to reduce these noise levels as much as possible.

[plissken]

29 minutes ago, barrows said:

We pay particular attention in the design implementation of the Rendu products to reduce these noise levels as much as possible.

 

What is your process for finding the determinate for what is affecting the DAC's output with all these subsystems interacting on a common PCB ground plane? 

 

I assume that you do this with your Ethernet input also. So if you designed to the spec, and the cable connecting to it is in spec...

[barrows]

12 minutes ago, plissken said:

What is your process for finding the determinate for what is affecting the DAC's output with all these subsystems interacting on a common PCB ground plane?

This interaction is different with every different DAC, so it would be folly to assume that measurements made on one DAC would be accurate for all DACs.  

We work to reduce the noise on the USB output of the Rendu products to the lowest level possible.  

But I am not going to reveal our entire design approach and details, and I do not see what this has to do with the Ethernet cable this thread is about (sorry for the off topic venture).

[plissken]

3 minutes ago, barrows said:

This interaction is different with every different DAC, so it would be folly to assume that measurements made on one DAC would be accurate for all DACs.  

We work to reduce the noise on the USB output of the Rendu products to the lowest level possible.  

But I am not going to reveal our entire design approach and details, and I do not see what this has to do with the Ethernet cable this thread is about (sorry for the off topic venture).

 

That avoids the question: When you measure the output of DACs, any DAC you happen to get hands on, and you see noise:

 

How do you know it's USB packet or symbol rate? Cache operations? IRQ? DMA Xfer, PCI bus snooping, L1/L2, Ethernet, paging file operations? 

 

Would you say the Rendu is susceptible to changes in Ethernet where they are all well within spec? If you have an out of spec horizontal run and you patch in with a $700 RJE does that filter out any Scew? Any NeXT? Interpair inductance?

[barrows]

20 minutes ago, plissken said:

Would you say the Rendu is susceptible to changes in Ethernet where they are all well within spec?

Again, this is OT.  As to the above quote, as I have mentioned, I have not personally tested any "audiophile" Ethernet cables, and we do everything possible to make the Rendu products to be immune to what comes before them.  

But, out of respect to those who do find differences with different Ethernet cables I will not state such is impossible.  I have seen many, many "impossible" things have an actual effect on audio playback in the past, and have learned to keep an open mind.

As I have stated multiple times here, there is enough anecdotal evidence of people finding differences with Ethernet cables to suggest that such is worth looking into more carefully.

[plissken]

Fair enough...

[plissken]

I wanted to follow up with Jolon and see if he was going to answer any questions I had about the measurements he posted. 

 

[jolon]

6 hours ago, plissken said:

I wanted to follow up with Jolon and see if he was going to answer any questions I had about the measurements he posted. 

 

Are you referring to the dBfs comment above?

 

You can see the peak-to-peak measurement in the screenshots. It's the RCA output of the Linn Sneaky MDS so I presume it is probably max ~2V.