PACKET LOSSES

[PY2CPPY2CP]

Hi,

I know that losses depend on Internet Link Qaulity.

Is there a way to diminish Packet Losses ?

73´s

De Enrique
PY2CP

[HB9VQQ]

Typically, applications that rely on real-time packet processing, such as video and audio-based programs like RM Noise, suffer the most from packet loss.
In a client-server architecture, these factors influence packet loss:

- Network congestion
- Old and outdated or faulty network infrastructure
- Misconfiguration
- Wifi issues
- Software errors

As a rule of thumb, the closer you are to the server in the network, the lower the packet loss.
If you are suffering from packet loss, try to find the source of the packet loss. There are various tools available.

Based on your callsign, I suspect that you are from Brazil. Setting up an RM Noise Server in South America could help to reduce packet loss and latency.

Roland

[PY2CPPY2CP]

Hi Roland,

Thnaks for the complete explanation.

We are still searching someone who can provide a RM dedicated server in our Region.

Gruesse

de Enrique
PY2CP

[PY2CPPY2CP]

Hi Roland,

Does more audio buffer in MS compensates partially this packet losses ?

De Enrique
PY2CP

[RandyW]

I would guess network congestion *somewhere*, as your loss varies substantially over time.


Sometimes your PROBE loss looks reasonable:

Code: Select all

2024-01-31 19:46:04.326 LOG: client: VZB ( py2cp ) 2024-01-31 16:46:03.902322 server: rmnoise3.rmnoise.com latency avg/max: 0.231/2.683 -14.5 lost/sent: 8/5142 (0.156%) out: 0 -0.0 util: 10.0 score: 84.104
2024-01-31 19:46:04.325 LOG: client: VZB ( py2cp ) 2024-01-31 16:46:03.902322 server: rmnoise2.rmnoise.com latency avg/max: 0.162/0.390 -1.0 lost/sent: 12/5148 (0.233%) out: 0 -14.0 util: 8.8 score: 83.720
2024-01-31 19:46:04.137 LOG: client: VZB ( py2cp ) 2024-01-31 16:46:03.902322 server: rmnoise1.rmnoise.com latency avg/max: 0.162/0.471 -1.0 lost/sent: 11/5145 (0.214%) out: 0 -10.5 util: 22.2 score: 86.000

(8, 11, 12 PROBE packets lost over ~90 minutes.)


Other times the PROBE loss is high TO ALL 3 SERVERS (suggesting the problem is close to you):

Code: Select all

2024-02-01 23:17:25.501 LOG: client: Y3Y ( py2cp ) 2024-02-01 20:17:24.904304 server: rmnoise3.rmnoise.com latency avg/max: 0.303/1.313 -88.4 lost/sent: 237/5136 (4.614%) out: 0 -0.0 util: 1.2 score: 11.511
2024-02-01 23:17:25.501 LOG: client: Y3Y ( py2cp ) 2024-02-01 20:17:24.904304 server: rmnoise2.rmnoise.com latency avg/max: 0.186/0.856 -1.0 lost/sent: 264/5138 (5.138%) out: 0 -99.2 util: 12.4 score: 1.965
2024-02-01 23:17:25.221 LOG: client: Y3Y ( py2cp ) 2024-02-01 20:17:24.904304 server: rmnoise1.rmnoise.com latency avg/max: 0.194/0.889 -1.3 lost/sent: 246/5138 (4.788%) out: 0 -33.1 util: 20.2 score: 63.931

(Shows 237, 246 PROBE packets lost over ~90 minutes. )


Interestingly, the AUDIO PACKET loss is quite a bit worse than the above PROBE loss at the same time:

Code: Select all

client: Y3Y ( py2cp ) lost packet count count: 32 average: 4.656 max: 20.000 total: 149.000
client: Y3Y ( py2cp ) lost packet count count: 17 average: 3.059 max: 8.000 total: 52.000
client: Y3Y ( py2cp ) lost packet count count: 21 average: 3.048 max: 8.000 total: 64.000
client: Y3Y ( py2cp ) lost packet count count: 32 average: 3.062 max: 8.000 total: 98.000
client: Y3Y ( py2cp ) lost packet count count: 38 average: 1.921 max: 4.000 total: 73.000
client: Y3Y ( py2cp ) lost packet count count: 37 average: 1.784 max: 3.000 total: 66.000

(The first line shows 149 AUDIO PACKETS lost within 90 seconds. During that 90 seconds 20 consecutive AUDIO PACKETS were lost.)


The only difference between PROBE packets and AUDIO PACKETS is that PROBE packets are small as they don't include a payload. This suggests network congestion may be the culprit.


I tried to test to your IP, but it doesn't respond to pings:

Code: Select all

$ ping xxx.xx.161.191
PING xxx.xx.161.191 (xxx.xx.161.191) 56(84) bytes of data.
--- xxx.xx.161.191 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2055ms

For what it is worth, I tested fine to a neighboring IP at this time:

Code: Select all

$ ping xxx.xx.161.180 -c 100 -s 850
PING xxx.xx.161.180 (xxx.xx.161.180) 850(878) bytes of data.
--- xxx.xx.161.180 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99131ms
rtt min/avg/max/mdev = 173.003/176.593/195.873/4.245 ms

[PY2CPPY2CP]

Hi Randy,

Curiously the audioi breaks have been mitigated reducing audio buffer to 50 ms. As far as I know audio buffering is realted to delay but not to packet losses.Please commnent.

73´s

De Enrique
PY2CP

[RandyW]

Curiously the audioi breaks have been mitigated reducing audio buffer to 50 ms. As far as I know audio buffering is realted to delay but not to packet losses.Please commnent.

Audio buffering is not related to packet loss.

Your average latency is around 185ms. Take a look at the picture below. Because of your frequent high spikes in max network latency, I would expect lowering the buffer to cause more audio breaks indicated by the "audio buffer exceeded count".

Packet loss is still your biggest cause of audio breaks. To find the location of the loss, try the following:
a) ensure there is packet loss at the time of testing

b) get an outbound traceroute to any server from a command prompt:

Code: Select all

tracert -d rmnoise1.rmnoise.com

(If you post this traceroute, I can perform some testing from the server.)

c) ping the first hop 100 times with a 840 byte payload:

Code: Select all

ping <ip-number-of-hop> -n 100 -l 840

d) repeat for each hop until you discover the hop that has a similar loss %

Here is a graph of your latest session:

[PY2CPPY2CP]

Hi Randy,

I´m getting in touch with my local inteenet provider tomorrow and ask them to reset over there.

By the way I proceed to find someone to build a server for South America. Maybe William Schauff, PY2GN will take it. I will be with him on beg March and let´s see how it will work.

Rgds

Enrique
PY2CP