GS108 switch ports...

Lol

Spooks,

Whilst in the digital domain, the data are the data (during Ethernet transmission, not actually 1s and 0s, but Manchester encoding, but that's a minor point).  During this transmission the electrical waveforms representing the data are contaminated by RFI, not to the point of changing the digital data represented, but it's there at a low level none the less.

How the DAC chip is connected may affect the nature of the RFI it sees, but it will always see some RFI along with the digital data.  As the DAC is an electrical device it will conduct some of the RFI on its input to its analogue output, and this will disturb the following analogue amplifier stages.

In the case of a UPnP streamer the Ethernet cable picks up RFI and introduces this into the streamer box.

If the streamer has it's own DAC, that RFI is conducted to the DAC chip and analogue output amplifiers of the streamer.

If the streamer is connected to an external DAC, via S/PDif, the RFI both disturbs the S/PDif signal by adding jitter, and is also conducted along the digital interconnect to the DAC box.  Once inside the DAC box, the RFI is conducted to the DAC chip and analogue output amplifiers of the DAC box.

In both cases the RFI in the Ethernet cable disturbs the analogue output.

I have never said that the RFI has any effect on the data, only on the analogue signal that's output after the DAC.

So you're never going to be able to stop RFI completely obviously... it is the enemy of all electrical communication.

You are only dealing with the first layer of the OSI model here, in order to make things bit perfect we need to go further up the OSI model so the data/payload is sanity checked at both ends. So yes I agree you're always going to get RFI in the Manchester encoding, however it does actually in turn get changed into the 1's and  0's further up the stack. At this point the data is consistent and it gets delivered bit perfect.

So, a question for you just to check your beliefs.

1) Do you think a standard shielded cat 5e or cat6 cable is inferior and will therefore audibly sound inferior to an audioquest one?

2) Do you believe data is directional and it matters which way you connect it?

I believe the point we are trying to prove is whether or not you'd be better keeping your money in the bank rather than spending £100 on a patch cable.

If you've ever been to a data center, you should see the state of some of the cabling and what is used... Most don't use any kind of shielded cabling and there are some massive sources of RFI in those places.

We are not "only dealing with the first layer of the OSI model", we also have delicate analogue amplifiers in the system.

In direct answer to your questions:

1)  In terms of the digital data communicated (given that we have 100BaseT comms), there will be no difference.  However UTP cables (Cat5e or Cat6) will deliver more RFI into the active circuitry of the streamer's Ethernet port than SSTP cables (Audioquest and some other CatX cables).  RFI on the data lines is more likely to be conducted through to sensitive analogue stages.

2)  In terms of the digital data communicated (given that we have 100BaseT comms), there will be no difference.  However there is a theoretical possibility that the frequency distribution of the RFI may be affected by manufacturing variances in the cable.

I believe that in some domestic settings there won't be an audible difference between a Cat6 SSTP cable and an Audioquest Ethernet cable, however in other domestic settings where the levels of RFI are higher or have a different frequency distribution, there will be an audible difference.  The same applies to Cat5e UTP, but there is a greater chance of a difference being detected.

P.S. in terms of data centres, I recently worked as an IT systems designer for a clearing bank, so yes I know about the practical robustness and tolerance of Ethernet.  However those systems don't have delicate analogue amplifiers hanging off the end of them, so they don't have the same inherent vulnerability to RFI as occurs in high quality audio equipment.

Chuckle - trying being an ICT/Computer engineer like me - then its fun. The real world reality of physics mixed with the idealised world of abstraction from computer scientists confused by the dumbed down world of consumer IT

One should not invest too much faith in theory until it's confirmed by practice.

One should not invest too much faith in practice until it's confirmed by theory.

Just one last thing though.... how is it possible to do real time data replication using something like VMWare vSphere fault tolerance (I.E I move my mouse on one VM and then the mouse move and any user input is replicated on another VM) - bearing in mind this could in theory be Virtual machines located in different cabinets in the same datacentre, having to traverse all sorts of networking equipment and requiring incredible bandwidth (10gb ethernet). Surely that requires completely bit perfect transmission otherwise it fails.

Or I could send someone the raw data for say Human DNA and it would arrive bit perfect at the other end? Yet, if I send a 25mb flac file (not stream) because I have already explained that media players play from memory (mostly) and don't 'stream' it will somehow sound different on different network cables.

Please limit the above to purely network cables as that is what this is about. Also, in reference to the comment regarding AMP sitting off the network cables. They don't.... the PERFECT binary data goes into the DAC, converted to analogue and then on to the AMP usually via usb or tos.

+1 to your post Huge.   I love the quote below as it describes arguments still going on today. 

"If it measures good and sounds bad, -- it is bad. If it sounds good and measures bad, -- you've measured the wrong thing." 

Daniel  von Recklinghausen, Chief Engineer, H.H. Scott (inventor of the EMIT tweeter....and many other things hi-fi) 

Spooks, I am not sure we are / were talking data integrity. In absolute terrms in your audio example data timing is key.

Now in the data world as I am sure you know timing and priority can and usually be determined by DSCP markings in the packet. So in the data centre example you give, if we were sharing a trunk with VLANs or even within a single VLAN   between replication/virtualisation data and say a SIP controlled voice channel I would need to prioritise my RTP data packets containing my voice audio samples (regular PCM if using G711 encoding) over my replication packets. I might not loose any data and everything remains bit perfect, but if my RTP data packets are randomly delayed beyond a certain tiny amount of time perhaps caused by excessive congestion or in appropriate configuration my bit perfect voice stream may turn into a Dalek sounding garble.. But all my data has remained totally bit perfect... 

But I believe earlier we, or at least I was , talking by RF radiation caused by imperfections in the Ethernet twisted pair transmission lines from different Ethernet patch lead types which is a different matter... perhaps you found the Texas Instruments engineering guide on the subject interesting?

Simon

I honestly don't even know where to begin with that, actually quite amusing.... Oh dear oh dear. Look - I tell you what, I'll leave the Audioquest 'directional' network cables to you because clearly I don't know what I'm talking about.

Spooks, I am not on about so called directional Ethernet audio cables from Audioquest.. I also find the concept suspect and feels ridiculous. I am pointing out there are many aspects to a digital systems performance in the audio world.. But just because the real world is not always straightforward it doesn't mean I agree to ridiculous marketing statements and mumbo jumbo. But clearly you can hopefully see how both expensive and cheap Ethernet leads can both equally cause a difference in the SQ if RFI coupling to the connected audio components is at play.

Simon

Spooks, you seem to be missing Simon's point... We live in an analogue world (I'm ignoring quantum physics here...) and virtually all digital systems make use of analogue transmission levels. Whilst the transmission at a digital level may be perfect, there can still be an adverse influence on downstream analogue components - especially audio, where our ears seem particularly good at detecting anomalies.

Over 30 years experience in IT - Head of Architecture, CTO etc. completely agrees with your DataCentre example, but try sitting in a DC with a sensitive audio component and convince me that it's completely immune to the combined RF interference...

ATB, Dave.

Blimey Dave all way above my head here - how's it going with you!!

Hi Dave,

Yes I can accept that there will be RF interference, I'm not disputing that. Whether we can actually here that is another question. The brain is an incredibly powerful thing and has the power to sway your opinion if you are expecting something to sound better.

What would be interesting is a double blind test to find out if it was possible to detect a difference. The only way to put any argument like this to bed fully is by way of a properly conducted scientific experiment. Personally I am dubious as to whether anyone has the ability to decipher between network cables especially since this is toward the bottom of importance versus the rest of the components involved (Amplification, Power supplies, DAC, Speakers).

In my opinion you would have to have dog like hearing to tell. Furthermore, I am of the opinion that I stated very early on - is that if you buy a sufficiently well made cable (really anything that conforms to the standards) it should be more than sufficient in a home environment.

Regarding Simon's post I really didn't want to get involved in comparing networking e-peens. I know what I'm good at and like you I have an extensive technical background and it is a futile process demonstrating it. It is clear that the comments made by all parties are well thought out and come from intelligent folk.

I really do take my hat off to people who can pass a double blind test and tell the difference between a regular cable and a 'special' one. I do not think it possible but I am open to the possibility I could be wrong. My ears really aren't that special.

Thanks.

I'm very well Pete - I'll drop you an email shortly...

Great got some news that you'll like hearing and a hearing session that you'll want to be at!!

I have no doubt whatsoever that you can hear rf interference.  Running my windows server through my Hugo you can very very clearly hear it as a high pitched signal through the speakers and as a bright sound to the music.  The mac mini through exactly the same set up with the same cables and the same socket sounds totally different with only a very slight hiss through the speakers and a much weightier sound.  Friends who have no interest in hifi were very easily able to tell the difference between the two sources

Intriguing... You have mail.

Spooks, sounds like we are agreeing then. The problem with double blind tests in this scenario is than for me to detect a change takes time. A / B swapping never works, but if I relax and listen over time I can become aware of feeling stressed or uncomfortable if something is not right. Whether I could spot a different Ethernet cable is debateble, but I am prepared to believe that there are detectable changes if one is prepared to listen long enough.

Funny you should say this I had a client using VMware clients where we had exactly this issue with mouse movement and delay and lack of fluidity on a VMware client. Now VMware uses its own private data prioritisation class methods and so doesn't tend to rely on TCP/IP DSCP. However starve the VMWare of its required bandwidth it will not be able to internally prioritise its data and therefore it will be unable to manage its data type queues. Give it sufficient bandwidth and the internal queue prioritisation can be effectively achieved.

Its not about being just bit perfect. Its about being bit perfect and appropriately timed for many applications. This is achieved by managing the class of service required for the data type.

Simon

Equally applies to desktop virtualisation: Data, applications and main OS on a server in the EU, desktop rendered on a remote PC or thin client anywhere in the world - helps compliance with the EU data directives whilst allowing users to be located outside the EU.

Wat,

What do you prefer to Ethernet?

S/PDif:  Fully synchronous - real-time & jitter prone (particularly when using consumer grade optical links or in presence of RFI)

USB:  Passing near real-time data over a non real-time link and hope it works OK

Async USB:  Essentially all the same processing overheads as Ethernet!

Wat - I don't disagree with your sentiment - and of course it equally applies to USB cables where similar things are at play - although by design of the USB link control is worse than Ethernet for noise emissions.

But this is why I believe there is great merit in decoupling the DAC from the streamer. Since I have done this I have found the affect of the Ethernet variables and even FLAC vs WAV becomes minimal to even none existent at times. In this setup the prime element is the accuracy and stability of the streamer clock. (which of course can still be modulated through RF noise)

I think these interactions and other side effects become more pronounced when equipment is closely coupled through shared earth planes, powerlines , EM coupling stray capacitance. These last two are affected by physical distance.

Simon

100% Wat,  this is touched in another thread, TQ don't give specs

Ethernet seems to have one particular make who's prose in voodoo has to be read to be believed,  believed as in I really don't believe an electrical company can write such crap; & it's a shame 'cause it's not a bad cable in both material quality & SQ terms. Shame about the pricing - but thats a whole other post-thread

I selected my ethernet 'cause it sounded better than basic Cat5 & I could not hear a difference between it & another at >2x the price.

Plus this cable cmpy gives specs that not only tell me about materials & construction,  but the electrical properties tell me how it can perform as an ethernet.  

Bandwidth: 1300 MHz

Skew @ 100MHz: 5ns/100m

Resistance: 57.1(Ohm/km)

C: 40(pF/m)

Imp. Z: 100Ohm

Velo Factor: 0.8c

Huge, I would say these days Async USB and SPDIF are more similar than TCP. The DAC clock is very rarely (I cant think of one design instance) derived directly from the SPDIF transport clock these days.

Ultimately most modern SPDIF implementations effectively work asynchronously. If you over run or deplete the receive buffer due to miniscule clock variances between sender and receiver clocks you will get a moment of silence over an extended period of time.

On Async USB similar things are at play - but here the receiver can signal the sender to send slightly larger frames of data or if the buffer is near empty or it can signal the sender to reduce the  size of the frame of data slightly within a given time slot. This way as long as the two send and receive clocks are approximately similar the receive buffer can be regulated.

SPDIF the frames are constant - and the time slots are derived by the transport frequency which is a function of the bandwidth required to be transmitted - which is determined by audio sample type payload.

With Ethernet using TCP then we have complete asynchronous two way flow control and resend capability and can even cope with the frames being received out of order... and there are several levels of buffer/window indirection.

Simon