Optical Network Configurations

[vortecjr]

29 minutes ago, jabbr said:

 

Theres also a meme meme floating around, apparently launched by @JohnSwenson (at least I’ve seen it attributed that way) that  jitter/phase noise in the network bitstream can somehow find its way to the DAC. 10G+ devices are designed to have lower jitter (must hit a tight eye pattern) and if this does affect the DAC somehow then that’s also an advantage. 

What John is proposing is very difficult to measure. Yet some people here claim they can here it’s affects. Maybe those people found to have this special gift can be rewarded an S to wear on their chest:) Seriously, what John is proposing is more for completeness than it is for practice listening advantage compared to other things like power supply noise which is easily measured. 

[vortecjr]

16 hours ago, jabbr said:

@vortecjr I want to comment on the fact that I’m not meaning to say that a 10G switch is better than your bespoke FMC: opticalModule where I understand that it was designed with attention to clock & noise. I’m commenting instead regarding the $25 FMCs or the $100 SFP switches (1Gbe) for which I can’t make any comment on the amount of jitter etc on the wire ... I can’t say either way whether jitter “gets through” these interfaces because I haven’t seen tests — end to end tests aren’t required for 10/100 Mb or 1 Gbe. It’s reasonable to make a high quality FMC for the home audiophile. I can say that jitter doesn’t accumulate and pass through the 10G+ systems because that’s tested for (end to end jitter)

 

I mention this because early on in this thread we recommended cheap FMCs and switches, but I’ve personally moved on from that. (they work fine)

Understood. Let me know if there is anything i can do to help you in your endeavors.

[vortecjr]

Really Alex? Do you claim to hear the difference in the noise floor at the output of your DAC? If you do I have an “S” for you:)

 

I’m talking about structuring things in the order of importance based on measurements. I maintain that the power supply is the foundation of that structure and because it’s easily verified with measurements. Obviously I believe in John’s work and insisted on the oscillators we use. These oscillators finish off the low noise design because of John’s work on the power circuits that feed them. This and other design considerations are for completeness simply because good enough is not best. 

[vortecjr]

1 hour ago, Superdad said:

 

Well, not the "noise floor" but certainly the effect of jitter/phase-noise. 

And you can remember the 2015 history here as well as I do:  

During development of the ISO REGEN--before even putting on the Silanna GI chip--we built two identical versions of an überREGEN, with the one and only difference between them being the version of the clock.  One had the $1.05 Crystek C3391 (as used on the original USB REGEN and microRendu v1.3 and earlier), the other had a $9.70 Crystek CCHD-575.  Took all of 30 seconds to hear the significant difference between them.  

Shortly after--same or next day--either John or I called you (can't remember who) raving and suggesting you try out the CCHD-575 on the microRendu. You did, and that became the microRendu v1.4 board which you offered as an upgrade until the ultraRendu came out.

 

I guess I am just puzzled about why, with your own first-ear and ample anecdotal reports from your own customers, you today seem to be dismissing the relevance of phase-noise/jitter on packet-data interfaces.

Yes, I know we have not yet the measured proof.  [Would either of us like John to stop all product development and problem-fixing work on Sonore and UpTone products to finish the "Golden Gate Bridge clock-block test system" that he and I have been funding for the past two years?] But between the logical hypothesis he has put forth and the many improved-clock products selling and being discussed, I sure don't think people need to be branded with an "S" just for giving the matter consideration when they hear differences. 

 

Of course it won't be very long until the theory of blocking the upstream phase-noise fingerprint of Ethernet is put to test in the market. EtherREGEN puts the Ethernet signal through active LVDS digital isolators and ultra-low-jitter differential flip-flops--with separate power and clocking domains.  Lots of people will be able to compare it to your opticalModule FMC, which, while using a single instance of one of the chips chosen for the  EtherREGEN, and using the same CCHD-575 reference clock, does not have an isolation moat or flops to produce a fully isolated output.  

By being designed by the same mind, with similar voltage regulators, some of the same chips, and the same reference clocking, the comparisons between opticalModule and EtherREGEN will be a very fair test as to if galvanic isolation (via optical) and a simple reclock is enough--or if complete isolation of data/power/clock domains results in further SQ gains for DAC-connected renderer end-points.

 

I know you Jesus, so I know my frank talk above possibly is making you hot under the collar.  So let me finish with two points:

1) I really don't know the answer to the questions raised as I have yet to hear with my own ears an EtherREGEN or an opticalModule. (Full disclosure, I hope/expect the results to be good as I've already spent/bet close to $100K on seeing this through. )

2) EtherREGEN functions as a full multi-port switch, and thus will find much broader usage than your fine FMC. (This despite that we both know the Sonore/UpTone fanboys love to make a ruckus and conflate all this stuff together. )

 

Good times ahead!

--Alex C.

Alex your history is wrong. Adding a better oscillator to the microRendu had nothing to do with the development of your ISO Regen and neither of you called me to suggest this change. Sonore had updated the oscillator on the Rendu SPDIF/i2s unit’s with good results. We bought the oscillators, we had them measured and sorted by phase noise, and we had them installed. This was something that Barrows and I did on our own. Subsequently, Barrows and I wondered what would happen if we did the same with the microRendu and I authorized Barrows to mod a unit as a test. He did, he liked it, and I asked John to update the design for the 1.4 release. No sense to argue this point because I have all the emails. Anyway, since we could not measure why it sounded different in the microRendu I made a conscious decision to always call the change a hardware update, which it was, and I tried never to refer to it as an “upgrade”. I felt then and continue to fell today that if we can’t measure something that we should do our best not to comment about sound quality in the absolute and allow our customers to decide for themselves. Yes we have options and yes we try to guide people.  

 

The above should answer some of your second question but I will expand on things so you understand my position. I have high hopes that John will make the measurements and the world will be in a better place knowing the answer to the question. However, right now I can measure differences with a wide range of power supplies. Yet I have a very difficult time seeing any difference with a power supply or oscillator upgrade someplace upstream on my network. The simple fact remains that the differences in the power supplies at the endpoint are easily observable at the output of the DAC. Even if John proves his hypothesis via measurements its affects are something that is relatively small comparatively speaking.

 

The branding of “S” is only for those claiming super human capabilities and not those providing honest feedback about their systems. If I don’t make this distinction everyone would get an “S” and that would undermine its significance:)

 

The rest of your post sounds like marketing pitch to gain market share. The opticalModule is a fiber media converter made by Sonore which is needed by our opticalRendu and can also be used with other RJ-45 gear such as our micro/ultraRendu. We are making this FMC because we owe it our customers to offer them a complete solution. Your switch will be a much more expense alternative and that is fine by me.

 

I don’t get hot under collar about this stuff because I do this for fun:) 

[vortecjr]

4 hours ago, rickca said:

Why would you offer an update that you're not sure is an improvement?  

I explained this in my post above. However, I’m happy to expand on it though. First let me explain that the main oscillator in the microRendu directly drives the USB output and the processor which indirectly drives the network. Same applies to the ultraRendu. The opticalRendu is the first of our Rendu to have dual low noise oscillators one for the network and one for the USB and CPU. Anyway, during production of the microRendu the lower noise oscillator was not yet available and when it become available it was a natural progression in the design to utilize it. We ran a batch or two of these 1.4 boards so existing customers would not have to purchase an ultraRendu. Understand that John’s hypothesis on why any of the matters was not yet formulated or shared with me until much later so we were simple shooting for lower phase noise. BTW the original oscillator in the microRendu was better than what others were using at the time and is still better than what some are using today;) 

[vortecjr]

4 hours ago, Em2016 said:

 

Hi @JohnSwenson, on this point jabbr brings up, can you share eye patterns of an ultraRendu output?

 

1. ultraRendu alone

2. ultraRendu + opticalModule

3. ultraRendu + etherRegen

 

Using your LPS-1.2 to power everything.

 

I know you're working on measurements for analogue output of a DAC and that will likely take time. That's fine of course - I understand that is a complex undertaking.

 

But eye patterns of the above should be simple enough?

 

In your own development work so far, do you see eye pattern improvements going from #1 to #2 to #3 ?

They are not as simple as you think. To answer your question though we do not have plans to publish them at this time. 

[vortecjr]

4 hours ago, R1200CL said:

And please add the opticalRendu 😀

(Which works fine with the LPS-1.2, as long no, or below 100mA Vbus power drawn from the opticalRendu).

BTW there is an “S” award available for those promoting silly things for selfish reasons. A 100 mA swing is enough to drive the combination into a wired state and damage things. 

[vortecjr]

3 hours ago, R1200CL said:

Is this something you can make public ?

 

Like between the following ones:

iFi SMPS

SGC PS

Sonore Ultra PS

LPS-1.2 both at 7 and 9 V

 

Any other top specified PS like the JS-2 and Paul Hynes ones. 
And maybe add the PS used in the Signature Rendu SE version. 

I have all these measurements and a few more, but not the Paul Hynes power supply. These power supplies are different and each has a value / price point. I have consistently said and will continue to say just use the best power supply you can afford. 

[vortecjr]

5 hours ago, jabbr said:

 

The power supply used to power the opticalRendu is more important than merely for the SFP module and network clock because it’s also supplying the USB and many DACs are bus powered. In all cases the USB touches the DAC.

 

For the FMC I think any reasonably good PSU would suffice, eg linear if the FMC is near the audio equipment. The fiberoptic cable will not transmit leakage current!

 

Professional equipment uses SMPS — I assume well designed because the jitter specs are very tight. But they don’t use really cheap wall warts!

All good points.

[vortecjr]

5 hours ago, jabbr said:

 

A few points. I’d like to keep the discussion here about compatibilities between different fiberoptic Ethernet equipment eg various SFP modules, switches, NICs, FMCs and endpoints.

 

@vortecjr has made it clear that the LPS1.2 power supply is not appropriate for the opticalRendu, so let’s discuss equipment that is intended to be compatible. 

 

Eye pattern testing is not required for 1000base-X (1 Gbe) — I just suggested that it might be used to settle the issue about the effectiveness of fiberoptic isolation. 

 

My understanding is that the opticalRendu ships with a specified Multimode SFP but if folks want to report success with other SFPs including single mode, that would be on topic here and useful for the community in general. I’m not asking Jesus to bless that.

No worries and much appreciated.

[vortecjr]

9 minutes ago, charlesphoto said:

The opticalModules are a product unto themselves imo. Just not ready to go for a second pair yet for the office, so the TP Links good enough for now. I am using Bridge on the microRendu to send Roon to my older Naim Unitiqute, so any goodness I add to the main set up I can hear the results in the office as well. But taking the office TP bridge out altogether the sound did get harder and harsher. Didn't try the oM's there - didn't want to know.

 

I'm done monkeying with the network - too many restarts and hair pulls. I do look at the chain and sometimes think this is untenable. If only one part goes... probably best to just go for the whole hog in one, the Signature optical, but it's also been great to upgrade over time and for not nearly as much $. 

I have a pretty simple network. Router, switch, and wired home runs to various drops. One drop to a wifi access point in the center of the house. The audio room has a dedicated opticalModule for my Rendu.

 

I also have one massive upgrade (being sarcastic) and it’s a battery back unit for my router, switch, access point, and NAS. 

[vortecjr]

12 hours ago, jabbr said:

 

Most protocols at the TCP/IP level rely on standards at the Ethernet level. In this case 802.3x aka "flow control"

 

Standards should be used whenever applicable. In this case "flow control" is not reasonably handled at the TCP/IP level rather by ASICs in network switches and endpoints. It just doesn't work well otherwise. NAA is a usermode application. It cannot effectively implement flow control.

 

 

Wrong. pause-frames are the standard mechanism for flow control.

 

 

This is also wrong. The Linux kernel does not send out pause-frames. pause-frames are sent out by the hardware! In your case the iMX6 MAC sends out the pause-frame, as specified by the Freescale/NXP datasheet and errata!

 

I am sorry John, you are mischaracterizing this situation. The problem is that your iMX6 processor can only internally handle 400Mbs on the 1Gbs port. Freescale/NXP says that this hardware issue should be rectified with the use of pause-frames. The hardware generates them!!!

 

It is entirely unfair to blame NAA for your own oversight. pause-frames are hardly esoteric. This is an unfair characterization. pause-frames are handled by most NICs and switches.

 

My own recommendation, here, is that audio networks should support IEEE 802.3x i.e. flow control given the presence of low powered, low bandwidth endpoints.

 

That all said @vortecjr it seems that you have enabled flow control via the FEC driver (which itself enables the iMX6 hardware pause-frames) and this is the correct behavior. This is indeed the correct fix.

 

Let me also point out that @Miska regularly contributes to the Linux kernel in the ALSA area, which he does for free, and he is largely responsible for the ALSA driver being able to handle DSD. From where I sit he is the expert here. So I felt the need to provide my independent input on this issue --- and apropos this thread, generally recommend that flow control/802.3x be enabled (there are reasons to do this beyond this issue).

 

 

NO, pause-frames are neither esoteric, nor only applicable to NAA, pause-frames are an IEEE standard!!!

 

You should have thought about this because its in the iMX6 datasheet. Don't blame NAA. Sorry this really irritates me just own up to your mistake and issue a fix.

 

The Rendu series has always supported pause frames. Historically, customers have needed extra help with network setup if they used managed switches. The need to enable flow control in the managed switches is required to get things to work properly together. These managed switches as discussed sometimes have their flow control disabled so the request is ignored.

 

Now move forward to the introduction of the opticalModule. Two customs have reported issues with HQ Player / NAA while using an opticalModule and micro/ultraRendu combination. One customer moved to an opticalRendu which has a built-in switch which inherently doesn't have flow control issues. The other customer reports no flow control issues when he excludes the opticalModule from the network. As a result, we added some additional code to Sonic Orbiter to request pause frames when using an opticalModule and John confirmed that this worked in the lab. This fix was then uploaded to all the Rendu software and all is great. Except that this fix still doesn't work for the one customer. We don't know why the fix doesn't work for the customer but we will have an alternative for him to try soon. 

 

Jussi feels singled out here, but that is not the intent. We are simply trying to help a customer with an issue, fix anything that is needed, and move. 

 

Finally, I think you are out of line in the way you spoke to John above. You are not part of the design team, you don't know what is going on behind the scene, and you don't have all the information to accuse him of wrongdoing. 

[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.

[vortecjr]

49 minutes ago, Mike Rubin said:

My Sonore devices show up as Solid Run in Fing, so I strongly suspect they are based on Solid Run hardware. 

We use a SolidRun SOM on the Rendu series with USB output...the main baord is our own design. Optical capabilities have nothing to do with our selection of these SOMs. There is something much more important to us about their SOMs and you can't do it with a Pi SOM and they are not doing it on their boards either:)  

[vortecjr]

9 hours ago, jabbr said:

Solid … choice 😉
 

I’m pretty confused dent that upstream jitter and PSU noise from my servers doesn’t cross my network but the 10Gbe SOM does its own jitter rejection. 

Did you mean the 10Gbe SFP? If not, what SOM are you talking about?

[vortecjr]

tdx let me know if there is anything I can send you to try. 

[vortecjr]

2 minutes ago, lasker98 said:

I have it set for autonegotiate.

I have no expierence with this device, but I would check off Flow Control as well. 

[vortecjr]

Go to the Rendu's home page and add /diag to the units IP address and post the content of that page here.

[vortecjr]

Just know that the opticalRendu have an on board switch and flow control is requested of it on boot. This can be confirmed from the page I pointed you to above.

[vortecjr]

1 hour ago, Bertel said:

Looks like the settings are 'on' so ok?

 

I had read somewhere that some switches revert to 'rx only' with bonded interfaces, could that be the case here? But would that actually cause the stops...?

 

The RX errors are not normal. I’m not certain about the bonded interface.