0
I have a wireless link with packet loss of up to 10%. It has to carry one rtp stream, nothing else. Datarate of the stream is <100kb/s so the lowest datarate offered (1 mbit/s) by wlan (802.11b) is more than enough. To counter the packet loss I would like to try to take advantage of the arq algorithm offered by tcp. The setup looks like this: So one machine, which is the source of the rtp stream, will run a tcp-server (first end point of the tcp session) and a soft ap (hostapd running on linux). The second machine which is identical to the first one will be the end point of the tcp session an a wlan client (running wpa_supplicant) on linux. So the tcp sessiono won't span any routers or switches, just a single wireless link. Winth no routers/switches in between congestion control won't have much to do, but it won't hurt either hopefully. With both machines being identical and sufficiently powerfull flow control should not be an issue either. Especially as the rtp stream has a rather low data rate (< 100kb/s).
So my questions are: What paramaters/variables (/proc/sys/net/ipv4/tcp*) should i tweak in which way to achieve lowest possible latency(like ack every packet and send data imiadetly even in small packets and not wait for enough data to gather...) I don't care if throuput suffers. What else am I missing?
K. Nick
Posted 2017-11-16T18:53:41.647
Reputation: 1
1Arq would add overhead. RTP uses UDP because streaming media can usually afford to lose data with minimal impact. arq would be used to make sure that the endpoint received every byte of data accurately even at the cost of throughput and increased overhead. Why would you want to insure a real-time media stream was byte for byte accurate? What is the real problem you have here, rather than asking how to implement a solution you’ve come up with? – Appleoddity – 2017-11-16T19:02:20.430
1Is your equipment really only capable of 802.11b? There are some 802.11-layer tweaks that could help if you were on 802.11n or better: Set your IP DiffServ bits so your Wi-Fi drivers put these packets on WMM’s Voice (VO) queue. – Spiff – 2017-11-16T19:22:32.183
The equipment is standard 802.11g consumer grade stuff. Nothing special. My point is that its lowest speed is more than sufficient for the purpose. So speed/data rate is not the issue. Packet loss is. And that occurs with fancier 802.11n stuff probably even more. Wmm isn't the solution either. Afaik it is about prioritization of real time (strong time constraints) traffic. But there is nothing to prioritize against so we are top priority already. – K. Nick – 2017-11-16T19:39:12.020
I know the argument about audio being able to afford some packet loss. With the g711 codec probably up to 1% loss is ok. I have up to 10%, fluctuating which results in choppy sound and missing syllables frequently enough to be uncomfortable tiring to listen to. – K. Nick – 2017-11-16T19:51:47.810
As the rtt on the wireless link is about 2-3ms I hope to get away with adding just that small amount of delay and hopefully not much jitter while reducing packet loss below an acceptable limit. Therefore I'd like to tune the equipment to minimize that delay even if it would hurt overall throughout (which I don't need anyway) I know that this goes against the book but I'd like to try anyway before declaring the project s failure. – K. Nick – 2017-11-16T19:58:39.360
I understand you wanting to try. I don’t have a problem with that at all. But I can’t help you with it. It just seems like a strange solution when it seems the obvious thing is to fix the connectivity issue. And no, wireless N and especially 5 GHz should not have as much packet loss, unless you are simply too far away. 2.4ghz is just completely saturated and can be unusable in many areas any more with all the misconfigured wireless routers out there. Post back though with how you set this up if you figure it out, it’s interesting enough for sure. – Appleoddity – 2017-11-17T06:08:44.547