希望增加SNMP信息实时写入指定文件的功能，以方便调试参数。

[bettermanbao]

或者增加控制台关闭log，然后实时显示的SNMP参数功能。

谢谢！

[bettermanbao]

再请教一个问题，snmp里能否再增加一个FEC恢复失败的计数？用于统计因为丢包率过大造成fec无法恢复发生的计数。这样微调fec参数的时候就会有明确目标，控制无法恢复的次数尽量为0，同时FECRecovered/FECSegs的比例尽量接近1。谢谢！

[xtaci]

fecsegs - fecrecovered 就是恢复失败的。

[bettermanbao]

不是这样的吧，如果没有丢包发生，那fecsegs发了几个就是几个，fecrecovered应该是0吧。因为没有需要恢复的包。这是恢复失败就不是FEC sets-fecrecovered了吧？

[xtaci]

我明白你的意思，主要是判定问题， 现在判定FEC恢复失败，可能的办法是：

1. fec.go的第215行，判定后+1
2. fec.go的第103行，判定后+1

即超时 + 超对队列大小，判定为失败，这两个都是滞后指标。

[bettermanbao]

代码我不是很看得懂，逻辑上FEC现在只保留最近3组数据。那收到第4组的时候，如果第一组如果还没有恢复出来，就能判定第1组丢了多少个segs。这是否就是你说的超队列？

[xtaci]

对

[bettermanbao]

谢谢，请考虑一下增加FECFailed的计数吧。

[xtaci]

FECExpired更合适

[bettermanbao]

名字不重要，只要数字是fec没有恢复出来的seg就可以了。

[xtaci]

我试了下，基本就等于FECSegs - FECRecovered，因为如果不丢包10,3的配置下，先收到10个包，后面三个包，必定会慢慢被第二组，第三组的3个FEC包挤出队列。

[xtaci]

现在的问题是， 收到3个FEC包的时候，并没有记录当前的fec组，是没有丢失的。无法判定是真的恢复不了， 还是不需要恢复。

[bettermanbao]

再想想吧，你总能想到办法的。

[bettermanbao]

@xtaci 请问 FECExpired 还会添加吗？ 不知道kcp-go代码中是否有地方可以判断FEC的数据块不够，在那里加上FEC缺失seg的计数，或者在FEC缓存的第1组数据包被第4组数据包清出缓存的时候，统计一下1组数据包中一共多少个包没有被恢复出来。 代码不是很懂，仅仅提供一下思路。谢谢！

[xtaci]

10，3的配置， 只丢了一个包， 只需要9 + 1即可恢复， 后面的2个包，算恢复成功还是不成功， 这类问题很多，这个问题可以通过增加一个表去跟踪记录所有的还原情况， 但会有性能损失。

[bettermanbao]

如下图，FECLostSegs用来统计FEC运算以后，每组数据包实际的丢包。这样优化FEC参数时，目标就能明确为FECLostSegs=0，shardparity调到比FECRecoveredSegs稍大。

[xtaci]

嗯，明确的统计FEC纠错模块认定的丢失个数，这个没问题。

[bettermanbao]

那就期待你的更新了，感谢！

[xtaci]

@bettermanbao 更新了，试试

[bettermanbao]

@xtaci 等我试试

[bettermanbao]

数据有点看不懂了，下载下载着，突然FECLost暴增。。。

[xtaci]

嗯，又有个地方想错了

[bettermanbao]

再来一组数据，这次是间隔60秒采样，之前是间隔1秒。FEC(30,10)

[xtaci]

这个统计的实际上是，由于丢失太多，没有办法参与 FEC的DataShard个数

[xtaci]

名字应该叫做, FECUnRecoverable

[bettermanbao]

有点搞，能不能还是统计一个FECLost呢？

[xtaci]

目前没有办法，自己在外面做减法吧

[bettermanbao]

snmp文件先传上来，数据我等一下再研究。

kcptun_snmp_log.xlsx

[bettermanbao]

从数据中可以看出FECSegs很大，FECRecovered很小，还有很多FECLostSegs。感觉FEC参数很需要调整，目前是30,10。。。

[bettermanbao]

能具体解释一下吗？ 比如fec 10 3，前面10个包收到6个，后面3个包收到2个，FECShortShard是多少？

[xtaci]

FEC是每收到一个包，就尝试还原 1。 收到data(1)， datashard +parityshard < 10，无法还原 2- 6. 收到data(2..6)， datashard +parityshard < 10，无法还原 7。 收到parity(10,11), datashard +parityshard = 6+2 < 10，无法还原 。。。 。。。 一直收后面的数据包，直到缓冲区超过 13 * 3个包， 接下来， 每收到一个新包， 第一个data包移除，FECShortShard++

[bettermanbao]

所以fecshortshard可以近似理解为datashard-lostdatashard?

[xtaci]

不能，还要减去还原成功的

[bettermanbao]

麻烦看下，我上传的snmp log文件，感觉还是有点不理解。

[xtaci]

哪里不理解

[bettermanbao]

fecshortshard你代码里的注释是record unrecoverable data，但是按照你的解释是收到的datashard在被清出缓存时计数。到底怎么理解呢？这个数字大好还是小好？

[bettermanbao]

我刚才看了下代码，有点理解了。fec恢复成功会直接释放缓存，留在缓存中的datashard如果被强制释放，那一定就是丢包过多留下的不可恢复的data

[bettermanbao]

另外，再请教一下，接收端cpu满载，是否会造成额外丢包，影响fec效率？

[xtaci]

cpu满载主要影响是内核中的udp socket buffer，相当于一个消息队列，这个队列如果因为应用层处理不及时而填满，一定会丢包。 所以CPU满载，一定会丢包。

[bettermanbao]

理解了，谢谢。现在方便帮忙编译一下mipsle版的client吗？我想再试试，家里的pad没法编译，我自己下午变异的binary留在公司里了。谢谢！

[xtaci]

kcptun-darwin-386-20170109.tar.gz kcptun-darwin-amd64-20170109.tar.gz kcptun-freebsd-386-20170109.tar.gz kcptun-freebsd-amd64-20170109.tar.gz kcptun-linux-386-20170109.tar.gz kcptun-linux-amd64-20170109.tar.gz kcptun-linux-arm-20170109.tar.gz kcptun-linux-mips-20170109.tar.gz kcptun-linux-mipsle-20170109.tar.gz kcptun-windows-386-20170109.tar.gz kcptun-windows-amd64-20170109.tar.gz

[bettermanbao]

调了各种fec的比例，发觉如果fecshortshard要接近0，datashard和parityshard的比例要在5:3左右。但此时fecsegs比fecrecovered大很多，也就是fec的效率很低。一套fec的参数肯定不能满足不同丢包率，所以到底是选fec还是选重传，非常难权衡啊。

[bettermanbao]

早晨又测试了一下，确实CPU占用率100%后会出现内核丢包。而且内核丢包很有规律，FEC(5,5)的情况下几乎全部可以被恢复出来。表现在数据上就是FECRecovered一下变很大，下载速度并没有变慢。看来FEC对付内核丢包这种很有规律的丢包非常有效。 但是对于实际网络中的非常没有规律的丢包就显得不那么有效了，只能说用带宽换稳定。我这边网络上午丢包率很低，下午丢包率就会变得非常不稳定。等下午再测试一下吧。

再次感谢作者，有了这些实时的snmp数据，调参数就不用盲调了。

[xtaci]

嗯，不错， 你是观察到 /proc/net/snmp的内核丢包么？

[bettermanbao]

不是，没有/proc/net/snmp这个文件。我是人为让CPU占用率到达100%，这时FECRecovered就会变得非常大，CPU占用率下降后，FECRecovered马上下降。

[xtaci]

嗯，观察/proc/net/snmp是最准确的。

[bettermanbao]

openwrt上没有这个文件呢。。。 顺便问一下，Inseg的计数是datashard还是datashard+parityshard?

[xtaci]

Inseg = datashard+parityshard