Devialet Chat

(20-May-2019, 19:14)daniel.avasilichioaei Wrote: [ -> ]

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

I'd suggest disabling all the Large Send Offload options, along with Jumbo Frame and both TCP Checksum Offload options to be on the safe side.  If they have Rx and Tx options it's the Tx ones we're interested in.  If that changes the behaviour then we can perhaps narrow down which are significant.

Thanks for indulging me; I hope this is not a waste of time!

(20-May-2019, 19:46)thumb5 Wrote: [ -> ]

(20-May-2019, 19:14)daniel.avasilichioaei Wrote: [ -> ]

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

I'd suggest disabling all the Large Send Offload options, along with Jumbo Frame and both TCP Checksum Offload options to be on the safe side.  If they have Rx and Tx options it's the Tx ones we're interested in.  If that changes the behaviour then we can perhaps narrow down which are significant.

Thanks for indulging me; I hope this is not a waste of time!

@thumb5 - I made the test: same result/issues. I made a second test after I disabled all options containing "Offload", but it doesn't help: the issue is there.

Fair enough. Thanks again for trying the experiment.

Every time I think about this issue I find myself coming back to 3 questions:

- why do some people have it and some people don't?

- why does it only occur with the ethernet input and not with the wifi input?

- why only for giga bit connections?


Logically there has to be a difference in setups somewhere (network connections, device settings/configurations) if it occurs for some people and not for others. 2 areas where we will find differences are:

1- what inputs we have active in our configuration files for our Devialet's. and

2- what zones we have active in our audio settings in Roon.

So, I don't get the problem, the ethernet input is my only active input, and the Roon Ready zone for my 140 is the only zone I have active in Roon. I'm guessing that at least some of those experiencing the problem have more than one input active in their configuration files. I'm guessing that one of those additional active inputs may be the wifi input.

If both the ethernet and wifi inputs are active and receiving a signal the Devialet defaults to ethernet and ignores wifi. Is it possible that has something to do with the issue because the only time I have experienced the issue is when I was trying something and was using a config file with both wifi and ethernet inputs active rather than my normal config file which only has the ethernet input active.

So, if you're having the problem and if both your ethernet and wifi inputs are active, can you try creating a new config file with only the ethernet input active and see if you still get the problem when using a gigabit speed connection.

It's probably a crazy idea but it would be interesting to hear results if a couple of people can try it.

@David A - another possibility is that there are differences between the hardware, such as different revisions of the Ethernet PHY or even the processor on the Core Infinity board. Thinking aloud (again) these might result in subtle timing changes that tip the balance between Gigabit Ethernet working reliably and not.

Hello friends, your experience and error in honor, but what I read so it leads to nothing! As it seems, the error is neither in Devialet or Roon but in their own network at home. To find the source of the error, it would be worth trying the following.

1. A Cat 6/7 cable from the router to your own giga-switch (not manadged switch) for audio streaming
2. A Cat 6/7 cable from the switch to Devialet
3. A Cat 6/7 cable from Switch to Roon Core (Rock or Nucleus)
4. Roon Core on Mac or MS I would not test it, there are several traps, see chat #120...
5. Pay attention to Roon's instructions for switch and router, if necessary adjustments made.
5. Remove all other cables from the router.
6. If the router has multiple outputs, then you could remove all cables, and only the cables to the Devialet and Roon infected. So without an additional switch.

Now I would be curious about the result!
Please report !!

Only a suggestion, to help!

!!!What I have forgotten, it could also be time to report users, where it works and what network constellation they have!!!

When I first started experiencing this problem (when Roon 1.6 was released and Devialet released their latest OS/firmware update), I tried everything I could think of since there were some users that were not experiencing the problem. As time went on, many of those that claimed it worked fine realized that they were, in fact, operating at 10/100 mpbs network speed. But some, as described in this thread and in Roon forums, had it working at gigabit speeds without issue.

Here's a list of the major changes I methodically tried:

-- different PCs running RoonServer or Roon Core
-- different ethernet runs (including different cabling - 6, 6a, 7 - and dramatically different lengths) from PC to router to Devialet
-- different Devialet configs including eliminating all but ethernet input and no wifi
-- two different routers (Pace 5268ac, Dlink)
-- numerous different router settings

The problem was always readily reproduced. It wasn't until I changed the network speed did I find a workaround. Initially, I just changed the network speed to 10/100mbps on the PC running RoonServer. That worked! I then set the PC back to gigabit and placed a cheap 10/100mpbs switch in front of the Devialet. That also worked. Happy it did but clueless as to how/why.

What I have not tried is having two ethernet runs from my RoonServer PC such that one goes to the router and the other establishes a subnet to the Devialet as others have successfully implemented. To do so in my setup would be far more complex than just using the 10/100 switch.

My frustration with both Devialet and Roon is that I have to believe they know what the issue is but are remaining silent about it. It's never surprising that Devialet is silent, but in my experience, when Roon is quiet, it's because they know it's not their problem to fix. Of course, this did pass Roon's QA testing so they are partially responsible for the headaches.

As with all things Devialet, it will get fixed eventually. I suspect it will also require us to pester them periodically. I'd love to better understand the issue, but fortunately, the lower network speed works perfectly (as does using the AIR protocol) so I'm willing to wait patiently (yet read the forums frequently hoping someone shares some further insight ;-)

(20-May-2019, 20:19)daniel.avasilichioaei Wrote: [ -> ]I made the test: same result/issues. I made a second test after I disabled all options containing "Offload", but it doesn't help: the issue is there.

Daniel, I wonder whether we can test the idea that there is a packet loss problem at 1 Gbps but not at 100 Mbps.  One way to do that might be to use the psping command to send a series of back-to-back ping packets from your Roon PC to the Devialet and check what the rate of packet loss is.  For example:


(Needless to say, replace the 192.168.73.2 with the IP address of your Devialet, which from your WireShark traces is 172.168.168.102.)

Repeating this at both 1 Gbps and 100 Mbps might give us some more information about what's going on.

Note that this test doesn't use TCP.  My thinking is that if the Ethernet connection is showing some packet loss at Gigabit speeds, AIR over UDP might cope with that better than RAAT over TCP.

It's not an ideal test because if it reports packet loss we don't know whether they were lost from Roon to Devialet or vice versa, but either would cause problems for a TCP connection.

To everyone else: I hope this is not taking us off-topic or getting boring.  I'm assuming that what @daniel.avasilichioaei posted is related to the problems with RAAT over Gigabit Ethernet.

(21-May-2019, 16:48)thumb5 Wrote: [ -> ]

(20-May-2019, 20:19)daniel.avasilichioaei Wrote: [ -> ]I made the test: same result/issues. I made a second test after I disabled all options containing "Offload", but it doesn't help: the issue is there.

Daniel, I wonder whether we can test the idea that there is a packet loss problem at 1 Gbps but not at 100 Mbps.  One way to do that might be to use the psping command to send a series of back-to-back ping packets from your Roon PC to the Devialet and check what the rate of packet loss is.  For example:

Code:

C:\PSTools>psping -n 100 -i 0 -l 1420 192.168.73.2

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 192.168.73.2 with 1420 bytes of data:
101 iterations (warmup 1) ping test:
Reply from 192.168.73.2: 0.87ms
Reply from 192.168.73.2: 0.74ms
...
Reply from 192.168.73.2: 0.46ms
Reply from 192.168.73.2: 0.47ms

Ping statistics for 192.168.73.2:
 Sent = 100, Received = 100, Lost = 0 (0% loss),
 Minimum = 0.37ms, Maximum = 1.21ms, Average = 0.54ms

C:\PSTools>

(Needless to say, replace the 192.168.73.2 with the IP address of your Devialet, which from your WireShark traces is 172.168.168.102.)

Repeating this at both 1 Gbps and 100 Mbps might give us some more information about what's going on.

Note that this test doesn't use TCP.  My thinking is that if the Ethernet connection is showing some packet loss at Gigabit speeds, AIR over UDP might cope with that better than RAAT over TCP.

It's not an ideal test because if it reports packet loss we don't know whether they were lost from Roon to Devialet or vice versa, but either would cause problems for a TCP connection.

To everyone else: I hope this is not taking us off-topic or getting boring.  I'm assuming that what @daniel.avasilichioaei posted is related to the problems with RAAT over Gigabit Ethernet.

@thumb5 - I cannot run PSPING on my PC (Windows 10 Pro x64): I'm getting "Access is denied".
[attachment=3461]

(21-May-2019, 16:48)thumb5 Wrote: [ -> ]

(20-May-2019, 20:19)daniel.avasilichioaei Wrote: [ -> ]I made the test: same result/issues. I made a second test after I disabled all options containing "Offload", but it doesn't help: the issue is there.

Daniel, I wonder whether we can test the idea that there is a packet loss problem at 1 Gbps but not at 100 Mbps.  One way to do that might be to use the psping command to send a series of back-to-back ping packets from your Roon PC to the Devialet and check what the rate of packet loss is.  For example:

Code:

C:\PSTools>psping -n 100 -i 0 -l 1420 192.168.73.2

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 192.168.73.2 with 1420 bytes of data:
101 iterations (warmup 1) ping test:
Reply from 192.168.73.2: 0.87ms
Reply from 192.168.73.2: 0.74ms
...
Reply from 192.168.73.2: 0.46ms
Reply from 192.168.73.2: 0.47ms

Ping statistics for 192.168.73.2:
 Sent = 100, Received = 100, Lost = 0 (0% loss),
 Minimum = 0.37ms, Maximum = 1.21ms, Average = 0.54ms

C:\PSTools>

(Needless to say, replace the 192.168.73.2 with the IP address of your Devialet, which from your WireShark traces is 172.168.168.102.)

Repeating this at both 1 Gbps and 100 Mbps might give us some more information about what's going on.

Note that this test doesn't use TCP.  My thinking is that if the Ethernet connection is showing some packet loss at Gigabit speeds, AIR over UDP might cope with that better than RAAT over TCP.

It's not an ideal test because if it reports packet loss we don't know whether they were lost from Roon to Devialet or vice versa, but either would cause problems for a TCP connection.

To everyone else: I hope this is not taking us off-topic or getting boring.  I'm assuming that what @daniel.avasilichioaei posted is related to the problems with RAAT over Gigabit Ethernet.

@thumb5  - Done (psping64, instead of psping). No packet loss on both 100/1000 Mbps.

1000 Mpbs
[attachment=3462]

100 Mpbs
[attachment=3463]