-
Notifications
You must be signed in to change notification settings - Fork 834
Fine grained FEC Parameters
(supported since 20180806.0)
(this is an advanced topic, its suggested to read other articles in the wiki first)
There is an advanced form of -f parameter , named Fine-grained FEC Parameter , for example: -f1:3,2:4,8:6,20:10, we will talk about it in this article.
The normal form of -f parameter is -fx:y and it means send y redundant packets for every x packets. For example -f20:10.
There is also a --timeout parameter to tell UDPspeeder the max latency introduced. If timeouts, FEC will be done immediately even if enough packets have been collected.
You may ask "I told UDPspeeder to send 10 redundant packets for every 20 packets, but what happens if I only got 8 packets before timeout? "
By default: In --mode 1 UDPspeeder will just send 10 redundant packets for those 8 packets(8:10). In --mode 0 UDPspeeder may try to merge and cut those 8 packets into 20, then send 10 redundant packets(20:10); but that doesnt always work since there are overhead introduced by IP+UDP headers, if the 8 packets are very short, you may still run into a situation of 8:10.
Maybe 8:10 sounds overkilled, you can tune the behavior with fine-grained fec parameters, such as:
-f1:3,2:4,3:5,4:5,5:5,6:6,7:6,8:6,9:7,10:7,11:7,12:8,13:8,14:8,15:9,16:9,17:9,18:10,19:10,20:10
But thats ridiculously long, actually, you can just use -f1:3,2:4,8:6,20:10 instead, and let UDPspeeder choose the intermediate vaule (by a linear way). In this example, -f1:3,2:4,8:6,20:10 is equivalent to the longer version above.
-f1:3,2:4,8:6,20:10 means send 10 redundant packets for 20 original packets if enough packets have been collected, send 6 redundant packets for 8 original packets if only 8 packets have been collected, send 4 for 2 if only 2, send 3 for 1 if only 1, and let UDPspeeder infer the other intermediate vaules.
A: Its a game of possibility, whether FEC can be successfuly recovered, depends on if you can receive x packets from the x+y packets. Usually if the packet-loss is not super huge, 20:10 is much stable/better than 8:4, to get similiar effect for smaller x you need to increase the y in x:y a bit, thats why we use 8:6 in the example.
-f1:4,2:5,10:14,20:20,100:82 is a parameter which is able to reduce 40% packet-loss to about 1%, which costs about 2 times bandwith usually. If the traffic is very heavy, the bandwitdth cost can be 1.8 times at best. If the traffic is very light, for example, there is only 1k bytes per second, the bandwitdth cost will be about 5 times (the worst case), but 5 times is only 5k bytes per second, so its still acceptable.