Jump to content
IGNORED

Sporadic ping times (case closed)


Recommended Posts

I get sporadic ping times from the microrendu. it could be <1ms then up to 75ms. It's really all over the board. I noticed for a period of time it would start high at say 60ms then drop incrementally 59, 57, 55, 54....36,35,34...19,18,17 until it got in the single digits then bounce back up again. Every other device on my network gets <1ms ping times. I've tried different cables. It is the microrendu. What's the issue and what can be done to resolve it?

Link to comment
I get sporadic ping times from the microrendu. it could be <1ms then up to 75ms. It's really all over the board. I noticed for a period of time it would start high at say 60ms then drop incrementally 59, 57, 55, 54....36,35,34...19,18,17 until it got in the single digits then bounce back up again. Every other device on my network gets <1ms ping times. I've tried different cables. It is the microrendu. What's the issue and what can be done to resolve it?

 

I don't know for sure what is going on here, but my guess is the ICMP reply has been given a low priority so audio packets have a high priority.

 

John S.

Link to comment
We don't have any data on that the typical ping time is with different systems. We also don't specify a ping time for the unit.

 

Should I assume that my unit is defective because the ping time is inconsistent and high? Ping times between devices on the same network are typically consistent while networks "may" vary. There is a threshold, especially in a home network with typically one hop through the router or switch. A home network threshold is usually about 1ms. Either the NIC on the microRendu is faulty, or something else is going on.

Link to comment
I get sporadic ping times from the microrendu. it could be <1ms then up to 75ms. It's really all over the board. I noticed for a period of time it would start high at say 60ms then drop incrementally 59, 57, 55, 54....36,35,34...19,18,17 until it got in the single digits then bounce back up again. Every other device on my network gets <1ms ping times. I've tried different cables. It is the microrendu. What's the issue and what can be done to resolve it?

I get very similar results.

Pareto Audio AMD 7700 Server --> Berkeley Alpha USB --> Jeff Rowland Aeris --> Jeff Rowland 625 S2 --> Focal Utopia 3 Diablos with 2 x Focal Electra SW 1000 BE subs

 

i7-6700K/Windows 10  --> EVGA Nu Audio Card --> Focal CMS50's 

Link to comment
Should I assume that my unit is defective because the ping time is inconsistent and high? Ping times between devices on the same network are typically consistent while networks "may" vary. There is a threshold, especially in a home network with typically one hop through the router or switch. A home network threshold is usually about 1ms. Either the NIC on the microRendu is faulty, or something else is going on.

 

I don't think it is malfunctioning, mine do it to. As I mentioned I'm pretty sure it has to do with thread priorities. My guess is that since the microRendu is a dedicated audio device the audio specific threads have increased priority which means that non audio threads such as replying to a ping take a backseat, which means that if an audio thread is busy processing audio data the replay to a ping packet will wait.

 

The wide spread in ping delays tends to support this. If a ping packet arrives when there is no audio processing happening, it gets replied to very quickly. If there IS audio processing going on it waits until it is finished which is most likely going to be a random amount of time since the ping packet is not going to be synchronized with the audio system.

 

It does NOT mean there is something wrong with the network hardware, just that audio processing is considered more important than replying to a ping.

 

On a general purpose system with a general purpose OS a ping will interrupt the audio processes giving you a quick turn around time, as you noticed on your other computers. But is interrupting the audio processes so there is a very fast reply to a ping really a good thing for an audio specific system?

 

John S.

Link to comment
The wide spread in ping delays tends to support this. If a ping packet arrives when there is no audio processing happening, it gets replied to very quickly. If there IS audio processing going on it waits until it is finished which is most likely going to be a random amount of time since the ping packet is not going to be synchronized with the audio system.

I get the ping results that Johnseye reports when the micro rendu isn't doing any audio processing ... the DLNA/MPD app is active, but no music is playing. I don't even have a BubbleUPnP controller active talking to the micro rendu.

 

I'm not saying this is a problem, I'm just confirming his results.

Pareto Audio AMD 7700 Server --> Berkeley Alpha USB --> Jeff Rowland Aeris --> Jeff Rowland 625 S2 --> Focal Utopia 3 Diablos with 2 x Focal Electra SW 1000 BE subs

 

i7-6700K/Windows 10  --> EVGA Nu Audio Card --> Focal CMS50's 

Link to comment
I don't think it is malfunctioning, mine do it to. As I mentioned I'm pretty sure it has to do with thread priorities. My guess is that since the microRendu is a dedicated audio device the audio specific threads have increased priority which means that non audio threads such as replying to a ping take a backseat, which means that if an audio thread is busy processing audio data the replay to a ping packet will wait.

 

The wide spread in ping delays tends to support this. If a ping packet arrives when there is no audio processing happening, it gets replied to very quickly. If there IS audio processing going on it waits until it is finished which is most likely going to be a random amount of time since the ping packet is not going to be synchronized with the audio system.

 

It does NOT mean there is something wrong with the network hardware, just that audio processing is considered more important than replying to a ping.

 

On a general purpose system with a general purpose OS a ping will interrupt the audio processes giving you a quick turn around time, as you noticed on your other computers. But is interrupting the audio processes so there is a very fast reply to a ping really a good thing for an audio specific system?

 

John S.

John, it exhibits the same behavior when no audio is being processed, thus no thread prioritization or usage. The device should be idle otherwise. Ping response should be immediate, 1ms or less.

 

I believe you are the developer of the microRendu. No offence please, but are you able to provide more than a "guess"? Sorry, your words.

 

If this is due to CPU lag then there could be a significant issue with this device beyond a faulty NIC. If it is CPU lag there could be problems due to temperature (the mRendu does run warm) a driver issue, etc.

Link to comment
I think this is the wrong forum for a discussion of ping response time and the IP stack.

 

 

Sent from my iPad using Computer Audiophile

 

Maybe if we were talking conceptually only. This is specific to the microRendu and has been duplicated. Not sure why you would want to talk about it elsewhere considering we aren't talking about any other device except the microRendu.

 

I'm also considering this a support request. Sonore links this forum as access to their support, and I think it's their only method of support.

Link to comment

The response times will be influenced by what happens in the network and/or in the IP stack of the microRendu. I doubt very much anyone on CA has delved into the Linux IP stack to investigate this. Perhaps at a network programming site you will find someone who has studied ICMP implementations.

Link to comment
The response times will be influenced by what happens in the network and/or in the IP stack of the microRendu. I doubt very much anyone on CA has delved into the Linux IP stack to investigate this. Perhaps at a network programming site you will find someone who has studied ICMP implementations.

I think you'd be surprised about who posts here and what their professional backgrounds are. But I'm looking for an answer from the manufacturer, Sonore, about what in any network device in the market would be considered a problem.

Link to comment
Maybe if we were talking conceptually only. This is specific to the microRendu and has been duplicated. Not sure why you would want to talk about it elsewhere considering we aren't talking about any other device except the microRendu.

 

I'm also considering this a support request. Sonore links this forum as access to their support, and I think it's their only method of support.

 

I ran a quick test today. I downloaded a generic iMX6 debian image, put it on another uSD card, put that in the microRendu and powered it up, waited a couple minutes to make sure it booted, then looked up the IP address in my router's DHCP list and pinged it.

 

ALL responses came up with less than 1ms.

 

This is NOT a hardware issue!! There is a high probability it is something related to thread priorities which were modified from normal OS in order to improve the performance of the things related to audio, the primary purpose of this device.

 

That is all I can do for you right now. Andrew is the one that has done all the OS tuning in order to get the best performance from the audio stuff, he is the one that is going to have to answer any more details on this.

 

I am moving in less than a week and am frantically trying to get my house packed up, I simply do not have any more time to deal with this and anything I would need to dig into this any further have been packed up and will not be accessible for several months.

 

This is not a hardware problem and I do not consider it a software "problem" either. If super low ping response is so critically important, you are going to have to work with Andrew on this.

 

Signing off.

 

John S.

Link to comment
I ran a quick test today. I downloaded a generic iMX6 debian image, put it on another uSD card, put that in the microRendu and powered it up, waited a couple minutes to make sure it booted, then looked up the IP address in my router's DHCP list and pinged it.

 

ALL responses came up with less than 1ms.

 

This is NOT a hardware issue!! There is a high probability it is something related to thread priorities which were modified from normal OS in order to improve the performance of the things related to audio, the primary purpose of this device.

 

That is all I can do for you right now. Andrew is the one that has done all the OS tuning in order to get the best performance from the audio stuff, he is the one that is going to have to answer any more details on this.

 

I am moving in less than a week and am frantically trying to get my house packed up, I simply do not have any more time to deal with this and anything I would need to dig into this any further have been packed up and will not be accessible for several months.

 

This is not a hardware problem and I do not consider it a software "problem" either. If super low ping response is so critically important, you are going to have to work with Andrew on this.

 

Signing off.

 

John S.

 

Thanks for the response John, and thanks for the test, especially in the midst of a move. I know how much that can suck. Your test brings us closer to the answer assuming you ran the test on the same device you also experienced high ping times on previously. If that's the case it's very likely not a NIC issue.

 

It could still be a driver issue, and this is more likely the cause. It could also be CPU lag based on the OS config. Because it occurs when there is no audio being processed, or any other activity, it wouldn't be a thread prioritization.

 

This isn't to improve ping time obviously, it's to ensure audio packet delivery is't hampered by latency. It's also to ensure the health of the device is good.

 

Are you or Jesus able to contact Andrew so that he can comment?

Link to comment
Thanks for the response John, and thanks for the test, especially in the midst of a move. I know how much that can suck. Your test brings us closer to the answer assuming you ran the test on the same device you also experienced high ping times on previously. If that's the case it's very likely not a NIC issue.

 

It could still be a driver issue, and this is more likely the cause. It could also be CPU lag based on the OS config. Because it occurs when there is no audio being processed, or any other activity, it wouldn't be a thread prioritization.

 

This isn't to improve ping time obviously, it's to ensure audio packet delivery is't hampered by latency. It's also to ensure the health of the device is good.

 

Are you or Jesus able to contact Andrew so that he can comment?

 

There is no need to contact Andrew. We are at the tale end of development on Version 2.4 of Sonicorbiter. I have put a note for us to look into this during development of Version 2.5 of Sonicorbiter. At that point, we will decide what if anything needs to be done.

Link to comment
There is no need to contact Andrew. We are at the tale end of development on Version 2.4 of Sonicorbiter. I have put a note for us to look into this during development of Version 2.5 of Sonicorbiter. At that point, we will decide what if anything needs to be done.

OK Jesus, thanks. It's worth investigating whether the current ping behavior means there is some potential to further optimize Sonicorbiter and make the micro rendu an even better device.

Pareto Audio AMD 7700 Server --> Berkeley Alpha USB --> Jeff Rowland Aeris --> Jeff Rowland 625 S2 --> Focal Utopia 3 Diablos with 2 x Focal Electra SW 1000 BE subs

 

i7-6700K/Windows 10  --> EVGA Nu Audio Card --> Focal CMS50's 

Link to comment
There is no need to contact Andrew. We are at the tale end of development on Version 2.4 of Sonicorbiter. I have put a note for us to look into this during development of Version 2.5 of Sonicorbiter. At that point, we will decide what if anything needs to be done.

Ok, so you're not going to release a fix in the next OS release, but you'll look into it for the following release. This tells me you don't know what the cause is, it's not an easy fix, but you're looking into it. Glad it made it to your bug list. Looking forward to version 2.5. Thanks.

Link to comment
Ok, so you're not going to release a fix in the next OS release, but you'll look into it for the following release. This tells me you don't know what the cause is, it's not an easy fix, but you're looking into it. Glad it made it to your bug list. Looking forward to version 2.5. Thanks.

 

All it means is that we are not working updating the operating system in Version 2.4 of Sonicorbiter. We are going to release a new feature in Version 2.4 of Sonicorbiter along with some other general updates. In version 2.5 of Sonicorbiter we will be working on the operating system and that is when we will look into this issue.

Link to comment

Here is the ping time on my system with the unit at idle:

64 bytes from 192.168.0.228: icmp_seq=0 ttl=64 time=43.476 ms

64 bytes from 192.168.0.228: icmp_seq=1 ttl=64 time=46.293 ms

64 bytes from 192.168.0.228: icmp_seq=2 ttl=64 time=41.179 ms

64 bytes from 192.168.0.228: icmp_seq=3 ttl=64 time=34.044 ms

64 bytes from 192.168.0.228: icmp_seq=4 ttl=64 time=28.942 ms

 

Here is the ping time on my system with the unit playing DSD256:

64 bytes from 192.168.0.228: icmp_seq=0 ttl=64 time=1.337 ms

64 bytes from 192.168.0.228: icmp_seq=1 ttl=64 time=1.824 ms

64 bytes from 192.168.0.228: icmp_seq=2 ttl=64 time=1.570 ms

64 bytes from 192.168.0.228: icmp_seq=3 ttl=64 time=1.426 ms

64 bytes from 192.168.0.228: icmp_seq=4 ttl=64 time=1.994 ms

 

Someone actually gave you the hint back in one of threads...just listen to music.

Link to comment
  • vortecjr locked this topic
  • 1 month later...

Because some were "concerned", ping results from microRendu running the latest 2.5 update:

 

64 bytes from 192.168.0.135: icmp_seq=0 ttl=64 time=3.432 ms

64 bytes from 192.168.0.135: icmp_seq=1 ttl=64 time=3.655 ms

64 bytes from 192.168.0.135: icmp_seq=2 ttl=64 time=3.006 ms

64 bytes from 192.168.0.135: icmp_seq=3 ttl=64 time=2.142 ms

64 bytes from 192.168.0.135: icmp_seq=4 ttl=64 time=3.685 ms

64 bytes from 192.168.0.135: icmp_seq=5 ttl=64 time=5.450 ms

64 bytes from 192.168.0.135: icmp_seq=6 ttl=64 time=3.074 ms

64 bytes from 192.168.0.135: icmp_seq=7 ttl=64 time=4.541 ms

64 bytes from 192.168.0.135: icmp_seq=8 ttl=64 time=2.859 ms

64 bytes from 192.168.0.135: icmp_seq=9 ttl=64 time=2.791 ms

64 bytes from 192.168.0.135: icmp_seq=10 ttl=64 time=2.576 ms

64 bytes from 192.168.0.135: icmp_seq=11 ttl=64 time=2.468 ms

64 bytes from 192.168.0.135: icmp_seq=12 ttl=64 time=2.213 ms

64 bytes from 192.168.0.135: icmp_seq=13 ttl=64 time=3.389 ms

64 bytes from 192.168.0.135: icmp_seq=14 ttl=64 time=2.706 ms

64 bytes from 192.168.0.135: icmp_seq=15 ttl=64 time=2.910 ms

64 bytes from 192.168.0.135: icmp_seq=16 ttl=64 time=3.002 ms

64 bytes from 192.168.0.135: icmp_seq=17 ttl=64 time=2.295 ms

64 bytes from 192.168.0.135: icmp_seq=18 ttl=64 time=5.527 ms

64 bytes from 192.168.0.135: icmp_seq=19 ttl=64 time=3.605 ms

64 bytes from 192.168.0.135: icmp_seq=20 ttl=64 time=6.029 ms

 

Pretty consistent, and a lot lower than before . . . which should make absolutely no difference to the sound quality or functionality of the unit ;)

John Walker - IT Executive

Headphone - SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable Ethernet > mRendu Roon endpoint > Topping D90 > Topping A90d > Dan Clark Expanse / HiFiMan H6SE v2 / HiFiman Arya Stealth

Home Theater / Music -SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable HDMI > Denon X3700h > Anthem Amp for front channels > Revel F208-based 5.2.4 Atmos speaker system

Link to comment
22 minutes ago, jhwalker said:

Because some were "concerned", ping results from microRendu running the latest 2.5 update:

 

64 bytes from 192.168.0.135: icmp_seq=0 ttl=64 time=3.432 ms

64 bytes from 192.168.0.135: icmp_seq=1 ttl=64 time=3.655 ms

64 bytes from 192.168.0.135: icmp_seq=2 ttl=64 time=3.006 ms

64 bytes from 192.168.0.135: icmp_seq=3 ttl=64 time=2.142 ms

64 bytes from 192.168.0.135: icmp_seq=4 ttl=64 time=3.685 ms

64 bytes from 192.168.0.135: icmp_seq=5 ttl=64 time=5.450 ms

64 bytes from 192.168.0.135: icmp_seq=6 ttl=64 time=3.074 ms

64 bytes from 192.168.0.135: icmp_seq=7 ttl=64 time=4.541 ms

64 bytes from 192.168.0.135: icmp_seq=8 ttl=64 time=2.859 ms

64 bytes from 192.168.0.135: icmp_seq=9 ttl=64 time=2.791 ms

64 bytes from 192.168.0.135: icmp_seq=10 ttl=64 time=2.576 ms

64 bytes from 192.168.0.135: icmp_seq=11 ttl=64 time=2.468 ms

64 bytes from 192.168.0.135: icmp_seq=12 ttl=64 time=2.213 ms

64 bytes from 192.168.0.135: icmp_seq=13 ttl=64 time=3.389 ms

64 bytes from 192.168.0.135: icmp_seq=14 ttl=64 time=2.706 ms

64 bytes from 192.168.0.135: icmp_seq=15 ttl=64 time=2.910 ms

64 bytes from 192.168.0.135: icmp_seq=16 ttl=64 time=3.002 ms

64 bytes from 192.168.0.135: icmp_seq=17 ttl=64 time=2.295 ms

64 bytes from 192.168.0.135: icmp_seq=18 ttl=64 time=5.527 ms

64 bytes from 192.168.0.135: icmp_seq=19 ttl=64 time=3.605 ms

64 bytes from 192.168.0.135: icmp_seq=20 ttl=64 time=6.029 ms

 

Pretty consistent, and a lot lower than before . . . which should make absolutely no difference to the sound quality or functionality of the unit ;)

 

Yes, this is what Jesus shared with me.  It is better.  I will share a quote from Chris's review of another device in which he compares the mR. "On the rare occasion that someone has an enterprise class network (think Cisco switches and the like), and plays 24/192 content or DSD128 or upsampled HQPlayer material, the microRendu can drop tons of packets. This leads to dropouts because the mR's 1 Gbps Ethernet interface can't keep up with the incoming data."

 

The same interface that can't keep a ping time at <1ms consistently, but whatever.  Like you say it should make absolutely no difference to the sound quality. Nothing's wrong with it. It sounds just fine.

 

Jesus also informed me this is not a fix, it is how the new OS behaves.

 

I`m happy it has less latency than before.  Who knows, maybe this new version resolves the issue Chris pointed out.  Although that's not an issue either because it sounds just fine and none of this should make a difference in the sound quality or functionality of the unit.

Link to comment
8 minutes ago, Johnseye said:

 

Yes, this is what Jesus shared with me.  It is better.  I will share a quote from Chris's review of another device in which he compares the mR. "On the rare occasion that someone has an enterprise class network (think Cisco switches and the like), and plays 24/192 content or DSD128 or upsampled HQPlayer material, the microRendu can drop tons of packets. This leads to dropouts because the mR's 1 Gbps Ethernet interface can't keep up with the incoming data."

 

The same interface that can't keep a ping time at <1ms consistently, but whatever.  Like you say it should make absolutely no difference to the sound quality. Nothing's wrong with it. It sounds just fine.

 

Jesus also informed me this is not a fix, it is how the new OS behaves.

 

I`m happy it has less latency than before.  Who knows, maybe this new version resolves the issue Chris pointed out.  Although that's not an issue either because it sounds just fine and none of this should make a difference in the sound quality or functionality of the unit.

 

Correct - latency will have no effect on sound quality.

 

Dropped packets, however, could certainly be noticeable if they got numerous enough.

John Walker - IT Executive

Headphone - SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable Ethernet > mRendu Roon endpoint > Topping D90 > Topping A90d > Dan Clark Expanse / HiFiMan H6SE v2 / HiFiman Arya Stealth

Home Theater / Music -SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable HDMI > Denon X3700h > Anthem Amp for front channels > Revel F208-based 5.2.4 Atmos speaker system

Link to comment

My experience on 2.3 is that latency drops to a very low level below 1 ms when you play music.

 

From 192.168.x.x: bytes=60 seq=0001 TTL=64 ID=cc74 time=0.578ms
From 192.168.x.x: bytes=60 seq=0002 TTL=64 ID=cd1e time=0.669ms
From 192.168.x.x: bytes=60 seq=0003 TTL=64 ID=cec8 time=0.720ms
From 192.168.x.x: bytes=60 seq=0004 TTL=64 ID=cfa4 time=0.737ms
From 192.168.x.x: bytes=60 seq=0005 TTL=64 ID=d128 time=0.436ms
From 192.168.x.x: bytes=60 seq=0006 TTL=64 ID=d280 time=0.425ms
From 192.168.x.x: bytes=60 seq=0007 TTL=64 ID=d37c time=0.634ms
From 192.168.x.x: bytes=60 seq=0008 TTL=64 ID=d4ec time=0.550ms
From 192.168.x.x: bytes=60 seq=0009 TTL=64 ID=d6a1 time=0.647ms

 

When not playing it is not so good:

 

From 192.168.x.x: bytes=60 seq=0001 TTL=64 ID=329c time=29.987ms
From 192.168.x.x: bytes=60 seq=0002 TTL=64 ID=3413 time=1.187ms
From 192.168.x.x: bytes=60 seq=0003 TTL=64 ID=358e time=4.582ms
From 192.168.x.x: bytes=60 seq=0004 TTL=64 ID=36ea time=9.752ms
From 192.168.x.x: bytes=60 seq=0005 TTL=64 ID=387b time=14.886ms
From 192.168.x.x: bytes=60 seq=0006 TTL=64 ID=38d1 time=20.124ms
From 192.168.x.x: bytes=60 seq=0007 TTL=64 ID=3a2f time=25.098ms
From 192.168.x.x: bytes=60 seq=0008 TTL=64 ID=3a34 time=30.334ms
From 192.168.x.x: bytes=60 seq=0009 TTL=64 ID=3bf3 time=35.440ms
 

have you tried this?

Link to comment
Guest
This topic is now closed to further replies.



×
×
  • Create New...