请问为什么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

按照https://github.com/xtaci/kcptun/issues/137#issuecomment-255999344 中层主的数据 FECRecovered不应该这么少才是

[yzslab]

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