Torben: I have several Ghent DC cables, and they’ve become my go-to whenever I need a new one. Standard free shipping is reasonably speedy, they’ve been very nice to deal with, and the cables are well made as far as I can tell.
I get the JSSG360 shielded ones in their 4S6G(OFC) form. Happy, and as @TheFlash says they’re not carrying any data 
Excellent! Glad to hear it 
Torben, is the Ethernet cable shielded or unshielded?
Hi @Omni - Yes it is:
Belden 1303E CatSnake CAT6A Ethernet Cable, JSSG360, Metz Connect CAT6A fully shielded plug (dual-shielding protection) (shielding loop - no shielding connected to metal plug)
Torben
Thanks for your tip 
Just bought an additional 1 meter from ROCK/Roon server to may switch - WOW!
Torben
PS: Now I am thinking about buying 3 meter from wall socket to switch
Thanks for sharing, @torbenrick. I am keen to understand what this means as it appears to be self-contradictory (my misunderstanding I’m sure): “dual-shielding protection - shielding loop - no shielding connected to metal plug”
Thanks.
Belden 1303E CatSnake CAT6A ethernet cable, JSSG360, dual straight-plugs 8P—8P, Metz Connect CAT6A fully shielded plug (dual cable-shielding protection - shielding loop - no cable-shielding connected to metal plug)
Two layers of copper shield mesh to protect cable from the complicated EMI (Black sleeved)
The inner shield and the outer shield are connected together on both ends to be a closed loop shielding, but not connected to any metal shield/not connected to the plug
Torben
Thanks Torben. So dual-shielded and shielding loop refer to the inner and outer mesh, and the shield is completely floating. I understand now… except:
My (partial, emerging!) understanding is that a shield works by redirecting any noise to ground, so if there is no ground then there is no effective shield (and performance will be same as an unshielded cable). Am I missing something?
Nost sure what to think about this:
“In the case of a pure optical input (zero metal connection), this does block leakage current, but it does not block phase-noise affects. The optical connection is like any other isolator: jitter on the input is transmitted down the fiber and shows up at the receiver. If the receiver reclocks the data with a local clock, you still have the effects of the ground plane-noise from the data causing threshold changes on the reclocking circuit, thus overlaying on top of the local clock.”
Torben
He might have something there about ground plane noise but… is jitter actually a thing in ethernet? I’m not sure I recognise the term in that context. And even if it is, it certainly won’t/can’t have any impact on sound quality. Also what is this phase-noise thing?
Respect Mr Swenson that I do, he seems to be conflating the ethernet and bitstream worlds in ways he really shouldn’t. I haven’t read the paper but I have a sneaking suspicion he’ll talk about the importance of ethernet clocks to sound quality… and that would set alarm bells ringing.
EDIT: oh dear. It’s not far into the paper where we get this:
“We are going to explain how jitter of the clock—e.g., in a network switch—will show up in the data coming out of that switch, even though no separate clock signal is transmitted with the data. And we will explain how this gets into and affects the DAC-attached endpoint.”
That “White paper” is, unfortunately, full of pseudoscience gibberish. 
(it’s been discussed a number of times here on the forum)
@Anupc - It would be nice to know if you agree with the below statement:
"Neither an SFP module nor an SFP+ module by itself, knows anything about speed or protocol of the signal going through them. There is no clocking going on in the module itself. There is no auto-negotiation speeds or anything like that happening at all.
All of the above happens in circuitry on the board containing the SFP cage, NOT in the module itself.
The SFP+ connector interface is exactly the same as the SFP interface except for one pin. The SFP+ was specifically designed so an SFP+ module WILL work in an SFP cage. This means that as long as SFP+ modules meet the specs they will ALL work in SFP cages.
The one thing that will NOT work, is if the boxes are running at different speeds. Since there is no auto-negotiation you cannot have a switch with a 10GbE port, connected to a device with a 1GbE port. Since the speeds of the BOARDS don’t match, they will not talk. Plugging SFP+ modules into SFP cages on both sides WILL work for ALL SFP+ modules, as long as you use identical modules on both sides."
If I understand this correct: A SFP+ can be used in a 1GbE switch of FMC without any problems?
BIG thanks
Torben
Well, the SFP+ specifications (SFF-8431) states that lower speed transmissions may be supported.
That “may” suggests that it’s left to the SPF+ manufacturer’s discretion. While that 2nd paragraph indicates that SFP+ cages are designed to accommodate SPFs, but not necessarily vice versa!
In any case, it may very well work in some cases, but why would you want to plug a more expensive/higher-speed capable SFP+ into an SFP cage?!? 
There’s no inherent benefit.
The discussions on other forums about various SFPs or SFP+s “sounding different” is just absolute rubbish (from overactive auditory imagination). There’s no direct relationship between the PCM/DSD data encapsulated within TCP streams over Ethernet frames, to electro-optical links. Imagine if I said the colour or size of an envelop changes the contents of the letter inside. It’s totally absurd 
THX
Not me But at the moment, there is a BIG hype for getting SFP+ in audiophile circles. Due to the laser quality in SFP+ it should have lower jitter.
Torben
As Nigel indicated above, jitter has absolutely no relevance whatsoever to sound quality in the context of an SFP/SFP+ transmission.
Ethernet packets are electro-optically transmitted over SFP/SFP+ completely asynchronously. In that context, jitter has no relevance because the Ethernet packets at the receiver are buffered, then unpacked into TCP streams (usually HTTP for UPnP), which is likewise heavily buffered (windowing/error-correction), which is then unpacked into PCM/DSD data.
People who are suggesting that SFP/SFP+ makes a difference in sound quality because of “jitter” have very vivid imagination🫨, they’re conflating the impact of jitter on synchronous interface like TOSLink and assuming the same thing applies to SFP/SFP+. It doesn’t.
There is a famous song from Kate Bush: “Running Up That Hill” - it will be the same trying to convince these people about that
For me it is a absolut mystery why people than claim that they can hear a difference an prefer Finisar over other good SFP’s. I don’t get it.
Torben
What don’t you get? If many other “good SFP’s” are Finisars under the cover then it’s a value for money thing: why pay more for exactly the same device rebadged? I’m not sure I’ve read of many people thinking the Finisars sound better; most I’ve read is that they sound just as good.
Having said that, I would be delighted to sell you one of my new, painstakingly R&D’d and entirely imaginary SFP modules which I call the Rasinif*. Guaranteed to match or excel the performance of any Finisar or equivalent SFP, with the added bonus of being directionless .
*use a mirror if required!
Two things.
As @Anupc confirms, jitter in EthernetWorld is simply not a thing. Here in UK we would call it a “red herring” but I’m not sure whether a Dane might know of an actual Red Herring which is as delicious as all the other herrings I’ve eaten in Copenhagen… 
If there is anything behind the hype (and I doubt it), it will be in a pair of SFP+ capable FMC’s, not simply a vanilla FMC which can (should/might) be compatible. But I really think there is a lot of imagination going on here and even if you replaced your FMC’s with SFP+ capable ones, you wouldn’t hear a difference.
Don’t even try. Any attempt to educate/convince them would be considered a personal attack against their beliefs.
You don’t have to look very hard. The most egregious are audiophilestyle and whatsbestforum, both (especially the former) with individuals with significant commercial interest involvement.
