Getting dropouts when upsampling with Roon to DSD512 and outputting to opticalRendu; thoughts?

[plissken]

I don't see how a switch with flow control would improve a point to point link.

 

Play at DSD 256. If the ST is Linux based I would see if you could SSH to it and run TOP during playback.

[plissken]

1 minute ago, The Computer Audiophile said:

If the Transporter is sending too much too fast, flow control will solve the issue. 

 

That should managed up stack though I would think. I would change to DSD256 sampling and see what happens first.

[plissken]

Flow control is a congestion mitigation mechanism. If there is congestion on the wire the preference with Flow control is to send a pause frame to tell a sender to back off. This is for when there are multiple Tx/Rx sources saturating a link. We would rather pause, than drop traffic (creating a resend and even more traffic and more congestion).

 

I doubt DSD 512 is capable of saturating at 1GBe link. So I don't think it's warranted.

 

But if there is a routing issue and people are multi-homing like described then going to a more traditional flat network like you suggest would make sense.

[plissken]

11 minutes ago, The Computer Audiophile said:

This is where you’re too smart for your own good :~)

 

I can saturate the link with one server sending to a single Rendu easily. I’ve done it and reported it. The Rendu has a Gb interface but internally it isn’t capable of that speed.  
 

When using HQP, I have to enable flow control on my switches to make it work. @Miska has said he won’t change how HQP works because flow control should be enabled on the switch and it resolved the issues. That’s HQP and not Roon of course, but it illustrates my point with a Rendu. 

 

I don't do DSD or high SRC rates so I don't know the data rates, and hence my suggestion of going to DSD 256 initially. It's my nod to that it could be a saturation issue.

 

It sound's like the Rendu has a 100/1000 PHY but not the bus behind it for full wire speed? That's odd for the given costs.

 

I would have to ask @Miska if he's using flow control and relying down layer in the OSI stack for a control mechanism so he doesn't have to make it happen in the session or application layer. Again just a guess on my part.

 

Your suggestion is a good one as it's certainly affordable to try.

 

 

[plissken]

What are your thoughts on just using a Raspberry Pi4 with Volumio to test with?

 

I know the GBe on it is full data rate.

[plissken]

Just now, jiminlogansquare said:

DSD256 definitely eliminates the problem identified at DSD512. No dropouts/gaps in playback at DSD256. However, I want to run at DSD512 if possible, as this delivers - a subjectively, to my ears, in my room and with my music sources - better sound from my T+A DAC 8 DSD. So, I have gone ahead and ordered the switch Chris recommends and try flow control for the Rendu to see whether that allows DSD512 without the glitches.

 

And on preview, I see you agree with Chris’s recommendation. I will report back here after I have implemented it. 
 

One other question, should I implement flow control only for the port assigned to the Rendu, or all the ports I am using (one copper port to hook the switch to the network, two fiber ports to hook the sonicTransporter and Rendu to the network)?

Glad to hear DSD 256 works.

 

You would enable Flow Control on all interfaces in the path.

[plissken]

2 hours ago, Miska said:

Hardware buffer is not so many ethernet MTUs. The NIC itself is capable of generating pause frames to avoid this overflow.

 

I was wondering about this as it's a common option directly on NIC's.

[plissken]

I understand this is a end point buffer issue (overflow) and that Flow Control is used to do this at layer 4 instead of handling it at layer 6 or 7 from a software developer point.

 

 

 

[plissken]

1 minute ago, Miska said:

 

Since it's a hardware buffer overflow and the hardware buffer is not directly visible to the software, best place to deal with it is at the hardware level where there is also sufficient reaction time to the buffer situation. With high level software it would be always late and anyway just guesswork. Especially for stream type protocols like TCP (involving window sizes, etc).

 

So I see it as correctly dealing with the situation at the layer where it also happens...

 

 

I understand but the app dev is relying on the end user setting up flow control or knowing what that is. This is a buffer and not speed issue from my read.

 

What I don't understand is how Sonore advertises DSD512 support with out an * carve out. I didn't see anything about flow control in the online manual shouldn't this be a default on the OS?

[plissken]

35 minutes ago, Miska said:

Which buffer are you talking about? Overflow happens in NIC's hardware packet buffer. 1500 byte MTU's arrive pretty fast at 1 Gbps speed, so there's not much time from hardware buffer reaching high level to the time when you need to send out pause frame. This is why NICs handle this, because on modern OS and NIC you (luckily) don't even get interrupt for every received ethernet MTU.

This is what I'm wondering about. I would hope that the application layer as it's own buffer and can keep NIC FIFO from over filling.

 

It circles back to Chris's thread about buffering and I posed the question about how data streams should be handled at the application layer. I use JRiver and can buffer entire albums in seconds with 10GBe.

[plissken]

I wanted to add some color to this as I did a T-shooting session with Chris and Jim. The data showed that the Rendu, on either SFP port is flapping non-stop.

 

Jim said the SFP was loose and prone to coming out if touched on the Rendu side. Even when the SFP module was reinserted with a bit more force the flapping didn't permanently go away. When it did stay stable it was ping-able and it could be reached by web browser.

 

Jim ordered four replacement SFP's from FS.COM and we will try again.

 

All this brings me to my last point: If you are getting a switch with SFP modules please check with the manufacturer that it has a CLI in addition to the Web Interface. It makes troubleshooting much easier. Even though I wasn't familiar with TP-Links CLI I was able to orient myself in a few minutes and provide diagnostic value. It's clunky as hell but better than nothing :-)

[plissken]

12 hours ago, The Computer Audiophile said:

Hats off to @plissken on this one for putting so much time in. 
 

I agree we shouldn’t make a mountain out of a mole hill, but there also shouldn’t be any dropouts at anytime. We’ll get there on this one. 

 

Another potential solution is to setup rate limiting on the port to 80% of the end point's 400Mbit capacity.