Wavelength Ethernet Spacelator

[Miska]

18 minutes ago, One and a half said:

The Spacelator reduces the number of errors in the Ethernet Transmission, so there's no need to correct or resend, avoiding processing and the extra noise that goes with that. 

From the interview, it appears the clocking is performed internally, with no external clock input mentioned. Delivery is 2019.

 

Errors? What errors? I have several terabytes of traffic gone through with zero errors.

 

Retransmissions happen usually due to higher levels in the OSI stack that Ethernet level devices don't know/understand about and thus has no impact over.

 

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)

 

[Miska]

2 minutes ago, One and a half said:

I'm just passing the message on from the interview. 

 

Yes, I totally understand that.

 

Just commenting about the information, not shooting the messenger!

[Miska]

20 minutes ago, jabbr said:

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)

 

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). Someone needs to begin modeling signaling of high speed military radio networks that have advanced randomized frequency hopping. So much that the comms looks like background noise. Although lot of this is also trickling down to high speed mobile/wireless networks (WiFi, LTE, etc).

 

There's for example this doc about these in CDMA:

http://www.wireless.ece.ufl.edu/twong/Notes/CDMA/ch2.pdf

And OFDM variant used in many many different technologies these days. xDSL and similar wiring systems also use these kind of techniques due to lot of interference and low channel separation on the telephone cables.

 

One of the best Ethernet specs so far to improve noise for audio use is 802.3az / Green Ethernet. Newer switches and NICs have better and better capabilities to measure cable length and attenuation and adjust transmit powers accordingly. Would be kind of stupid to blast at full power over short cable at powers needed for 100 meters long cable.

 

32 minutes ago, jabbr said:

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

 

Yes, although latency of local networks is totally non-issue for audio playback. Since this is not Wallstreet trading application...

 

But certainly I'd like to see on R&S or similar network analyzer how the audiophile products fare against HPE/Cisco gear.

 

Anywa, for example NAA can tolerate about 500 milliseconds of network jitter, and would thus work even across the internet from other side of the globe. Also bandwidth needs of audio vs capacity of 1 / 10 / 25 Gbps network links is so low, that there's plenty to spare for other things.

 

[Miska]

2 hours ago, mansr said:

Everything except the lowly UART has some kind of clock transmitted along with the data.

 

Well, I wouldn't say most wireless transmissions transfer clock as such, but more just modulation patterns over one or more carriers (typically multi-carrier these days), which are of course driven by a clock. Bunch of frequencies and levels encoded at some (sometimes variable) bitrate. 256-QAM or similar, mixed with randomized center frequency hopping or such. Receiver can just hook into changes that can happen at varying rate. Of course you can have some "clock" that defines channel band center(s). Or band division like IIRC ADSL has that uses low frequency band for the uplink and high frequency band for the downlink.

 

1 hour ago, jabbr said:

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

 

"Eye pattern" sounds a bit inefficient because you have lot of "holes" in it. You could fill those with different waveforms/frequencies. I'd expect efficient transmission look more like noise on a scope. Unless you don't think about "eye pattern" in the traditional meaning. Keysight seems to have some nice scopes for dealing with modern comms (good screenshot of QAM too):

https://www.edn.com/electronics-products/electronic-product-reviews/other/4461130/Oscilloscope-sets-bandwidth-record--on-all-four-channels

 

1 hour ago, jabbr said:

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

 

Ahh, yes, sure. I was kind of anyway expecting comparison at least within the same speed class. Gigabit switch against gigabit switch at least. I would expect all gear to be at least gigabit these days anyway.

 

 

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.

[Miska]

3 hours ago, Arpiben said:

For anyone interested in Ethernet synchronisation aspects:

- SyncE or synchronous Ethernet for transfer clock purposes (ITU-T G8261/2/4)

- 1588 PTP (Precision Time Protocol)

 

Of which only latter has relevance to audio and even then only for pro audio...

 

[Miska]

2 hours ago, Arpiben said:

Dealing with Latency, even if with little/no relevance in audio, the advertised values are around 5 ms for 5G networks. For such, in wireless, you need to have huge Bandwidth or Channel Spacing (500MHz/1000MHz/1500MHz).This means using frequency bands around 80 GHz and above.

Otherwise in cables or optical fibers the latency is around 5 ns / meter.

Nothing to worry about or in other words no need for MQA even with mobile phone audio streaming☺️

 

I know there are even bigger constellations than 4096 too. Was just an example...

 

Since for streaming we have enough buffers and fairly low bandwidth usage compared to for example Netflix 4K video, there are certainly no issues doing these things over the internet. I'm writing this and streaming Tidal over fixed 4G (LTE) internet connection. I have ADSL too, but it is slow and disappearing already. Operators want to get rid of cables here... My pings to computeraudiophile.com over this LTE connection are in 25 ms range, "jitter" about 5 ms (there's quite a bit of traffic there).

 

Quote

--- www.computeraudiophile.com ping statistics ---
29 packets transmitted, 29 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 17.135/26.590/36.495/5.402 ms

 

So far, maximum LTE speed I've reached in practice here was 350 Mbps. I have also one router capable of LTE Advanced CAT16 (1 Gbps), but network is not yet up to it.

 

Doing things over LAN is certainly non-problem.

[Miska]

5 hours ago, jabbr said:

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.

 

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?

 

Quote

Not necessary when using a good 10 Gbe switch or NIC as these already have femtosecond clocks

 

I would stay away talking about "femtosecond" jitter figures and such. So totally different for those GHz clocks compared to audio clocks. From the presentations you linked to, one can see that they look at jitter / phase noise figures above 4 MHz point. For audio clocks one looks at figures above 10 Hz point or even lower.

 

Higher the clock frequency gets, worse the low frequency phase noise figures gets. For example 100 MHz clocks used with ESS DAC chips have about 20 dB worse phase noise at 10 Hz than 22.5792/ 24.576 MHz clocks you need for direct DSD512. That is one problem when decoupling DSP and D/A conversion under same synchronous clock domain on one chip. One of the reasons I rather run all DSP asynchronously from the actual D/A conversion process...

 

5 hours ago, jabbr said:

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?

 

I'm still sticking to 1G switches although thought about 10G to improve speed of connection between switches. Now one can get good managed 1G switches at reasonable prices (new ones). Since I'm using HPE gear, I recall eying some model that had like two 10G SFP ports for uplink and rest were 1G.

 

[Miska]

2 hours ago, bobflood said:

 

Care to elaborate on the good (new) managed switches?

 

Recently I've been buying HPE 1820 series:

https://www.hpe.com/us/en/product-catalog/networking/networking-switches/pip.switches.7687976.html

and 1920S series:

https://www.hpe.com/us/en/product-catalog/networking/networking-switches/pip.overview.1009689650.html

 

And after spending a little bit of effort on configuration, like making sure flow control (802.3x) is enabled, things work nicely. I also utilize VLANs on my setup, but it is not necessary for typical home configurations.

 

I'm rarely a brand loyal person, but for network switches, I've been using HP for a very long time in various different kinds of environments and never had much to complain.

 

My WiFi access points are also HPE, powered from the switch using PoE.

 

[Miska]

29 minutes ago, jabbr said:

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.

 

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.

 

[Miska]

3 hours ago, jabbr said:

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 ?

 

I think overall Ethernet and other networking technologies are good fit for audio. It certainly increases complexity though, that's the cost. Optical Ethernet gives full isolation and lot of bandwidth and flexibility for all kinds of use.

 

I was trying to check 5.1 channel DSD256 over WiFi today, but exaSound driver on Windows machine was acting up so I couldn't. Maybe it's time to try the Mac driver instead.

 

[Miska]

13 hours 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?

 

Those are all (that I know of) low level Ethernet devices and don't understand higher OSI layers like IP and even less TCP/UDP.

 

[Miska]

At least my streaming protocols operate at UDP/TCP level and doesn't really care what kind of physical link is underneath and doesn't distribute any clock. Thats why it works over Ethernet, WiFi, powerline, etc whatever that can carry TCP/IP.

 

Same goes also for other protocols like UPnP AV.

 

There are some protocols that rely more on the lower levels, namely AVB. And AES67/Dante/Ravenna to lesser extent. Former I haven't seen being used for audiophile cases, while Ravenna is used to some extent. But still, these rely on PTPv2 protocol for clock distribution and feed it to a DPLL for clock generation.

 

[Miska]

9 hours ago, plissken said:

Protocols like SIP and MPLS, engines like CEF/FIB all work at the L2/L3 boundary.

 

SIP is just plain UDP/TCP with RTP media streams (UDP) with RTCP control. So it sits tightly at L4 and thus works fine over internet. Our team implemented SIP VoIP and video calls for Linux-based Nokia devices/phones, along with bunch of other protocols. SIP is a bit braindead by design, so it never got very popular and doesn't have nice support for video/audio chats. Unlike protocols like XMPP (Google Talk etc at that time) and Skype that we also had.

 

SIP is actually my prime example of "designed by a committee" disaster. UPnP being almost as bad too.

 

[Miska]

Power filters are good for the purpose, cleaning up powerline Ethernet high frequency noise is easier than the spikes from electrical motors and such. I have two filters in listening room, one for equipment with linear PSUs and another one for those with switching PSUs.

 

 

[Miska]

34 minutes ago, marce said:

Why does powerline communication have an exemption from EMC rules, why did EMC UK (Keith Armstrong among others) try and get it banned....

 

At least here also the power consumption meters communicate back to the power company using powerline data transfers.... This is why I can see realtime power consumption data of our house from the power company's web pages.

 

No, I'm not as such using or recommending power line Ethernet as primary option, but I think it is viable alternative. I personally just don't need it because the entire house is wired with CAT6 and in addition I have 802.11ac wireless with multiple access points (corporate models) around the house.

 

[Miska]

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

 

Already at the beginning it starts talking about technologies using power lines to deliver internet access and not about local networking:

"as an option for the delivery of broadband Internet" ... "One mechanism for providing broadband Internet access might be thought to be PLT, and similar digital communications technologies, that use the electric power lines (the "mains") to, and within, homes to carry the high speed data signals used by broadband Internet."

 

But other than that, the rant sounds much more like industry political battle where traditional telcos are worried that power companies would become competitors. Power companies are anyway already using PLT technologies for their smart grid over longer distances than the home networking devices can do. For home networking the power levels needed to carry the data are so low that it doesn't pose much problem.

 

We are now specifically talking about https://en.wikipedia.org/wiki/IEEE_1901 and https://en.wikipedia.org/wiki/G.hn

 

And no, I don't get excited about SMPS noise, because I have a probably closer to 50 SMPS thingies running in the house.

 

[Miska]

4 hours ago, marce said:

Now lets get practical over power levels...

Laptop, 10mW, router 100mW wireless not a lot of power...

 

So far I have seen much more problems out of cellular phone transmitting at it's full 2W power near sensitive equipment, especially because it is pulsating packet transimission. And large electric motors starting that you can even notice as lights blink. Also when I turn on my power amp lights blink. Comparing than anything from power line comms...

 

Those MHz frequencies don't really get much through with normal linear or switching power supplies.

 

If you are more worried, you can always use mains regenerator or off-line UPS for audio equipment.

 

And what are you going to do about electric company's smart grid data on the network anyway?

 

4 hours ago, marce said:

You are adding noise to your mains wiring system, a nice collection of long un-shielded cables meandering all around your domestic environment.

 

That is more of a problem in a different way, having couple of kilometers of air wires on the poles anyway picks up all kinds of things, including lightning induced electricity.

 

[Miska]

4 hours ago, Superdad said:

 

And I seem to recall that PLT (of utility companies) in the USA uses a 19Khz carrier!

 

That can actually get through LPSU mains transformer, while something like 25 MHz doesn't really go...

 

[Miska]

I measure lot of devices and have quite a bit of measurement equipment. And I have done quite a bit of measurement equipment.

 

For any gear you must begin with the assumption that mains is in any case horrendously dirty. You can start with assumption that in worst case it will roughly stay within +-50V of noise in range from 50 Hz to 1 MHz, and will contain noise up to GHz range at lower levels. And you may gets spikes that reach kV levels. Then you are good.

 

Standard RFI/EMI filters that attenuate noise about 30 dB are pretty good already. I've got Siemens ones in the equipment I've built.

 

@marce can you please post measurements where this stuff really shows up in analog output of various DACs or similar that we can verify it being a real problem?

 

I'm not recommending to use HomePlugs or similar if there are other ways that suffice, but sometimes there are no other reasonable ways to do it, there's no need to do lot of fear mongering about it. In any case you have no control over what other peoples like neighbors, nature or electricity company does on the grid. If you cannot access your music, you certainly have another kind of problem. Or if you have a computer that sounds like vacuum cleaner in your listening room that's certainly noisy in a different kind of way.

 

[Miska]

Here's output noise spectrum of a standard type of LPSU based on LM317:

 

Now combine that with standard PSRR of a good opamp that is 120 dB and it is not that bad at all.

 

 

If there are good practical and objective results from audio gear, I'm happy to see.