Fiberoptic Ethernet and bits on the wire

[jabbr]

I'm posting this because I am significantly changing my position on 1GbE vs 10GbE+ regarding network audio transmission.
This is essentially a cross post from https://audiophilestyle.com/forums/...hernet-clock-phase-noise-on-the-ground-plane/ which has some additional motivation and links to code (I don't see how to post python files here)

First of all I use 10GbE+ because it supports PTPv2 even though I don't use PTPv2 for stereo and I like pro grade stuff. I've never been able to hear a difference among different quality devices.

Any benefit to fiberoptic ethernet is entirely due to blockage of common mode noise transmission.

I had thought, and posted on audiophilestyle, that because 10GbE+ implements SRS (stressed receiver conformance test) that we could be sure that jitter didn't pass across an Ethernet link. Turns out that's irrelevant ... highly highly relevant.

So I ran some models and it turns out that network speed (1G,10G,25G,100G) is essentially irrelevant nor does phase noise/jitter matter at all...

 

[kemmler3D]

I guess a non-audible impact is expected, but in practice, don't the audio data packets get buffered again at least once or twice before an analog signal is rendered?

 

[audio_tony]

I guess a non-audible impact is expected, but in practice, don't the audio data packets get buffered again at least once or twice before an analog signal is rendered?

As far as networking is concerned, it's just data and not 'audio packets'.

TCP/IP doesn't know what is being sent over the wire (or WiFi).

Or am I stating the obvious here?

 

[kemmler3D]

As far as networking is concerned, it's just data and not 'audio packets'.

TCP/IP doesn't know what is being sent over the wire (or WiFi).

Or am I stating the obvious here?

Yes, definitely, I'm just wondering on top of that what the validity of OP's analysis is in context with the way DACs actually work in practice. It looks like this is a modeled outcome (which still shows drastic inaudibility) but DOES any ethernet phase / jitter actually propagate through to the analog signal in practice? Do any streamer / DAC combinations actually work like this? I've generally gone under the assumption that they don't, but I can't claim to have actually gone in and checked.

 

[voodooless]

The audiophilestyle topic cites a white paper by UpTone Audio, who sell audiophile networking bullshit.

It tries convince readers that jitter would cause noise in the ground plane. But as per usual with these so called white papers, they uses legitimate mechanisms, turns them on it’s head, claim audible difference, but do not show any evidence to back it up.

Hitchens’ razor applies!

 

[jabbr]

I guess a non-audible impact is expected, but in practice, don't the audio data packets get buffered again at least once or twice before an analog signal is rendered?

I used worst case assumptions. FWIW I have heard significant hum through connections/common mode noise/ground loops. I've been under the assumption that buffering etc works, yet the model is rather definative

 

[jabbr]

Yes, definitely, I'm just wondering on top of that what the validity of OP's analysis is in context with the way DACs actually work in practice. It looks like this is a modeled outcome (which still shows drastic inaudibility) but DOES any ethernet phase / jitter actually propagate through to the analog signal in practice? Do any streamer / DAC combinations actually work like this? I've generally gone under the assumption that they don't, but I can't claim to have actually gone in and checked.

So, right, there is drastic inaudibility.

Conversely with copper ethernet, common mode noise might get in and interfere ... thats a ground loop. Hospitals use ethernet isolators because ground loops/common mode noise can cause safety issues when an electrode is in the heart ... that is to say, the electronics are there

Now does ethernet phase/jitter actually propagate ... it has never ever been measured to, and the model pretty much explains why ... so in the absence of evidence to the contrary: no!!

 

[jabbr]

The audiophilestyle topic cites a white paper by UpTone Audio, who sell audiophile networking bullshit.

It tries convince readers that jitter would cause noise in the ground plane. But as per usual with these so called white papers, they uses legitimate mechanisms, turns them on it’s head, claim audible difference, but do not show any evidence to back it up.

Hitchens’ razor applies!

This is a persistent meme used to sell people clocks that they don't need. Trying to debunk... one mind at a time

 

[voodooless]

This is a persistent meme used to sell people clocks that they don't need. Trying to debunk... one mind at a time

Sadly, your modeling won’t convince many of the prospective buyers. It’s a valiant effort nonetheless!

 

[Hayabusa]

Any benefit to fiberoptic ethernet is entirely due to blockage of common mode noise transmission.

normal 1GbE twisted pair should also not pass common mode signals:

 

[jabbr]

The audiophilestyle topic cites a white paper by UpTone Audio, who sell audiophile networking bullshit.

It tries convince readers that jitter would cause noise in the ground plane. But as per usual with these so called white papers, they uses legitimate mechanisms, turns them on it’s head, claim audible difference, but do not show any evidence to back it up.

Hitchens’ razor applies!

I've been arguing the lack of evidence for years ... I found a single paper (Heydari/Pendram ... which was a model) whose title suggested that phase noise could cause ground plane noise, but the paper itself didn't find that... I combined their model with very generous assumptions about non-linearities which could down-fold the phase noise into the audible spectrum etc so really giving the benefit of the doubt.. and the model is literally 10 orders of magnitude below audibility ... zero effect in the real world (i.e. a charge cannot be less than an electron). There is a very good reason there is no evidence to back up the marketing 'theory' because its essentially impossible

 

[jabbr]

normal 1GbE twisted pair should also not pass common mode signals:

whelp ... POE is common mode so ... TP passes common mode, so not so simple

 

[voodooless]

whelp ... POE is common mode so ... TP passes common mode, so not so simple

And the fact that you don’t blow up a non POE receiver with a POE enabled source means it effectively filters out common mode signals just fine. POE stuff happens before the isolation transformers.

 

[pablolie]

IF your network has packet loss when it comes to the very modest network needs audio traffic has, throw away every switch and router and replace them with something that isn't garbage. Simple.
It'll cost you little these days.
Audio doesn't benefit from getting 10G speeds at all, or cabled via copper or fiber vs Wifi. It has never mattered. I started to stream music at my place when 802.11b back in the very early 2000s -6 Mbps of usable bandwidth- and it worked perfectly.
And audio networking doesn't have to be TCP/IP. There are other protocols that work just fine.

 

[fatoldgit]

So lets look at some basic facts:

- all ethernet devices contain buffers that do a "store and forward" of the packets which enables resends as needed
- all ethernet devices contain a clock
- 1gbit (100 Mbyte per second) has more than enough headroom for a 200kbyte to 1Mbyte per second audio stream
- copper ethernet transceivers use transformers to shunt noise
- copper ethernet has a differential topology to suppress EMI/EMF along the cable
- tcp/ip is an async protocol (unlike say rs232 or sp/dif) so out of order packets, should that occur, is a non issue

If anyone is concerned about electrical isolation/noise reduction after considering all of the above, then buy two TP-LINK MC200 media convertors and a 62.5u SC/SC OM1 fibre lead. Total cost < $US 100

this looks like:

ISP router -> copper ethernet -> MC200 -> fibre lead -> MC200 -> copper ethernet -> Audio Endpoint (dac/streamer)

Specifications of the MC200 are:

• Standards and Protocols: IEEE 802.3ab, IEEE 802.3z, IEEE 802.3x
• Basic Function: Full Duplex Flow Control (IEEE 802.3x)
• Extends fiber distance up to 0.5km using 50/125um fiber
• Extends fiber distance up to 0.22km using 62.5/125um fiber
• Ports: 1x 1000M SC port; 1x 1000M RJ45 port (Auto MDI/MDIX)
• Wave Length: 850nm
• Network Media 1000BASE-FX: Multi-mode Fiber
• Network Media 1000BASE-T: UTP category 5, 5e cable (maximum 100m); EIA/TIA-568 100? STP (maximum 100m)
• maxium power draw is 1.7W

Note that you have the option to run a long ethernet cable or long fibre cable to the MC200 that is next to your audio endpoint: The key point is that doesn't matter in this context because you will use a 0.5m ethernet cable from the second MC200 in the chain to your audio endpoint.

Also note that with a 62.5um fibre cable you can have a distance of 220m between your ISP router/first MC200 and the MC200 that is next to your audio endpoint which more than covers the length of your typical billionaire super villians secret hidden mansion.

If super paranoid, power the MC200 that is next to your audio endpoint with an LPS

What this means is:

noise

the MC200 only draws a max of 1.7W (i.e. internal intrinsic noise is tiny) and because the ethernet cable between the MC200 that is next to your audio endpoint and the end point is 0.5m, induced EMI/EMF along the cable is zero, on top of all the other noted noise suppression "stuff" intrinsic in copper ethernet

clocking

because the MC200 that is next to your audio endpoint has it's own packet buffer and clock, there is no need to sweat the need to reclock the signal over and above that provided by all network devices. Also because out of order packets can happen, reclocking won't change that... the packets could potenitally reach the next device in the chain out of order.

But that doesn't matter cause tcp/ip at the final end point (which contains a big arsed OS with a big arsed tcp/ip buffer stack) will reorder the packets and present these in order for whatever is consuming the packet stream (in this case the audio player)

Peter

(30 years experience developing mission critical, high throughput tcp/ip data interchange software)

 

[fatoldgit]

I live in New Zealand and I stream Qobuz.

When I stream Qobuz, my end point (the data center that Qobuz streams from) is ec2-54-77-163-178.eu-west-1.compute.amazonaws.com (determined via monitoring network requests with iftop which is a Linux command line utility)

If I traceroute this, it goes through six network gateways inside New Zealand, (seven hops in total) then to two in Sydney Australia then Singapore then four in France (across two cities, Paris and Marseille) then onto Dublin in Ireland ... a total distance of at least 18,660 km (which is the point to point distance between me and Dublin.. doesnt account for the sideways part to Aussie etc)

Audiophiles obsess over inhome network stuff (and of course wifi can be an issue) and yet in my case I can stream Qobuz (via a slow copper based VDSL internet connection... 25mbits down/5mbits up) with no issues despite the tcp/ip packets traveling over 20,000 km and traversing many more network devices than the traceroute shows (traceroute only shows the routing boundaries traversed and not other networking devices the packets pass through inside an ISP or datacenter)

Ethernet (unlike serial connections) runs on a "store and forward" protocol. A packet gets sent, the next device in the chain gets it and stores it and then sends an acknowledgement that it received it ok back to the sender.

If the sender doesn't get the acknowledgement in a specified time it resends... if it does get an acknowledgement, it drops the packet from it's memory (depends on type of acknowledgement..see below)

Packets all have a set size and each packet has a header and a checksum. The receiving device checks for malformed packets.... is it the correct size, does the header have integrity and then does the packets recalculated checksum (done by the receiving device) match that spec'ed in the header. If not, a resend request is made.

So if a packet goes through 100 devices, each device checks it's ok, sends it on and forgets it or retries the resend until it's ok.

Note the above "life of a packet" is a high level overview and so some deep technical points have been ignored for brevity (like packets for frames etc) nor do I differentiate what role ethernet plays verses TCP/IP.

In relation to clocking, whatever was the last network device that a packet passed through (ISP router,local NAS, local server) has already reclocked the packet (each device has a clock) so it's good to go.

This is not serial transmission where by reclocking can help.

The only thing that can bugger up inhome ethernet is flakey wifi or a bad ethernet cable and reclocking doesnt help these issues.

Below is the traceroute and I have added in the non-New Zealand locations in capitals, next to the route hop.

Note the last value on each line is the transmission time for that hop and you will note they are all different

This transmission time is analogous to jitter in serial protocols but is of no concern in ethernet... where as a serial protocol would die with jitter of 1/3 or 1/2 of a second

The clock in a network device is only for internal reference, no device in the chain cares about the clock in the devices before or after it ****

This mean the transmission time between network devices is not important nor do network devices need to be "sync'ed" to a master clock nor is a higher precision clock needed somewhere in the chain... as long as the next decoded packet needed by your streamer/pc/dac is in it's buffer in time for playback that's all that's needed


1 _gateway (192.168.1.254) 0.412 ms 0.466 ms 0.514 ms
2 203-114-134-244.lo.sta.inspire.net.nz (203.114.134.244) 15.381 ms 15.372 ms 15.348 ms
3 203-114-134-200.lo.sta.inspire.net.nz (203.114.134.200) 15.340 ms 15.327 ms 15.363 ms
4 203-114-190-44.sta.inspire.net.nz (203.114.190.44) 15.980 ms 203-114-150-178.ge-0-1-5-1143.wlg-br.inspire.net.nz (203.114.150.178) 15.347 ms 16.383 ms
5 203-114-149-86.sta.inspire.net.nz (203.114.149.86) 27.651 ms 203-114-150-70.sta.inspire.net.nz (203.114.150.70) 21.050 ms 21.043 ms
6 203-114-149-34.sta.inspire.net.nz (203.114.149.34) 23.590 ms 203-114-148-34.sta.inspire.net.nz (203.114.148.34) 47.013 ms 46.426 ms
7 203-114-134-220.lo.sta.inspire.net.nz (203.114.134.220) 44.478 ms 43.692 ms 43.674 ms
8 AUSTRALIA SYDNEY te0-3-0-7.agr51.syd01.atlas.cogentco.com (154.18.97.57) 44.908 ms 44.884 ms 44.859 ms
9 AUSTRALIA SYDNEY be3578.ccr71.syd01.atlas.cogentco.com (154.54.47.17) 44.851 ms 46.291 ms 46.282 ms
10 SINGAPORE be2546.ccr31.sin01.atlas.cogentco.com (154.54.1.29) 137.237 ms 136.775 ms 137.216 ms
11 FRANCE MARSEILLE be2914.ccr31.mrs02.atlas.cogentco.com (154.54.87.210) 275.817 ms be2919.ccr32.mrs02.atlas.cogentco.com (154.54.87.214) 275.921 ms 275.043 ms
12 FRANCE PARIS be2780.ccr42.par01.atlas.cogentco.com (154.54.72.225) 300.966 ms 301.949 ms 300.890 ms
13 FRANCE PARIS be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) 311.823 ms 311.797 ms be2103.ccr32.par04.atlas.cogentco.com (154.54.61.22) 301.852 ms
14 FRANCE PARIS * * amazon.demarc.cogentco.com (149.6.164.250) 310.203 ms
IRELAND DUBLIN ec2-54-77-163-178.eu-west-1.compute.amazonaws.com

Peter


**** where some "thing" in a computing environment needs to be sync'ed to a master clock, this is done via ntp (Network Time Protocol) and ntp is a protocol that runs over tcp/ip so this is an amazing thing... a precision master clock that keeps devices/databases/applications in sync yet it runs over a non-precision (relative to time) protocol. ntp is accurate to a few milliseconds

 

[pablolie]

I live in New Zealand and I stream Qobuz.

When I stream Qobuz, my end point (the data center that Qobuz streams from) is ec2-54-77-163-178.eu-west-1.compute.amazonaws.com (determined via monitoring network requests with iftop which is a Linux command line utility)

If I traceroute this, it goes through six network gateways inside New Zealand, (seven hops in total) then to two in Sydney Australia then Singapore then four in France (across two cities, Paris and Marseille) then onto Dublin in Ireland ... a total distance of at least 18,660 km (which is the point to point distance between me and Dublin.. doesnt account for the sideways part to Aussie etc)

Audiophiles obsess over inhome network stuff (and of course wifi can be an issue) and yet in my case I can stream Qobuz (via a slow copper based VDSL internet connection... 25mbits down/5mbits up) with no issues despite the tcp/ip packets traveling over 20,000 km and traversing many more network devices than the traceroute shows (traceroute only shows the routing boundaries traversed and not other networking devices the packets pass through inside an ISP or datacenter)

Ethernet (unlike serial connections) runs on a "store and forward" protocol. A packet gets sent, the next device in the chain gets it and stores it and then sends an acknowledgement that it received it ok back to the sender.

If the sender doesn't get the acknowledgement in a specified time it resends... if it does get an acknowledgement, it drops the packet from it's memory (depends on type of acknowledgement..see below)

Packets all have a set size and each packet has a header and a checksum. The receiving device checks for malformed packets.... is it the correct size, does the header have integrity and then does the packets recalculated checksum (done by the receiving device) match that spec'ed in the header. If not, a resend request is made.

So if a packet goes through 100 devices, each device checks it's ok, sends it on and forgets it or retries the resend until it's ok.

Note the above "life of a packet" is a high level overview and so some deep technical points have been ignored for brevity (like packets for frames etc) nor do I differentiate what role ethernet plays verses TCP/IP.

In relation to clocking, whatever was the last network device that a packet passed through (ISP router,local NAS, local server) has already reclocked the packet (each device has a clock) so it's good to go.

This is not serial transmission where by reclocking can help.

The only thing that can bugger up inhome ethernet is flakey wifi or a bad ethernet cable and reclocking doesnt help these issues.

Below is the traceroute and I have added in the non-New Zealand locations in capitals, next to the route hop.

Note the last value on each line is the transmission time for that hop and you will note they are all different

This transmission time is analogous to jitter in serial protocols but is of no concern in ethernet... where as a serial protocol would die with jitter of 1/3 or 1/2 of a second

The clock in a network device is only for internal reference, no device in the chain cares about the clock in the devices before or after it ****

This mean the transmission time between network devices is not important nor do network devices need to be "sync'ed" to a master clock nor is a higher precision clock needed somewhere in the chain... as long as the next decoded packet needed by your streamer/pc/dac is in it's buffer in time for playback that's all that's needed


1 _gateway (192.168.1.254) 0.412 ms 0.466 ms 0.514 ms
2 203-114-134-244.lo.sta.inspire.net.nz (203.114.134.244) 15.381 ms 15.372 ms 15.348 ms
3 203-114-134-200.lo.sta.inspire.net.nz (203.114.134.200) 15.340 ms 15.327 ms 15.363 ms
4 203-114-190-44.sta.inspire.net.nz (203.114.190.44) 15.980 ms 203-114-150-178.ge-0-1-5-1143.wlg-br.inspire.net.nz (203.114.150.178) 15.347 ms 16.383 ms
5 203-114-149-86.sta.inspire.net.nz (203.114.149.86) 27.651 ms 203-114-150-70.sta.inspire.net.nz (203.114.150.70) 21.050 ms 21.043 ms
6 203-114-149-34.sta.inspire.net.nz (203.114.149.34) 23.590 ms 203-114-148-34.sta.inspire.net.nz (203.114.148.34) 47.013 ms 46.426 ms
7 203-114-134-220.lo.sta.inspire.net.nz (203.114.134.220) 44.478 ms 43.692 ms 43.674 ms
8 AUSTRALIA SYDNEY te0-3-0-7.agr51.syd01.atlas.cogentco.com (154.18.97.57) 44.908 ms 44.884 ms 44.859 ms
9 AUSTRALIA SYDNEY be3578.ccr71.syd01.atlas.cogentco.com (154.54.47.17) 44.851 ms 46.291 ms 46.282 ms
10 SINGAPORE be2546.ccr31.sin01.atlas.cogentco.com (154.54.1.29) 137.237 ms 136.775 ms 137.216 ms
11 FRANCE MARSEILLE be2914.ccr31.mrs02.atlas.cogentco.com (154.54.87.210) 275.817 ms be2919.ccr32.mrs02.atlas.cogentco.com (154.54.87.214) 275.921 ms 275.043 ms
12 FRANCE PARIS be2780.ccr42.par01.atlas.cogentco.com (154.54.72.225) 300.966 ms 301.949 ms 300.890 ms
13 FRANCE PARIS be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) 311.823 ms 311.797 ms be2103.ccr32.par04.atlas.cogentco.com (154.54.61.22) 301.852 ms
14 FRANCE PARIS * * amazon.demarc.cogentco.com (149.6.164.250) 310.203 ms
IRELAND DUBLIN ec2-54-77-163-178.eu-west-1.compute.amazonaws.com

Peter


**** where some "thing" in a computing environment needs to be sync'ed to a master clock, this is done via ntp (Network Time Protocol) and ntp is a protocol that runs over tcp/ip so this is an amazing thing... a precision master clock that keeps devices/databases/applications in sync yet it runs over a non-precision (relative to time) protocol. ntp is accurate to a few milliseconds

Truth! Clocking is important in networks, but in the case of audio transport that is pretty irrelevant as long as there is no buffer starvation. As long as the payload arrives, the higher level protocols take care of stuff.
Stop worrying about digital networks and clock and jitter b.s. everybody... it's like being constantly worried about pollution while you're out in pristine nature.

I'd think video enthusiasts would be more worried about networks, since 4k and such may test some old networks... and yet Netflix 4k works just fine. And note there is a LOT of buffering going on all over the place with video and yet video quality is pristine, even though you'll find some 20 year old network equipment between your home router and whatever Netflix caching location (they have like nearly 2k caching loactions in over 150 countries last I checked).

 

[MatrixS2000]

The audiophilestyle topic cites a white paper by UpTone Audio, who sell audiophile networking bullshit.

No one should ever take networking advice from an audio company…

As most of the basics have already been covered here I will only add one additional item. Noise in ethernet networks shows up as physical layer errors - CRC errors. Any noise on ethernet cannot get into the payload. In audio, the noise you hear is file locked and you can't reduce it without using something like a DAW.

 

[MatrixS2000]

whelp ... POE is common mode so ... TP passes common mode, so not so simple

Huh???? PoE is generated from the switch only when a PoE capable device is attached to that port. No PoE device, no DC power sent on the ethernet port.

Also PoE, has zero impact on the noise reducing capability of the switch which is typically 30-50dB via transformer isolation. PoE flows through the centre tap of the transformer resulting in equal current in both halves of the winding. The result - DC bias cancellation and no impact to the transformer’s ability to attenuate noise.

 

[pablolie]

Huh???? PoE is generated from the switch only when a PoE capable device is attached to that port. No PoE device, no DC power sent on the ethernet port.

Also PoE, has zero impact on the noise reducing capability of the switch which is typically 30-50dB via transformer isolation. PoE flows through the centre tap of the transformer resulting in equal current in both halves of the winding. The result - DC bias cancellation and no impact to the transformer’s ability to attenuate noise.

The noise level on an Ethernet physical medium will not ever be passed to the actual payload. Whatever DR the audio track had will be maintained end to end perfectly. That's the strength of digital vs analog... analog signal degradation is much harder to deal with... with digital you can just regenerate a perfect signal very easily.