Yeah, as described, I have fiber between my router and the Etherregen. I have also experimented with different SFP modules, which certainly to my ears have a more subtle effect than cat6a vs fiber. As I said, Ethernet sounds better to me than fiber in some ways.
I hear you on theory of why an external clock shouldn't sound better. Even if it is a better clock, surely the clock adjacent to the chip would be better than the 75 ohm cable and terminations and distance that comes with an external clock. But it is obviously better with the clock. And maybe that is attributable, as you say, to noise. Certainly other changes have reduced noise.
Different Linux distributions sound different, Ethernet cables, switches, LPS, and soon. It's maddening!
I would certainly prefer a more simple setup and spending less money. My biases work against where I have arrived so far.
|
I tried a few notable examples and I’m not sure they make a difference. Ended up buying the Ether Regen because I thought I heard a difference. A few months ago I rearranged my kit , forgot to plug ether regen and did not realise it. A few days later I realised the error. Adding the Ether regen I found no difference. I tested with and without a few times over multiple days and truly could not hear any difference. Hence I think it is not necessary
|
I have had the Phoenix NET in my system for several years and the improvement is not subtle. Most noticeable is a deeper soundstage and more low level detail retrieval. My system is primarily:
|
@analog that's pretty incredible considering that the Innuos Statement is already an exceptional streamer. The fact that you can hear these improvements is enticing.
|
I have had good luck modifying my Ethernet chain, this thread got me thinking, my AI discussion below.
Yes, handling a noisy or poorly clocked Ethernet signal requires more processing effort and hardware resources than handling a clean one. This increased workload occurs at both the physical hardware level and the higher software/protocol levels. [1, 2]
Why Poor Signals Increase Processing
When an Ethernet signal is degraded by noise or timing jitter, the system must engage several "expensive" recovery mechanisms:
- Complex Signal Recovery: At the physical layer (PHY), the hardware must use more power and complex digital signal processing (DSP) to filter out noise and recover a stable clock from the jittery incoming signal.
- Error Correction (FEC): High-speed Ethernet often uses Forward Error Correction (FEC). A noisy signal generates more bit errors, forcing the hardware to perform intensive mathematical calculations to detect and correct those errors before they reach the main system.
- Packet Retransmissions: If noise is severe enough to cause uncorrectable errors, the Ethernet Frame Check Sequence (FCS) will fail, and the packet will be dropped. This triggers TCP retransmissions, which require the main CPU to manage timers, re-buffer data, and process the same information multiple times.
- Link Renegotiation: Extremely poor signal quality can cause the network adapter to constantly drop and renegotiate the link speed (e.g., dropping from 1Gbps to 100Mbps), which consumes additional management overhead. [3, 4, 5, 6, 7, 8, 9, 10, 11]
Impact on Performance
- Power Consumption: Circuits consume more power when they have to work harder to stabilize a fluctuating clock source or filter high-frequency noise.
- CPU Load: While simple noise is often handled by the network card, the resulting packet loss and retransmissions can significantly increase CPU usage at the operating system level.
- Latency and Jitter: The extra time spent on error correction and waiting for re-sent packets increases network latency and introduces further jitter into the data stream. [2, 4, 7, 10, 12, 13]
Me again. Maybe a clean signal results in less processing on the network card, and less noise inside the streamer?
|
