请问为什么FECRecovered的值远小于FECParityShards？

[Olympus-E]

比如我Vultr测试服务器
KCP SNMP:&{BytesSent:737 BytesReceived:55718110 MaxConn:1 ActiveOpens:1 PassiveOpens:0 CurrEstab:1 InErrs:0 InCsumErrors:0 KCPInErrors:0 InPkts:98317 OutPkts:1397 InSegs:81132 OutSegs:27348 InBytes:95850088 OutBytes:1039954 RetransSegs:0 FastRetransSegs:0 EarlyRetransSegs:0 LostSegs:0 RepeatSegs:13132 FECRecovered:1079 FECErrs:0 FECParityShards:22539 FECShortShards:1690}

用的是-ds 10 -ps 3

参数：
本地：

{
"localaddr": "0.0.0.0:6666",
"remoteaddr": "xxxx:6666",
"key": "dick0neo",
"crypt": "aes-128",
"mode" : "fast3",
"scavengettl": 15,
"mtu": 1250,
"sndwnd": 256,
"rcvwnd": 10240,
"datashard": 10,
"parityshard": 3,
"tcp": true

远端

{
"listen": ":6666",
"target": "127.0.0.1:2000",
"key": "xxxxx",
"crypt": "aes-128",
"mode": "fast3",
"mtu": 1250,
"sndwnd": 1024,
"rcvwnd": 512,
"datashard": 10,
"parityshard": 3,
"nocomp": false,
"tcp": true
}

通过本地Insegs/服务端Outsegs在95以上 理论上来说这个FEC参数足以应对这个丢包率 但是FEC却没有恢复出多少

只有把FEC打到很大的冗余度 比如5:5，FECRecovered才会接近FECParityShards

按照#137 (comment) 中层主的数据 FECRecovered不应该这么少才是

[yzslab]

分两种情况吧。
第一种：低pps
这种情况，按你10:3的比例，要发够10个才能触发生成冗余包的机制，也许等凑够10个，早就已经触发重传机制的，因此就轮不到FEC。
第二种：高pps
发包快，如果造成拥塞，丢包率会增大，你原来的比例肯定就不适用了