Best strategies for dealing with packet loss

[wa6hzt]

I'd appreciate everyone's thoughts on this. I have seen two schools of thought on how best to deal with packet loss; one says to increase the packet size while keeping buffer/delay values lower while the exact opposite is also touted as being more robust.

To put it in RRC terms, at one extreme you might have buffer and delay values of 16 and 15 with a packet size of 5 ms, with the other extreme being buffer and delay values of 6 and 5 with a packet size of 40 ms.

I am plagued by very bad packet loss at times, especially in the evening, and some expert advice would be greatly appreciated. Bandwidth concerns aside, which of these two approaches... or is there another... that works best?

Thanks & 73

[sm2o]

In general longer packets are better as the  UDP overhead is significant with shorter packages. And of course longer delays give better results

73 de mike

[dj0qn]

You didn't mention the bandwidth or type of provider you are using. This makes a huge
difference in settings.

As a general rule, I always set everything to the minimum codec necessary. In most cases,
I have found 0 is perfectly acceptable for CW & SSB work, anything higher is just overhead.
You can see the effect of increasing the codec above 0 in appendix A of the RemoteRig manual.
Keep in mind that this bandwidth is in both directions! The same applies to serial connections,
such as for CAT. For example, if you can use 4800, then do so and not 57600. This just eats
up unnecessary bandwidth.

Some suggested settings for low bandwidth, mainly 3G that I give people:

These 2 are important:
- audio quality to 0
- turn continuous RTP on

Play around with these 3 until you are satisfied:
- increase rx jitter buffer to min 10
- increase rx jitter delay to min 12
- audio packet size 20 or 40

73,
Mitch DJ0QN / K7DX

[wa6hzt]

Thanks Mitch and Mike!

I have been running codec 0, and have experimented with 12, as well. Sometimes I find 12 gets raspy-sounding after a while, but have not noticed that with 0.  I agree, 0 is fine for everything I have tried it with, which has been FM and digital modes.

Bandwidth at the radio end is 768 K up and 10 MB down, and I have enabled QoS to the RRC to the highest priority.

Bandwidth at the control end is almost 4 MB up and 25 MB down. QoS enabled at that end, too. Both are cable internet services.

Even running 16/15 buffers and 20 ms packets, I still get hiccups at times. I know bandwidth isn't the issue, and suspect ISP problems at the radio end. The direct path is about 200 miles (322 km). I have verified bandwidth isn't too pinched in the evening via speed tests.

There are no external devices attached and I have been watching the actual bandwidth during operation as I have changed parameters. Nothing over about 150 K in a worst-case scenario, typically 90 to 100 K with the current 16/15 buffers with 20 ms packets.

Thanks again!

73

[dj0qn]

Look at Appendix A in the RemoteRig manual. There you will see the effect on bandwidth of using various codecs.

Codec 0 uses 80k bps in each direction. Codec 2 doubles that requirement to 160k bps. 12 is new, and I haven't
tried it you yet, but looks even better for 3G type of work. Of course, using dual receive doubles the bandwidth
yet again for every codec, but this mainly effects Yaesu and Elecraft Twin users,

Looks like you are on the right track, good luck!

73,
Mitch DJ0QN / K7DX

[va3mw]

I've been working on this issue at 2 sites, and you might be seeing a very real internet problem called Buffer Bloat.

Short story, is there are only a few firewalls that I  know of that can deal with it.  One is the Astaro and I have reduced it in my DD-WRT buffers by reducing the Q sizes. 

ifconfig wlan0 txqueuelen 16
ifconfig eth0 txqueuelen 50

You have to experiment and change the values on every interface on your DD-WRT router.

This really won't be fixed until they actually fix it in the Linux kernels they use to run a lot of the home routers we use today.  The RFC is at http://queue.acm.org/detail.cfm?id=2209336.

Essentially, if you router is busy, your TCP packets (other traffic) don't get correctly throttled resulting in your real time UDP packets being buffered way to long.

Buffer bloat is well discussed on the internet and regardless of your bandwidth or latency values, you  may still have issues.