Wavelength Ethernet Spacelator

[jabbr]

6 hours ago, Miska said:

 

 

And there's nothing to "reclock" on Ethernet. One could try to reduce the noise impact by using spread spectrum clocking though (clock with as high as possible random jitter), although many devices use it already. Unfortunately audiophile gear usually goes totally opposite way on this though... (Ethernet clock has no relation what so ever to audio clocks)

 

 

 

As of Ethernet 10g which is now decade+ old and more so 25g 40g 100g, the end to end jitter is specified to have a tight upper limit. (So spread spectrum wouldn’t meet spec)

 

There are perhaps some some improvements with latency associated with good clocks on NICs for example the Solarflare “Flareon” 7322F if you want something exotic but commercially available ... would be really hard to beat good commercial fiberoptic switched/NICs in isolation, latency or any other measurable parameter  

 

Its not just that there isn’t anything to reclock, it’s that there is no reasonable way to improve on what’s already there unless you are comparing to 20-30 year old offerings. 

[jabbr]

2 hours ago, Miska said:

I have not spent time reading 10+G network specs, so I don't have clear picture of their frequency constellation patterns. I'm quite disappointed if they actually transmit any clock (that you could reclock in first place).

 

Basically as of 10GBase-X compliance with eye-pattern for end-to-end jitter in picosecond range rather than specs for individual components.

 

The “audiophile” brands are promoting the idea that reclocking a network switch, for example, will affect jitter at the receiver — and it will if the network switch is crappy — but 10GBase-X already takes this into account by specifying end-to-end jitter  

 

Quote

 

Someone needs to begin modeling signaling of high speed military radio networks that have advanced randomized frequency hopping.

 

A different interesting use of spread spectrum than the military has been doing for at least 25 years.

 

Of course 10G speeds are not necessary for audio — I’m just pointing out that the really old 10mbs and 100mbs networks tolerated/used poor jitter components — 1Gbe less jitter but when 10G was introduced, the jitter specs became vastly better and the 10G switches are already very low jitter. If an audiophile switch is introduced it should be compared — end to end — against 10G equipment not 100M equipment  

[jabbr]

4 hours ago, mansr said:

There's still some fundamental unit interval the receiver locks onto in order to make sense of the signal. That is, in fact, what you say in the last sentence.

 

Right, so the totally allowable jitter can be allocated between transmitter and receiver -- there is lots written but to start: https://www.keysight.com/upload/cmc_upload/All/669-10GigEthernet-08-01-02.pdf

https://www.sitime.com/api/gated/AN10026-10GbE-RJbudget.pdf

[jabbr]

6 hours ago, Miska said:

Only case I know where any of the jitter/latency have any relevance to audio, is AES67/Dante/Ravenna and sometime AVB, which use PTPv2 for clock transmission.

 

802.3ae (2002) as I've said, specifies end to end jitter and because the input frame is locked by PLL, jitter on the input results in a degree of jitter on the receiver. Consequently the specification of end to end jitter: both the transmitter and receiver together have to meet the specification.

 

The premise of Ethernet reclocking is that the transmitter or switch has too high levels of jitter/phase noise.

 

Not necessary when using a good 10 Gbe switch or NIC as these already have femtosecond clocks i.e. https://www.sitime.com/api/gated/AN10026-10GbE-RJbudget.pdf

 

So ... this thread is about a device that is intended to improve Ethernet SI ... I'm saying that fiberoptic Ethernet 10G (802.3ae) already does this ... that's what I use. They are giving away very high quality equipment on eBay because the pros are going 100 Gbe. It may not make a difference but at the prices who cares?

[jabbr]

15 hours ago, Miska said:

The only effect of too high jitter would be packet loss? If the packet loss is already 0, what would be the improvement of improved clocking?

 

Not entirely simple answer but if the question is whether the jitter on the transmitting interface can affect jitter on the receiving interface, the answer is yes.

http://www.ece.tamu.edu/~spalermo/docs/rx_jitter_tracking_fwd_clk_ragab_jece_2011.pdf

 

Similarly both common and differential mode noise: http://www.ece.tamu.edu/~spalermo/docs/rx_jitter_tracking_fwd_clk_ragab_jece_2011.pdf

 

Now a leap of faith would say that jitter on the Ethernet interface thus could affect jitter on the USB stream. This has not been demonstrated to my knowledge but based on the above (and other data) the answer is that its possible.

 

Not to say that this makes its way into the DAC, or is relevant for audio  but if the question is whether the upstream clock can affect the downstream interface, the answer has been known to be yes for some time.

[jabbr]

Let me expand slightly on the mechanism.

 

The Ethernet transmitter doesn't transmit a clock per se, rather the clock is recovered from the incoming packet via PLL. The PLL is necessary to phase lock the incoming packet with the receiver interfaces so that the bits can be latched and reclocked at the receiver. The PLL tracking is affected by source jitter.

 

In an ideal world, a FIFO isolates and reclocks the Ethernet buffer. In the case of a high quality 10G fiber interface, the receiver CPU undoubtedly has higher jitter than the Ethernet stream, so this might be moot. This is the reason, though, that 802.3ae requires the test of end-to-end jitter, rather than individual components. I focus my efforts on the terminal receiver i.e. good PSU, good hardware knowing that my network will give me a measurably good signal up until that point.

[jabbr]

7 minutes ago, Miska said:

 

I understand that, but if the end effect at ethernet packet level is zero? Since I'm getting zero errors at ethernet packet level, playing with jitter optimizations is moot. Even if there would be 50% packet loss due to excessive jitter on 10G ethernet, still it wouldn't make a difference for audio because you would have 5G effective bandwidth. While DSD512 over NAA requires that you manage to push 50 Mbps through within +-500 ms TCP level jitter.

 

 

I can’t disagree with any data. Devil’s argument says that jitter at the receiver somehow makes it into the DAC. Not technically impossible but not proven. I picked up some Solarflare 7322f cards at like $120-150 so ... some day when my very long stack of things to test out dwindles 99%, then I’ll sit down and tell you if I can hear “SQ” ??? 

[jabbr]

14 hours ago, Miska said:

Even if there would be 50% packet loss due to excessive jitter on 10G ethernet, still it wouldn't make a difference for audio because you would have 5G effective bandwidth. 

 

Yes! That is a great way of looking at it — and why I use 10Gbe actually — it is so over spec’d for the job. Jitter is really low, fiber blocks common mode noise, Ethernet blocks differential mode noise. 

 

Its also really cheap, so way over spec & cheap, and I don’t need to worry about the network   ... plus I like the color of the cables ?

[jabbr]

On 11/9/2018 at 10:00 AM, plissken said:

 

You know how many times I've pointed that out and it falls on deaf ears?

 

I've even pointed out you can inject the worst jitter possible by pulling the cable and plugging it back in and the music never stopped in non-realtime systems.

Regarding jitter and it’s potential effects:

 

Jitter generally consists of phase noise. There is also amplitude noise. Noise can be differential and it can be common mode. 

 

Noise of all the above types can be transmitted from the transmitter to the receiver. There are various mitigation strategies and circuits for each of the above noise types. 

 

Without circuit details and measurements, one cannot be sure about how much noise may or may not be transmitted between systems. I suppose if you leave the cable unplugged that you have some assurance that noise won’t tend to pass. For those of us who don’t want to keep plugging and unplugging the cables there are different isolation techniques. 

[jabbr]

33 minutes ago, plissken said:

 

Ya, like WiFi.

 

Also the phase noise is going to happen around the signalling rate and not audio-band. You seem to want to put a square peg into a round hole.  When all you need to do is measure the output of the DAC.

 

Why bother measuring when we have resources here such as yourself that know everything.

 

Phase noise is curious, and I agree that mere logic would question whether phase error at 25 Mhz (BTW the crystal for Ethernet tends not to be the signalling rate but no matter) should translate down to audio frequencies.

 

The reason that power supplies make a big difference in crystal phase error is that there is a 1/f nonlinearity which converts 1/f voltage noise into 1/f offset phase noise. This phase noise will widen the peak.

 

I don't know that the nonlinearity is unidirectional.

 

33 minutes ago, plissken said:

 

But again, if Gordon wants to prove any of this is audible, I welcome him to sitting down to a test rig like I outlined with the LACP config I posted or he can provide an isolation device to Amir at audiosciencereview.

 

Well yes I think folks who are promoting a product or certain capabilities of a product have some incentive to demonstrate benefits.

 

I am using WiFi and pointing out where COTS hardware, albeit pro grade, already deals with issues that have been raised here, so can serve as a starting point for folks who are interested in upgrading network hardware. I have been advocating optical isolation for a few years now, and its great to see products such as the Lumin X1, the Wavelength spacelator and upcoming Uptone switch incorporate optical elements,  and even SFP capabilities (there are copper as well as fiber SFP modules so this is very flexible).

 

Wifi can be a bit glitchy still but getting there.

[jabbr]

24 minutes ago, plissken said:

 

It doesn't because if it did you would have posted something crowing about it.

...

24 minutes ago, plissken said:

 

If the non-linearities propagated down into the human hearing band you would have posted a resource on it.

 

Don't make assumptions, and don't twist what I have already posted, including references. My own interests lie more in DAC and amplifier topologies. where certain nonlinearities are clearly audible ... if you are of the opinion that all DACs and amplifiers which have the same THD sound the same, then I don't have any interest in proving anything to you and certainly no interest in crowing. I've posted many many resources which anyone can read if they want, or not.

 

24 minutes ago, plissken said:

 

Actually the more they can market without any peer review the better.  They will let the gullible with gold ears do the selling.

 

Wifi is downright reliable actually. I have 248GB wireshark capture with 0 dropped packets and only 4 re-transmits around here somewhere.

 

Heck, you can pickup Cisco 2960-8-TC's left and right for $25 with SFP GB. That will provide every ounce of isolation.

 

That's my point.

[jabbr]

1 hour ago, cjf said:

On the topic of these various ETH "doodads" that refer to "Re-Clocking" ETH signals.  Are these devices with the special Clocks dependent on the TCP Header data in anyway in order to perform their Clocking/Re-Clocking?

 

Every Ethernet switch reclocks the Ethernet signal. It does not depend on the TCP header.

[jabbr]

3 hours ago, marce said:

PLT, power line communication is adding EMC to the mains, so you distribute it everywhere, it can couple all over the place and filtering it is not as easy as some presume…

A lot of you get excited about a few pA of noise from a SMPS, yet will quite happily add far more noise to the mains using PLT, it is a bit of a joke…

Anyway if you want to get a broader view of the problem here is some info from EMCIA:

https://www.ban-plt.org.uk/emcia.php

 

Well said!

 

Need to keep everything in perspective!

 

I've used PLT in the past, never been too impressed, and WiFi has progressed to the point where mesh networks are very fast.