+- Devialet Chat (https://devialetchat.com)
+-- Forum: Devialet Chat (https://devialetchat.com/Forum-Devialet-Chat)
+--- Forum: Streaming (https://devialetchat.com/Forum-Streaming)
+--- Thread: Roon RAAT and "An audio file is loading slowly" (/Thread-Roon-RAAT-and-An-audio-file-is-loading-slowly)
RE: Roon RAAT and "An audio file is loading slowly" - thumb5 - 19-May-2019
(19-May-2019, 10:16)daniel.avasilichioaei Wrote: After reading all very helpful replays to my previous test, I decide to make an additional test: for my dedicated network card for Roon Core - Devialet communication, I forced connection speed to 100/1000 Mbps, and repeat the test for both Roon READY and Roon AIR, using the same track (MQA 192kHz). Result is here attached.
My observations:As far as I can see, both protocols are fine, but there is a handshake issue between Roon READY and Devialet Expert on 1000 Mbps network.
- Roon AIR acting in a very similar way for both 100/1000 Mbps connections (same amount and fluctuations for network traffic).
- On 100 Mbps connection, both Roon READY and Roon AIR are acting in a very similar way, and both are working fine with no issues at all. Indeed, ROON Ready is generating a very little more network traffic, and it is a little more fluctuating. Since we are speaking about different protocols, I believe that both differences are absolutely normal.
- On 1000 Mbps connection, Roon REDAY is getting crazy: it is generating a huge amount of additional network traffic, and also very big fluctuations.
That's an interesting discovery. Can you get Wireshark traces for Roon RAAT (Roon Ready) at both 100 Mbps and 1 Gbps for comparison? If so I'd be happy to take a look and let you know if I can see what's going on.
RE: Roon RAAT and "An audio file is loading slowly" - daniel.avasilichioaei - 19-May-2019
(19-May-2019, 11:18)thumb5 Wrote:(19-May-2019, 10:16)daniel.avasilichioaei Wrote: After reading all very helpful replays to my previous test, I decide to make an additional test: for my dedicated network card for Roon Core - Devialet communication, I forced connection speed to 100/1000 Mbps, and repeat the test for both Roon READY and Roon AIR, using the same track (MQA 192kHz). Result is here attached.
My observations:As far as I can see, both protocols are fine, but there is a handshake issue between Roon READY and Devialet Expert on 1000 Mbps network.
- Roon AIR acting in a very similar way for both 100/1000 Mbps connections (same amount and fluctuations for network traffic).
- On 100 Mbps connection, both Roon READY and Roon AIR are acting in a very similar way, and both are working fine with no issues at all. Indeed, ROON Ready is generating a very little more network traffic, and it is a little more fluctuating. Since we are speaking about different protocols, I believe that both differences are absolutely normal.
- On 1000 Mbps connection, Roon REDAY is getting crazy: it is generating a huge amount of additional network traffic, and also very big fluctuations.
That's an interesting discovery. Can you get Wireshark traces for Roon RAAT (Roon Ready) at both 100 Mbps and 1 Gbps for comparison? If so I'd be happy to take a look and let you know if I can see what's going on.
I made the Wireshark traces for Roon RAAT. Each one is containing:
- ~10 seconds with silence (no music)
- ~60 seconds of MQA 192kHz (the same track, from 0 to 60 seconds)
- ~10 seconds with silence (no music)
I cannot attach the files here, because they are too large. How can I send the files to you?
Thank you!
RE: Roon RAAT and "An audio file is loading slowly" - daniel.avasilichioaei - 19-May-2019
(19-May-2019, 11:18)thumb5 Wrote:(19-May-2019, 10:16)daniel.avasilichioaei Wrote: After reading all very helpful replays to my previous test, I decide to make an additional test: for my dedicated network card for Roon Core - Devialet communication, I forced connection speed to 100/1000 Mbps, and repeat the test for both Roon READY and Roon AIR, using the same track (MQA 192kHz). Result is here attached.
My observations:As far as I can see, both protocols are fine, but there is a handshake issue between Roon READY and Devialet Expert on 1000 Mbps network.
- Roon AIR acting in a very similar way for both 100/1000 Mbps connections (same amount and fluctuations for network traffic).
- On 100 Mbps connection, both Roon READY and Roon AIR are acting in a very similar way, and both are working fine with no issues at all. Indeed, ROON Ready is generating a very little more network traffic, and it is a little more fluctuating. Since we are speaking about different protocols, I believe that both differences are absolutely normal.
- On 1000 Mbps connection, Roon REDAY is getting crazy: it is generating a huge amount of additional network traffic, and also very big fluctuations.
That's an interesting discovery. Can you get Wireshark traces for Roon RAAT (Roon Ready) at both 100 Mbps and 1 Gbps for comparison? If so I'd be happy to take a look and let you know if I can see what's going on.
Please try this link: https://we.tl/t-0TpuzCyZqV
RE: Roon RAAT and "An audio file is loading slowly" - thumb5 - 19-May-2019
Thanks Daniel, got the traces.
At first sight, it looks to me as though the main difference is that there are a lot of packet drops on the way from Roon to the Devialet at 1 Gbps, whereas there none at all at 100 Mbps. This probably also accounts for the high rate of back-traffic from the Devialet to Roon.
I'll have a more detailed look and report back shortly.
RE: Roon RAAT and "An audio file is loading slowly" - K4680 - 19-May-2019
Hi, just a thought someone has ever tried Mulicast / IGMP on the router on or off. If so, has it affected the traffic load?
"IGMP (Internet Group Management Protocol) Snooping".
Router Specific Settings (Roon)
Some routers have settings that can cause interference with Roon's communication to endpoints and Remote devices. Below are some of the common configuration changes that have been required for some routers to function properly with Roon.
Netgear Orbi Routers
If you’re making use of an Orbi router, we recommend unchecking Disable IGMP Proxying in your router’s settings. This setting can interfere with the ability for Roon Remotes to connect to the Roon Core.
Technicolor Routers
We've seen that some technicolor routers cause Roon to have difficulties communicating to networked endpoints. This can be resolved by adding exceptions for Roon and RAATServer to the router's IPv6 firewall settings.
Motorola Routers
Some Motorola routers have a setting called Energy Efficient Ethernet. This setting has previously been known to cause occasional dropouts during playback to networked endpoints. Disabling this setting can help alleviate these dropouts.
FRITZ OS 7
The FRITZ OS 7 update includes a feature called "Software Packet Acceleration" that can cause issues with remote connectivity. We recommend disabling this setting from the FRITZ GUI.
ASUS Routers
We recommend enabling "Enable Multicast Routing" option in settings.
Netgear R7000
We recommend disabling the "Enable Smart Connect" setting.
Synology 1600
We recommend enabling "IGMP Proxying" and/or "IGMP Snooping"
Getting Further Help From Roon Support
If you’re in need of further troubleshooting assistance, get in touch with our team by posting details in the Support section of Community. (From Roon User Guide)
RE: Roon RAAT and "An audio file is loading slowly" - thumb5 - 19-May-2019
Some more observations:
It looks like the variation in network traffic is all down to the TCP flow carrying audio from Roon to the Devialet (as expected). There is UDP in both traces but at a similarly low frequency in both - I guess this is probably the Devialet discovery protocol (as used for AIR).
As I said in my previous post, the TCP flow at 100 Mbps looks very clean with no re-transmissions. After things settle down, Roon is consistently sending super-jumbo frames of about 60 KB each. The round-trip time is very stable - about 6 ms almost all the time, with very occasional peaks upto about 15 ms.
At 1 Gbps there are lots of bursts of duplicate ACKs from the Devialet and re-transmissions from Roon. This suggests frames are frequently being lost en route. The round-trip time is also (consequently) much more variable, with peaks up to 800 ms, and the frame size is much smaller on average (1.5 - 2.5 KB by eye). The most likely cause is that either the Ethernet hardware on the Devialet is running out of receive buffers or (less likely, I'd say) the application software on the Devialet isn't handling the input fast enough.
It looks as though the Devialet is advertising a larger receive window at 1 Gbps than at 100 Mbps (~1 MB vs ~ 0.4 MB). Maybe that is significant.
As far as I can see, the variation in network flow from Roon to the Devialet is because the traffic is stopping and starting due to the presumed missing packets. Because the flow is carried in much smaller frames, there is a higher protocol overhead which will tend to increase the overall network throughput. Also, the smaller average frame size accounts for the much higher level of "back-traffic" because there are many more ACKs coming back from the Devialet for a given volume of data sent to it.
There must surely be some hints in here about what's causing the problems with Devialet/Roon RAAT at 1 Gbps. I am suspicious about the higher advertised window size at 1 Gpbs and wonder whether the Devialet is asking for more incoming data than it can actually handle - that is, without dropping frames.
Thanks again for sending the traces, @daniel.avasilichioaei. If I get chance to do any more analysis I'll add further notes here.
RE: Roon RAAT and "An audio file is loading slowly" - daniel.avasilichioaei - 19-May-2019
(19-May-2019, 18:05)thumb5 Wrote: Some more observations:
It looks like the variation in network traffic is all down to the TCP flow carrying audio from Roon to the Devialet (as expected). There is UDP in both traces but at a similarly low frequency in both - I guess this is probably the Devialet discovery protocol (as used for AIR).
As I said in my previous post, the TCP flow at 100 Mbps looks very clean with no re-transmissions. After things settle down, Roon is consistently sending super-jumbo frames of about 60 KB each. The round-trip time is very stable - about 6 ms almost all the time, with very occasional peaks upto about 15 ms.
At 1 Gbps there are lots of bursts of duplicate ACKs from the Devialet and re-transmissions from Roon. This suggests frames are frequently being lost en route. The round-trip time is also (consequently) much more variable, with peaks up to 800 ms, and the frame size is much smaller on average (1.5 - 2.5 KB by eye). The most likely cause is that either the Ethernet hardware on the Devialet is running out of receive buffers or (less likely, I'd say) the application software on the Devialet isn't handling the input fast enough.
It looks as though the Devialet is advertising a larger receive window at 1 Gbps than at 100 Mbps (~1 MB vs ~ 0.4 MB). Maybe that is significant.
As far as I can see, the variation in network flow from Roon to the Devialet is because the traffic is stopping and starting due to the presumed missing packets. Because the flow is carried in much smaller frames, there is a higher protocol overhead which will tend to increase the overall network throughput. Also, the smaller average frame size accounts for the much higher level of "back-traffic" because there are many more ACKs coming back from the Devialet for a given volume of data sent to it.
There must surely be some hints in here about what's causing the problems with Devialet/Roon RAAT at 1 Gbps. I am suspicious about the higher advertised window size at 1 Gpbs and wonder whether the Devialet is asking for more incoming data than it can actually handle - that is, without dropping frames.
Thanks again for sending the traces, @daniel.avasilichioaei. If I get chance to do any more analysis I'll add further notes here.
Thank you very much for your work!
I'm not sure I fully understand your investigation, but to me it seems that most probably the issue is on Devialet side (not on Roon side). Am I right?
P.S.: On my configuration, the issue is the same (at least his effect), no matter if connection is Roon Core - Devialet [i]directly or via router.[/i]
RE: Roon RAAT and "An audio file is loading slowly" - thumb5 - 20-May-2019
(19-May-2019, 18:22)daniel.avasilichioaei Wrote: Thank you very much for your work!
I'm not sure I fully understand your investigation, but to me it seems that most probably the issue is on Devialet side (not on Roon side). Am I right?
P.S.: On my configuration, the issue is the same (at least his effect), no matter if connection is Roon Core - Devialet [i]directly or via router.[/i]
I've been thinking about those traces; the apparently very large frames were bothering me. It turns out that was probably a red herring, and on the wire there most likely isn't a significant difference in frame size between the 100 Mbps and 1 Gbps cases. Sorry for the confusion on my part.
Looking at the traces again, it seems that in the 1 Gbps case the first sign of trouble comes very soon after the data flow starts. In fact at that point the Devialet has only received about 7 KB of data, which is about four normal-sized Ethernet frames. So it's hard to believe that's the result of a buffering problem on the Devialet side as I thought yesterday.
Although it looks as though the Devialet is somehow not processing a frame that Roon has sent - as if the frame has been lost in transit - there might be several reasons for that and it wouldn't be fair to blame the Devialet based only on what can be seen from the Wireshark traces.
RE: Roon RAAT and "An audio file is loading slowly" - thumb5 - 20-May-2019
@daniel.avasilichioaei - it looks as though your E2200 Ethernet adapter supports offloading some TCP send processing to the hardware. Do you have "large send offload" enabled for your adapter? If so it would be interesting to turn it off and try your tests again. Just thinking aloud here...
RE: Roon RAAT and "An audio file is loading slowly" - daniel.avasilichioaei - 20-May-2019
(20-May-2019, 18:27)thumb5 Wrote: @daniel.avasilichioaei - it looks as though your E2200 Ethernet adapter supports offloading some TCP send processing to the hardware. Do you have "large send offload" enabled for your adapter? If so it would be interesting to turn it off and try your tests again. Just thinking aloud here...
@thumb5 - Yes, I have multiple "Large Send Offload", all enabled (this is the default value). I also have multiple other "Offloads", also all enabled (or "Rx & Tx Enabled"). Which ones should I disable for retesting?
Note:
During my test, these settings were not changed, they were the same for both 100/1000 Mbps.
The issue is the same (at least his effect) when using connection is Roon Core - Devialet via router and another network card (Intel). This one also have "Offloads" enabled.