BufferBloat?RepeatSegs?

[xtaci]

BufferBloat 问题， RepeatSegs/InSegs 过高，可以在此讨论。 BufferBloat相关资料:

• https://en.wikipedia.org/wiki/Bufferbloat
• http://blog.csdn.net/dog250/article/details/52879457
• http://blog.csdn.net/dog250/article/details/52830576
• http://blog.csdn.net/dog250/article/details/54171687
• http://blog.csdn.net/dog250/article/details/54424751
• http://anagranroberts.blogspot.jp/2011/07/bufferbloat-impact-on-response-time.html

[bettermanbao]

响应一下号召，炒鸡慢的罗马尼亚VPS，直连1Mbps左右。

服务器端kcptun开了3个端口，sndwnd都是1024。 内网用4核ARM v7的OrangePi Zero同时连接3个端口，然后做负载均衡。 客户端连到OrangePi，speedtest测速如下。

实际流量消耗大概是2：1，RepeatSegs/InSegs大概在20%。其实我想说的是看着这个速度，已经懒得调整任何参数了，简直碉堡了！感谢作者！

[xtaci]

优化了那么久，才发现有效载比不高的真正原因是RTT的抖动，导致误判数据包超时。 在国际链路下，RTT jitter特别明显。

[bettermanbao]

那请问BBR算法方面有什么值得借鉴的吗？

[xtaci]

没有太多值得借鉴的，实现pacing需要高精度时钟，而这在用户态，而且带GC的语言中，是很难实现的。

[wang20150419]

@bettermanbao 能说一下用树莓派做负载平衡的大致方法吗？我现在是 树莓派加速，openwrt路由器通过树莓派翻墙。

[bettermanbao]

@wang20150419 用的是最简单的iptables的方法，OrangePi上开3个kcptun，连接服务器上的3个端口，本地监听10085-10087，然后用下面命令把本地10000端口的流量随机分布到10085-10087。内网其他客户端连接OrangePi的10000端口。

iptables -t nat -A PREROUTING -p tcp --dport 10000 -j REDIRECT --to-ports 10085-10087 --random

[wang20150419]

@bettermanbao 谢谢！

[JuncoJet]

没，最近网络稳了，我最后第三个版本用着都不断= =、 同时小推广一下 https://github.com/JuncoJet/skeepalive 加入负载均衡，当一台服务器不稳是切其他服务器（pac）

[xtaci]

@bettermanbao 降低repeatSegs的另一个办法是，增大-interval，比如到40， 非常有效，让其对网络抖动容忍度更高。

[bettermanbao]

这么做，丢包重发的间隔就会变大，有比较过对速度影响有多大？

-------- 原始信息 -------- 由： xtaci notifications@github.com 日期: 17/1/16 18:04 (GMT+08:00) 收件人： xtaci/kcptun kcptun@noreply.github.com 抄送： bettermanbao jackybao_sh@msn.com, Mention mention@noreply.github.com 主题： Re: [xtaci/kcptun] BufferBloat?RepeatSegs? (#378)

@bettermanbaohttps://github.com/bettermanbao 降低repeatSegs的另一个办法是，增大-interval，比如到40， 非常有效，让其对网络抖动容忍度更高。

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/xtaci/kcptun/issues/378#issuecomment-272819718, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQhou1YRGy-_HtL82u_X8GCe_nxz7Lqxks5rS0CZgaJpZM4LkNoE.

[xtaci]

对于视频流，基本没有影响，反而更快。

影响的只是小包，交互式应用。 @bettermanbao

[notedit]

计划用你的libkcp 写一个voip的demo 测试一下

[xtaci]

@notedit 好，记得反馈体验。

[bash99]

Repeat 3648 In 45262 算高吗？ 加州vps，ping 大概175ms，丢包率不算高（iperf3 10M，网络好时5%以内） fast + 12:1 的 data:parity, 窗口256 下载908KB/s左右。

就是还是会碰到上行通，下行全断的情况，触发原因不详，有时连续下载1G也没触发。平均1～2小时一次，时间2～10分钟。

[xtaci]

@bash99 8%的repeat率，在高抖动的国际网路下，算好的了。

[LiR1cky]

@bash99 你这8%的丢包只是一段时间的统计值，实际网络情况下并非恒定保持这一状态的，会忽高忽低。 12:1宽容度不够，只能应付不到8%的丢包。建议略微提高到8:1或5:1看看还会不会有断流产生。

[bash99]

@LiR1cky 断流时似乎下行全断（iperf3 带宽2M测试，服务端有链接信息，但是就卡死了）

@xtaci 另外一个德州vps，ping 230～280之间波动，总体丢包率比上面5%的更好，manual ( 1 80 2 1）+ 19:3 的 data:parity, 窗口256

似乎碰到了最好情况，RepeatSegs:165 -- InSegs:42290，负载率接近74%; 下载速度841KB/s。 而且 FECRecovered:15 FECErrs:0 FECSegs:5768 FECShortShards:143；这时丢包率太低，可能FEC已经没啥意义了。

再来一次下载后，RepeatSegs:1363 -- InSegs:83155，仍然很好

[xtaci]

@bash99 没错，最近才意识到, ping的抖动才是国际带宽慢的关键，低抖动的重传率会低很多。

[bash99]

@xtaci 尝试降低 FEC 时到 19:1，（其它仍然是 1 80 2 1），似乎碰到了一个大波动，带宽在下载后期下降到200K 服务器端的 RetransSegs:13859 EarlyRetransSegs:12545 OutSegs:35374 LostSegs:993 ，但是客户端仍然是 RepeatSegs:728 FECRecovered:2 InSegs:21351 这个算是 EarlyRetransSegs 弥补了丢包呢？还是 EarlyRetransSegs 降低了带宽？ 因为我是拿本机一个全随机无法压缩的文件做的测试，按说从服务端到再上游没有带宽瓶颈。

再来一次后似乎好了一点，中间两次降速到300K然后回升，整体repeat在3%，但是丢包率达到了6%。感觉这种瞬间丢包率急升的分布，靠提升FEC搞定的话，平时就很难保持高速率了。

还是三者不可兼得。

[bettermanbao]

我用kcptun在路由器上开了个国内中转，然后共享到v2ex上了。 收集几天数据然后跟你们讨论，有人帮忙测一下速吗？ 中转地址：https://www.v2ex.com/t/335068

[xtaci]

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

@bettermanbao 抽空再测下这个版本，也是对RepeatSegs的优化尝试。

[bash99]

@bettermanbao 实测已经被堵爆了，打开google.com/ncr 重定向要 5秒，下载50KB/s。

[bettermanbao]

@xtaci 待会儿试试看 @bash99 现在是爆了。。。

[bash99]

@bettermanbao 现在又来了一次，下载35秒，384KB/s。（上游是加州vps上某个不可压缩的文件）。

[bash99]

@LiR1cky 试了试断流时切到3:3，重启服务端和客户端，仍然连不上。还是被完全断了udp下行啊。

[linhua55]

@bash99 https://github.com/xtaci/kcptun/issues/228#issuecomment-272715363 可以使用TCP，欢迎测试

[baggiogogo]

20170117 KCP SNMP:&{BytesSent:293777 BytesReceived:84380867 MaxConn:3 ActiveOpens:4 PassiveOpens:0 CurrEstab:3 InErrs:0 InCsumErrors:119 KCPInErrors:0 InSegs:166625 OutSegs:5177 InBytes:188406703 OutBytes:1161086 RetransSegs:26 FastRetransSegs:0 EarlyRetransSegs:0 LostSegs:26 RepeatSegs:6556 FECRecovered:1062 FECErrs:0 FECSegs:38447 FECShortShards:360} 正常看了两段视频，10/3FEC，interval 30，约4%。

[xtaci]

@baggiogogo 终于走对路了。。。。 RTT才是问题的关键啊。。。

[baggiogogo]

换了一台线路稍差一点的vps，10/3FEC，interval 40，约5%。

[xtaci]

不错，我观察到的结果是ping值的稳定性和repeatsegs正相关

[baggiogogo]

@bettermanbao 测了差不多就关掉吧，流量是小，万一有人拿去扫爆别人的服务器，收到投诉还是麻烦的。 上回我的ovh莫名其妙直接被删除，问了说我的ip扫爆别人的服务器，申诉了好久，后来查出来是什么ip冒用，给恢复了，但数据全没了。

[bash99]

@xtaci 进一步测试了一下，发现我这两台vps都有一个甜区，服务器发包超过这个比例丢包率会从1%上升到5%，这时如果是FEC设高了触发，怎么调整都很难有效。 ping 220～270的德州vps，支持的窗口更大一点，256，最后形成的带宽是840KB左右。 ping 150～170的加州vps，窗口需要设到192，这时各类丢包重传repeat都低到<2%，带宽利用率能到85%，但是总带宽在730KB。

都是最后把FEC设为0了，因为这个窗口下丢包率极低；同时如果设高FEC，造成发包数上升，反而丢包率更高了。

[xtaci]

@bash99 感谢各位的测试，如果在低于10%的ping丢包率下，FEC确实可以完全关闭，这样最省流量。 如果需要应对 > 10%的丢包率，建议还是开默认的10，3的FEC

[bash99]

@xtaci 忘了说了，德州的interval 是 80，加州的是50，至少在之前的测试下，这个数比缺省值能有效降低 Repeat。

[notedit]

@xtaci quic 这个协议 在一开始有FEC, 在经过很多测试之后 增加FEC并没有带来多大的提升

quic 现在的协议已经把FEC干掉

[xtaci]

@notedit QUIC的FEC是非常简陋的，完全不实用的XOR方式，最多只能应付一个丢包。干掉也好。

[bettermanbao]

@baggiogogo 服务器已关 @xtaci 看来新版效果很好，我就不测了哈。另外能否开个tg群，把热心群众拉在一起，也方便讨论。

[xtaci]

先在这个贴讨论吧，主要是要控制讨论的质量，不要水了。

[xtaci]

我自己测的结果是，基本能控制在10%以内的repeatSegs。至少证明方向是对的。另外在vps的面板上观察到的出入比，更靠近。

[baggiogogo]

我的两台，一直都在5%以内，时间从更新一直覆盖到目前，不错。我记得前个版本有一台会到7%。

[baggiogogo]

正常情况下的CPU负载及内存占用，树2，512/128窗口，10/3FEC，服务器TC到30M。

[satifanie]

@baggiogogo 你们都是默认参数吗？为啥我就不能那么彪悍呢，还会断流， 难道人品问题？已升级最新版本，随机端口了。

[CuminLo]

@satifanie 端口怎么随机? 我的也没有那么彪悍...

[bettermanbao]

@xtaci 测试了17号的版本，反馈一个现象。

Repeat/In的比例在FECShort很低的时候，比如接近0，和之前的版本相比降低明显，从14%降到4%。但调低ParityShard后，随着FECShort的增加，Repeat/In的比例又会回到8%左右。

应为FECShort的增加就是接收端实际没收到的包变多，发送端必定会重发这些包。但重发包的RTT在算法上是否有bug？会导致重发包重复发送？

[xtaci]

rtt计算没有问题，已经滤掉bufferbloat导致的抖动， 只是FEC现在的作用更明显了。 注意，告诉发送方的ACK包也会丢包，这会导致重传，FEC对此也有帮助。

[baggiogogo]

@satifanie 基本是默认参数了，到不是偷懒，是因为这套参数在我的线路ping最低，情况接近理想时整好占用30M带宽，除去连同FEC在内的所有开销，大约20M的有效带宽，而我的上传有20M，搭跳板也整好物尽其用。 先用电脑客户端试试，排除路由性能之类问题，电信线路的话不妨把FEC适当调高点看看能否缓解断流，排查下会否isp有所限制。

[bettermanbao]

@xtaci 我有测试了一下，目前强烈感觉Repeat/In的比例和FECShort的正相关性非常强烈。 具体数值你见截图，最后的百分比就是Repeat/In。

[bettermanbao]

顺便再问一下，InSegs里面是否包含RepeatSegs?

[xtaci]

InSegs是全部，必然包含Repeat

[bettermanbao]

@xtaci 另外，我有观察到FEC调低以后，上图绿色的InSegs明显低于黄色的。但是2组数据采集时除了ParityShard从3改到了1，其他参数完全相同。最主要的是Sndwnd都是一样的，是什么造成这种差异的呢？大胆猜测ParityShard是否不占用Sndwnd？？？