Optical Network Configurations

[vortecjr]

15 minutes ago, jabbr said:

 

I understand your opinion. I am not questioning your design process, rather the suggestion that Ethernet flow control is esoteric and would normally or ought be implemented in the NAA protocol. 

 

Indeed your hardware implements flow-control!

 

Again my objection was the statement starting “The issue with NAA ...” and going on to explain that pause-frames are esoteric and that “network professionals hate pause frames”.  The statement that the Linux kernel emits pause-frames is simply incorrect.

 

I don’t meant to criticize your design process but is any technical statement I’ve made wrong? Am I properly characterizing your fix as a mod to the fec driver to enable hardware pause-frames?

 

One just needs to object and give a reason why. Standards aside I asked Jussi if he could do something and he said no and gave his reasons to me. I even said I supported Jussi's decision in the other thread. 

 

It does support flow control, but it was being rigorously debated otherwise. I'm not blaming you. 

 

That is his opinion. On the other part I think you are reading to much into it.

 

I don't want to get into the technical discussion or discuss the fix.

[charlesphoto]

2 hours ago, bodiebill said:

 

The 305 arrived and I can use the ethernet port as a fully operational port like the SFP+ ports.

Of course it is limited to 1GB. @jabbr Is that the reason you say an RJ-45 SFP module is needed? To get it up to 10GB? If yes, why is this important? If I understand well, it is not the 10GB speed that improves things for audio but the higher standards in terms of jitter that go with the 10GB protocol. Or am I wrong? 

Ordered one for here on Monday. Figured I can always return it. Will be interesting.

[jabbr]

5 hours ago, bodiebill said:

The 305 arrived and I can use the ethernet port as a fully operational port like the SFP+ ports.

 

Confirmed here also, works fine. No doubt that's easier than using an RJ45 SFP.

[jabbr]

18 hours ago, Superdad said:

Just to be clear:  All appropriate standards and protocols are supported and active in our forthcoming EtherREGEN switch—playing in my system as I type this. 

 

Excellent. From what I understand of your design, it should do well on the “stressed eye pattern test” (802.3ae clause 52) but that compliance test is for 10Gbe not 1Gbe, so you wouldn’t be expected to have done that. I mention it, because it specifically looks an variations in incoming jitter wrt the tx eye pattern — ie ensuring that incoming jitter is isolated. 

 

Its great that you are bringing this product to market at a very reasonable reasonable price for a small batch design taylored to the audiophile market — light years better than spending the equivalent or much more on an “audiophile Ethernet cable”

[Superdad]

On 9/12/2019 at 4:14 PM, jabbr said:

I am not commenting on the copper Ethernet output to a copper Ethernet endpoint. There are many different devices with different purposes. I see the strength of the EtherREGEN, from what I understand of the design, to be for fiberoptic in and copper out?

 

The heart of what makes the EtherREGEN entirely different from any other switch is our use of active low-jitter high-speed differential isolators to feed data and clocks back and forth across a moat galvanically separating power planes. [Please don’t ask or speculate about the data mode or details of the technique—that’s the part we want to try to keep secret.] And we pass the data through ultra-low-jitter 10GHz-capable differential flip-flops on both sides of the moat. Plus all clock lines are run as differential, with LVDS>SE buffers placed a couple of millimeters away from the few chips that require single-ended clocks.

 

Now to the point of my reply here in your optical thread, prompted also by my desire to clear up your reference to our piece having fiberoptic “in” and copper “out.”

Our design goal was to make a noise, leakage, and clock-phase-noise fingerprint moat so effective that nothing (or as close to) coming in on the ‘A’-side of our switch (four Gigabit copper ports and one Gigabit SFP cage) has any effect on what comes out of the single ‘B’-side copper port (100Mb only—to do Gigabit on this side will be a vastly more complex and costly design).

 

As those following our development know, our newest round of preproduction boards are the first to be fully functional end-to-end. This week a few beta-test units will be sent to select people, mostly for network corner-case testing.

Yesteday was my own first full day of experimenting with EtherREGEN in my reference music system. (Yes, it sounds great; much better than my Cisco Catalyst 2960.) One of the tests I was most interested in performing was to determine if using the SFP/fiber port (as fed streamed data from my music server) sounded any different than using one of the Gigabit copper ports. It did not sound the least bit different, so I am taking that as one data point verification of the achievement of our design goal.

 

Certainly an “all fiber” system should be terrific and may be the future. But at present there are no DACs with fiber Ethernet inputs, and we are just beginning to see turnkey streamer/renderer endpoints with optical, such as the very fine Sonore opticalRendu.  Of course there are computer boards with SFP cages (the SolidRun Clearfog which @jabbr enjoys), and PCIe cards can be added.

But our hypothesis (based both upon theory and on what users have reported on audible results with improved clocking of packet-data interfaces) is that general noise and galvanic isolation (as afforded by fiberoptic) is not the whole story.

 

Lastly Jonathan, while we know that the jitter/phase-noise in 10G fiber switches is very low, an eye-pattern is not going to resolve such to make comparisons possible.  @JohnSwenson just bought a used Wavecrest DTS-2079, and he will be using it to measure jitter downstream (even on I2S lines in a DAC) while making changes in upstream interfaces/clocking. It’s research to quantify what many already find audible. Yes our scientific side would prefer the measurement proof come before the product, but in this case we designed to the theory and for the moment all we have for judgement are our ears. 

 

Thanks for permitting me space in your thread to share the above details and my thoughts.

Alex C.

[Miska]

Now the interesting question is, is it better with minimal jitter, or with maximal jitter?

 

[jabbr]

1 hour ago, Superdad said:

Now to the point of my reply here in your optical thread, prompted also by my desire to clear up your reference to our piece having fiberoptic “in” and copper “out.”

Our design goal was to make a noise, leakage, and clock-phase-noise fingerprint moat so effective that nothing (or as close to) coming in on the ‘A’-side of our switch (four Gigabit copper ports and one Gigabit SFP cage) has any effect on what comes out of the single ‘B’-side copper port (100Mb only—to do Gigabit on this side will be a vastly more complex and costly design).

 

My point in discussing “stressed eye pattern” is that type of jitter isolation has been looked into and measured for decades. 

 

The details about how the network switch vendors all accomplish this are intellectually interesting but regardless Tektronics & Keysight describe exactly how to measure it.

1 hour ago, Superdad said:

Lastly Jonathan, while we know that the jitter/phase-noise in 10G fiber switches is very low, an eye-pattern is not going to resolve such to make comparisons possible

 

Actually it will. If there is no jitter out, or if the switch perfectly removes the signature of incoming jitter, then it’s a nonissue. 

 

That said, we continue to await your measurements. 

[Foggie]

Seeing as I'm the only mU customer with issues using a OM on a fiber network, it would only make sense to use me as a beta tester for the EtherREGEN 😉.

[Miska]

15 minutes ago, jabbr said:

Actually it will. If there is no jitter out, or if the switch perfectly removes the signature of incoming jitter, then it’s a nonissue. 

 

Disregarding networking things, eye pattern and such tend to be problematic way of measuring low frequency drifts.

 

As an example is some of the ESS Sabre problems are quite tricky to measure because the level is low (-120 dB or so) and the the cycle takes about one minute. Low frequency drifts in the eye pattern at -120 dB level would be much much smaller than pixel size of the eye pattern plot.

 

[Superdad]

31 minutes ago, Foggie said:

Seeing as I'm the only mU customer with issues using a OM on a fiber network, it would only make sense to use me as a beta tester for the EtherREGEN 😉.

PM sent.  Only possible if you are located in the USA.

[Arpiben]

46 minutes ago, Miska said:

 

Disregarding networking things, eye pattern and such tend to be problematic way of measuring low frequency drifts.

 

As an example is some of the ESS Sabre problems are quite tricky to measure because the level is low (-120 dB or so) and the the cycle takes about one minute. Low frequency drifts in the eye pattern at -120 dB level would be much much smaller than pixel size of the eye pattern plot.

 

 

If by low frequency drifts you mean Wander ( Jitter for f<10 Hz) measurement is a non issue using different methods than eye pattern. 😉

[jabbr]

1 hour ago, Miska said:

 

Disregarding networking things, eye pattern and such tend to be problematic way of measuring low frequency drifts.

 

Yes Allen deviation (ADEV) is appropriate there or phase error vs offset frequency.

 

Not at all clear that those are appropriate for Ethernet packets. 

 

The point is that the conjecture that John Swenson has been promoting that upstream jitter somehow affects downstream jitter was in fact considered as of 2002, and the stressed eye pattern measurement developed. 

 

No data has been presented to suggest that this measurement is not appropriate. nor do we know that any 1Gbe equipment even passes the 10Gbe standards (let alone 40 or 100Gbe!)

 

Quote

 

As an example is some of the ESS Sabre problems are quite tricky to measure because the level is low (-120 dB or so) and the the cycle takes about one minute. Low frequency drifts in the eye pattern at -120 dB level would be much much smaller than pixel size of the eye pattern plot.

 

 

If in fact it were demonstrated that Ethernet jitter (as minimal as it might be) survives the input buffers and conversion to I2S, then one could consider those issues. I have always maintained that it is the low offset phase noise that is likely important for DAC clocks (aside from correlated jitter which is an entirely different animal), so yes but let’s see data!

 

Its conceivable that jitter on the Ethernet interface somehow affects the USB interface and somehow affects the DAC, and if that’s the case then it’s conceivable that server noise somehow affects the DAC (this conjecture is getting stretched very thin) but if server jitter doesn’t pass through the Ethernet switch then it’s a moot point. Measurements say it doesn’t. We are left with effects on SQ that are outside electronics! 

 

I am eager to be proven wrong!

[jabbr]

7 hours ago, Foggie said:

Seeing as I'm the only mU customer with issues using a OM on a fiber network, it would only make sense to use me as a beta tester for the EtherREGEN 😉.

 

Consider connecting the opticalRendu to the Mikrotik 305 switch and report your results. We would all benefit from that data point,

[jabbr]

19 hours ago, Miska said:

 

Disregarding networking things, eye pattern and such tend to be problematic way of measuring low frequency drifts.

 

Interestingly "choppers" are used to mitigate close in phase noise (eg https://www.highfrequencyelectronics.com/index.php?option=com_content&view=article&id=1160:eliminate-high-speed-adc-flicker-noise-with-chopper-upgrade&catid=123&Itemid=189) and I wonder how Ethernet packetization would effect low frequency drifts -- not intuitive.

[jabbr]

20 hours ago, Foggie said:

Seeing as I'm the only mU customer with issues using a OM on a fiber network, it would only make sense to use me as a beta tester for the EtherREGEN 😉.

 

The other possibility which occurs to me, is that if enabling pause-frames does not solve your issue, that you might investigate with wireshark and consider tuning the TCP flow control parameters: https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl but probably @vortecjr is in the best position to determine what the issues exactly are. They may not be hardware related.

[Miska]

57 minutes ago, jabbr said:

Interestingly "choppers" are used to mitigate close in phase noise (eg https://www.highfrequencyelectronics.com/index.php?option=com_content&view=article&id=1160:eliminate-high-speed-adc-flicker-noise-with-chopper-upgrade&catid=123&Itemid=189) and I wonder how Ethernet packetization would effect low frequency drifts -- not intuitive.

 

One way to ask for another kind of trouble...

 

Anyway, I'm still not understanding why this network gear jitter is discussed in first place...

 

Quote

Its conceivable that jitter on the Ethernet interface somehow affects the USB interface and somehow affects the DAC, and if that’s the case then it’s conceivable that server noise somehow affects the DAC (this conjecture is getting stretched very thin) but if server jitter doesn’t pass through the Ethernet switch then it’s a moot point. Measurements say it doesn’t. We are left with effects on SQ that are outside electronics!

 

Based on the reasoning that the network jitter matters for audio, streams from Tidal and Qobuz should be completely unlistenable, especially in my case where they go over LTE data link and end up even in best case with jitter in several milliseconds scale.

 

One major fault I'm commonly seeing where Ethernet interface may indeed affect USB interface and DAC is when people use "audiophile" network cables that are STP/FTP type and thus connect grounds between the devices, entirely spoiling the idea to use Ethernet for ground isolation. Hopefully nobody will invent optical cable that would still galvanically connect the two devices through some stupid metal or otherwise electricity conducting "shield"...

 

[charlesphoto]

Mikrotik CRS305 up and running in the system. Initial thoughts: very close to an opticalModule (for the sending end) - I would say the oM (again, this is on the sending side) is maybe 5-10% more revealing and tighter, which in my system actually translates to more fatigue I think - I'm finding the Mikrotik just seems easier to listen to. Slightly louder too, at least it seems. I haven't compared with an oM on the receiving end and won't as the whole reason for the Mikrotik is to act as a switch. Will be interesting to see if there's any change due to burn-in. 

 

And of course the main reason to get it hasn't really worked out - I wanted to use one as an 'endpoint' for the Unitiqute in the office running from the Mikrotik, but I can't seem to get it to work no matter which SFP I use (I get green light and no orange) - same SFP into a TP Link MC200 and it fires right up. These oM's can be so freaking fiddly. Anyway, the office does sound better even with the TP, as I also was able to remove the TP Link 10/100 optical bridge, an iFi SMPS, and about 50' of RJ45.

 

Might have an oM up for sale soon if I can't get it to work for the office. No idea what the issue is as it's not the unit itself, nor the SFP's being used (made sure all work in other configurations). Maybe there's a mismatch between the Naim (which is only 10/100 if I recall and the oM? But then why would the TP-Link 1gb unit work? Strange...

[ericuco]

On 8/3/2018 at 11:41 AM, jabbr said:

Really sweet: https://www.solid-run.com/product-tag/macchiatobin-single-shot/

https://www.solid-run.com/clearcloud-cloud-iot-core/

and https://www.solid-run.com/marvell-armada-family/clearfog-gt-8k/

10Gbe  

Relevant for audio? Maybe not today ... maybe today

10Gbe guarantees 5.5 ps end to end jitter ... i.e. the specs of the higher speed fiberoptic networks require less "jitter" so if you are concerned about jitter and noise etc, the bar keeps on getting higher and higher ... e.g. the board needs a better clock, better chips etc. etc. etc.

 

Has anyone tried one of these units as a HQP NAA?

 

I asked @Miska about it and he thought one of the Debian versions might work. It would be good to load one of the NAA images onto a SD card and be good to go.

[charlesphoto]

Optical saga continues: Mikrotik switch headed back to Amazon. With fresh ears and brain this morning A/B'd with an opticalModule to opticalModule and the Mikrotik CRS305 to oM, and the Sonore duo just sounded better. And without the oM able to talk to my Naim in the office the 305 didn't do what I set out for it to, so would have been an expensive FMC.

 

And finally, with some Terminal grunt, I was able to finally reset my Cisco 2960, so now have SFP out to the TP-Link 200 in the office (I already had one on hand), and all the disappearing RJ45  port madness I've been encountering resolved. Sounds great and time to do some work now while discovering great new music (getting tired of my test tracks). 

[Foggie]

On 9/15/2019 at 9:57 PM, jabbr said:

 

Consider connecting the opticalRendu to the Mikrotik 305 switch and report your results. We would all benefit from that data point,

If I get one, I will certainly do so.

[John769]

@charlesphoto thanks for the feedback.  Shame you weren't able to give it a few days to burn in before making a conclusion, as maybe one day of use- if that- wasn't quite enough in that regards.  Also how it performed as a switch in comparison to the Cisco would have been interesting.😁

[charlesphoto]

2 hours ago, John769 said:

@charlesphoto thanks for the feedback.  Shame you weren't able to give it a few days to burn in before making a conclusion, as maybe one day of use- if that- wasn't quite enough in that regards.  Also how it performed as a switch in comparison to the Cisco would have been interesting.😁

 

FWIW I think the Mikrotik is a perfectly acceptable sounding switch (powered by a rail of my HDPLEX 100), and probably after burn-in quite close to an opticalModule - on the sending side. I think the superior power regulation in the oM (and powered by an LPS 1.2) on the receiving side pre mR I would only consider the oM.  As it is, the Mikrotik didn't work for what I wanted it to (not its fault), so no amount of burn-in would make me want to hang onto it and lose $ on selling an oM if I don't actually need it as a switch.

 

It was perfectly plug and play - it also ran on poE from my Cisco, except the SFP/RJ45 transceiver I had on hand wouldn't work, so I needed the RJ45 port for ethernet in (it won't do both poE and data at the same time). The casework is decidedly cheap feeling, but that's ok. I also got the SFP out on my Cisco 2960L-16PS working, and I think that sounds as good, if not better than the Mikrotik out (sans burn-in that is). The Cisco's are well known, in Naim circles at least, for their superior sound quality - read Superdad's description of his (and the his new etherRegen in comparison) over on the etherRegen thread. But it has only one SFP in/out, so if you need more SFP ports, the Mikrotiks are a great inexpensive way to do so. 

 

Eventually the idea is to get an opticalRendu, in which case I would still go from opticalModule to opticalRendu, but would no longer need a pair of them, obviously. I think I've upgraded most everything I can around the microRendu 1.4 (power, cables, etc) that is the block now (beyond the analog gear) to even better sound, which is hard to imagine. 

[jabbr]

21 hours ago, charlesphoto said:

Optical saga continues: Mikrotik switch headed back to Amazon. With fresh ears and brain this morning A/B'd with an opticalModule to opticalModule and the Mikrotik CRS305 to oM, and the Sonore duo just sounded better. And without the oM able to talk to my Naim in the office the 305 didn't do what I set out for it to, so would have been an expensive FMC.

 

You hear what you hear.

 

That said I would expect the oM NOT to be sensitive to the network feeding it. Particularly on the optical side. But who knows, photons are not perfect quanta.

 

21 hours ago, charlesphoto said:

 

And finally, with some Terminal grunt, I was able to finally reset my Cisco 2960, so now have SFP out to the TP-Link 200 in the office (I already had one on hand), and all the disappearing RJ45  port madness I've been encountering resolved. Sounds great and time to do some work now while discovering great new music (getting tired of my test tracks). 

 

Yes! Most important is that your music flows freely  

[jabbr]

6 hours ago, charlesphoto said:

 

FWIW I think the Mikrotik is a perfectly acceptable sounding switch (powered by a rail of my HDPLEX 100), and probably after burn-in quite close to an opticalModule - on the sending side. I think the superior power regulation in the oM (and powered by an LPS 1.2) on the receiving side pre mR I would only consider the oM.  As it is, the Mikrotik didn't work for what I wanted it to (not its fault), so no amount of burn-in would make me want to hang onto it and lose $ on selling an oM if I don't actually need it as a switch.

 

It was perfectly plug and play - it also ran on poE from my Cisco, except the SFP/RJ45 transceiver I had on hand wouldn't work, so I needed the RJ45 port for ethernet in (it won't do both poE and data at the same time).

 

Agreed. I am finding that not all SFP RJ-45 modules work however the Mikrotik branded ones do. Stick with those for RJ-45 connections, or use the builtin.

 

FWIW I'm not hearing a difference between my (professional grade) Brocade, Mellanox or Mikrotik switches directly feeding my ClearFog. In the case of the Mikrotik I am feeding it a copper RJ45 from the basement Brocade and then output fiber. 

[Audio]

On 7/22/2019 at 8:05 PM, robi20064 said:

Which one had the problematic fan, the QNAP or the Ubiquiti?

 

 

The Ubiquiti has the noisy fans.

 

(Audio)