手动参数设定探讨

[xtaci]

策略1： 通过超时重传＋快速重传，响应速度优先（最大化响应时间）：
-mode manual -nodelay 1 -resend 2 -nc 1 -interval 20

策略2： 仅仅通过超时重传, 带宽效率优先（有效载比优先)。
-mode manual -nodelay 1 -resend 0 -nc 1 -interval 40 或
-mode manual -nodelay 0 -resend 0 -nc 1 -interval 20

策略3： 尽可能通过FEC纠删，最大化传输速度（推荐）：
-mode fast -datashard 5 -parityshard 5

[dolphinpaopao]

能否手动设定开或者关，增加一个统计一定时间内的丢包率来自动调整策略的功能。统计的时间长短，触发调整策略的丢包率，详细策略均可手动设置。这个有实现的可能行么？

[testcaoy7]

@dolphinpaopao 这就是Congestion Control，实现是可能的，但是会很复杂

[dolphinpaopao]

@testcaoy7 实现很复杂那就不要了，可能会影响稳定性，想要的是简洁稳定高效。目前这些手动参数设置挺好的。满足不同需求。

[kmahyyg]

stability is what we need most,the second is speed.
i prefer Strategy 2.
also, can you add more information about the arguments we can modify manually to this repo's wiki?

[xtaci]

策略1对于网页访问这种突发性请求，查询较为友好。
策略3对于视频流这种较为友好。

策略2较为中庸。

[koolwiki]

刚测试了一下，用策略2： -nodelay 1 -resend 0 -nc 1 -interval 40 的参数比fast2将近节约1/4的流量
策略2的另外一种 -nodelay 0 -resend 0 -nc 1 -interval 20会更省流量吗？

[xtaci]

说的很对，一切都是平衡

_响应速度, 传输带宽，高载荷比_ 三者是跷跷板。

比如响应速度，一个数据包发出后，判断对方是否接收到了，是等待一个RTT时间没有收到ACK就重发，还是说要再等等看。 真实的情况始终未知，-nodelay 1就是不多等了，结果ACK晚到了一点点，就多发包了; -nodelay 0就是已经等了RTT后，再等等看，那么如果再等了还等不到，这个时间就浪费了，响应时间就慢了，整体速度也拖慢了。 乐观主义还是悲观主义？

根据香农定理:

（1）信道容量由带宽及信噪比决定，增大带宽、提高信噪比可以增大信道容量；
（2）在要求的信道容量一定的情况下，提高信噪比可以降低带宽的需求，增加带宽可以降低信噪比的需求；
（3）香农公式给出了信道容量的极限，也就是说，实际无线制式中单信道容量不可能超过该极限，只能尽量接近该极限。在卷积编码条件下，实际信道容量离香农极限还差3dB；在Turbo编码的条件下，接近了香农极限。

(1) 可以理解为，高丢包率＝＝高噪音
(2) 可以理解为，固定丢包率下增大发送带宽 == 更高的传输成功率(比如通过FEC)；固定传输带宽下降低丢包率== 更高的传输成功率(比如通过DSCP)

策略3也可以理解为，我假定我的纠错包能全部把丢失的包还原出来，每5个包，2个纠错包， 小于 2/7的**_均匀丢包率**_下( <28%)，必定能还原出来，完全不需要重传。

策略1可以理解为, 我非常悲观的判断包一旦超过RTT，大概率丢失了，通过一切手段尽快重新发送。

[xtaci]

一组我的自用参数:

client
-mode manual -nodelay 0 -resend 0 -nc 1 -interval 40 -nocomp -dscp 46 -mtu 1400 -crypt aes-128 -datashard 70 -parityshard 30

server
-mode manual -nodelay 0 -resend 0 -nc 1 -interval 40 -dscp 46 -nocomp -mtu 1400 -crypt aes-128 -datashard 70 -parityshard 30

[dolphinpaopao]

@xtaci 你好，请问一下使用环境是怎样的，服务端是在vps上么？服务器的延迟丢包和本地带宽如何？

[xtaci]

200Mbps 联通, 日本vultr, ping 136ms, UDP丢包30%左右

[dolphinpaopao]

@xtaci ，另外再请教一下这样的环境下服务器的实际流量超出有效流量多少呢？kcptun的传输带宽能达到多少？

[RoyLi-Pvt]

200Mbps 联通 作者帝都啊 我天津联通100M 通过iperf测试vultr LA丢包率非常之低 只有0.043%
不知道晚上会不会恶化
另外目前用Fast3模式 看视频会断流 加载网页也是 用一段时间后会突然完全没流量 过一段时间就会恢复

[xtaci]

@Tmily 那个是假的，流量上去了就开始丢包了。

[RoyLi-Pvt]

@xtaci 那就是需要长时间测试？ 我是设置成100M带宽测试60秒 要是设置成200M丢包就变成39%了 但是我家本身是100M的 最多能跑到120M

[xtaci]

从未断流

[RoyLi-Pvt]

@xtaci 嗯 断流的问题我今晚回去再调调参数 我先试试120M 发600秒看看丢包率

[RoyLi-Pvt]

@xtaci 刚刚试了试发600秒 丢包率还是很低 这回试试发9000秒 下班回家正好看结果
另外就是iperf 的测试结果有个警告信息：WARNING: did not receive ack of last datagram after 10 tries.

[xtaci]

killall -SIGUSR1 client_xxxxxx server_xxxxx 才能看到SNMP

[RoyLi-Pvt]

额 我测试用的是ipref 没看KCP的信息~ 因为只是测丢包率嘛 这两个会有很大差别么

[testcaoy7]

@xtaci 我也遇到过断流，主要发生在放映YouTube视频的时候，断流时网页浏览一切正常，就是视频流传不过来

[RoyLi-Pvt]

@testcaoy7 我断流时是全部断了 去看console的话应该是有sessionxxxxxxxxx之类的报错

[kmahyyg]

@xtaci 从我开始使用kcptun到现在，无论哪个版本，我都遇到了和 @Tmily 一样的问题，试过fast/fast2模式，加载网页还是看ytb都会断流，不过目前适当调大wnd值以后好了一点点，但是经常yamux报i/o deadline reached.

[testcaoy7]

@Tmily @kmahyyg 试着增加前向纠错的比例，我加大后断流很少发生了，因此，我也推荐3号策略

[RoyLi-Pvt]

@testcaoy7 嗯 回家试试新参数 这回按照作者大大的调的都是联通

[xtaci]

多看下我上面对**_香农定理**_的介绍，会加深认识。

[koolwiki]

@testcaoy7 请问3号策略流量消耗大概几倍啊？

[xtaci]

解释一下另一个问题:
-datashard 70 -parityshard 30 和 -datashard 7 -parityshard 3 有没有区别

回答:

1. 如果完全随机丢包（在时域上均匀分布） ，这两者没有差别，完全等价。
2. 如果在时域上不均匀，丢包一会儿有一会儿没有，这两者就有差别。 70/30的配置更又可能把数据纠错出来， 7/3的配置很容易全丢无法恢复。

选择在70+30的这个大区间整体丢包30%， 还是在 7+3的这个小区间整体丢包30%？ 只有试试。

[baggiogogo]

@xtaci 在不用kcptun的情况，无论测速还是下载，线路本身可以跑满下载带宽。差别是看油管时不使用kcptun没有使用kcptun畅快。
请教下这种情况下参数设置思路，感谢。

[xtaci]

你可以把这个问题想成全国的高速公路收费站， 某些收费站很宽大，基本不堵塞，另外一些就堵几公里长。 你下载跑满带宽，只不过是根本就没有碰到收费站而已，还在市内。 @baggiogogo

[xtaci]

#218 这个mtu的issue很有意思

[xtaci]

5:3 FECRecovered:539 FECErrs:0 FECSegs:13960

5:4 FECRecovered:1896 FECErrs:0 FECSegs:50221

5:5 FECRecovered:15697 FECErrs:0 FECSegs:17089

dataShard/parityShard的不同比值在丢包率为34.6% 下的还原率关系，可以看出，在parity越过了丢包率这个值后，数据还原率爆发性增长。

[peakvision]

3/(5+3)已经超过链路丢包率，向前纠错量已经大于丢包损失率，理论上降低重传，此后爆发的fes_recovered对传输有实质改善吗？

[xtaci]

需要观察SNMP确保FECRecovered是否真的接近FECSegs， 如果是，一定会有质的飞跃。

你看到的ping丢包率，不一定是实际丢包率，观察SNMP是最准确的。

[peakvision]

@xtaci killall -SIGUSR1哪些比值计算丢包呢，单客户端情况下用客户端InSeg/服务器的OutSeg去计算服务器到客户端的丢包率吗？我的客户端运行在win上。

@wxyzh 请问你iperf3参数是什么，我用-c -u -t 10 -R，无论-b从10M到50M，测试结果都好像不正常。

[xtaci]

统计意义上，可以用(1- 接收端的InSeg ／ 发送端的OutSeg) 约等于生命周期的丢包率。
LostSeg是发送端自己认为自己超时丢包的，不准确。
FECRecovered / FECSegs 一定要接近1

[peakvision]

呃，我的客户端是在windows上，看来打印不出来。

[geerda123]

@peakvision 请问iperf参数是多少，我也想知道

[peakvision]

@geerda123
server:
iperf3 -s -f M -V

client:
iperf3 -c server_ip -f M -V -R -u -t 10 -b 40M -l 800 -w 8192

我测试的时候client是windows版的。vps带宽是100mbit，基本上我认为调整上面的-l即可，但我的bin执行的时候经常报错，而且结果感觉不准。

[geerda123]

不用锁端口吗，-p等。-V 绑定一个IPv6地址。好像没必要。有大神告诉你吗，我怕测试结果不是通过kcptun 2016-12-04 21:15 GMT+08:00 peakvision <notifications@github.com>:

…

@geerda123 <https://github.com/geerda123> server: iperf3 -s -f M -V client: iperf3 -c -f M -V -R -u -t 10 -b 40M -l 800 -w 8192 我测试的时候client是windows版的。vps带宽是100mbit，基本上我认为调整上面的-l即可， 但我的bin执行的时候经常报错，而且结果感觉不准。 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#137 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARpMHEXrt3AS3n-xgMO0Y_DRS3-_9nHyks5rErzrgaJpZM4JnVaw> .

[linhua55]

@peakvision

server:
iperf3 -s -f M -V

client:
iperf3 -c server_ip -f M -V -R -u -t 10 -b 40M -l 800 -w 8192

应该去掉client端命令中的-u，不是UDP模式，应该是TCP模式

[peakvision]

@linhua55 测试是为了考察kcptun的理论速度，所以跟随kcptun测udp。

[linhua55]

@peakvision
谢谢。 唉，一测，40M UDP丢包率竟然高达92%， 5M 30%， 10M 65%

[peakvision]

@linhua55 你的客户端运行在什么平台上？
我测出来也是udp丢得奇高，感觉与kcptun实际效果出入很大。

[linhua55]

@peakvision
可以看一下这个issue esnet/iperf#386
运行在 Windows下的 Archlinux虚拟机上，用vagrant软件来管理这个虚拟机，非常方便。参数上，干脆舍弃FEC了。
有个主意： 创建一个 可方便比较的文件 放在服务器上，用UDP传输这个文件，同时记录时间点，然后在客户端比较原始文件和接受到的这个文件的差异 来分析丢包率。和丢包的特征（如丢包的分布曲线） 多测几次，然后提取出共同的特征来 建模 生成这些参数

现在是用：iftop工具，具体命令是sudo iftop -B来查看占用带宽大小 是否符合 iperf3 测得的。 和 Shadowsocks客户端中，显示日志中的速度曲线来调参数的。 在显示的带宽稳定的情况下，曲线中的低谷 表示 有丢包，或包不能被FEC还原。 高谷表示 没有丢包或包成功被FEC还原。

小的FEC参数，如7/3，高谷会处于较低速度，因为就算连着几个包被还原，总体短时流量(7+7+...)也较小。而大的FEC参数 70/30，高谷会在较高的速度上，因为一旦有一个包 被还原，这个短时流量(70)是较大的。

[linhua55]

@peakvision
这个测得到丢包率是相对于服务器的带宽的，而服务器的带宽往往远大于自己的带宽，因此测得不准。

只有在服务器带宽和自己的带宽相等的情况下(或使用工具如tc，来限制服务器的带宽)，这里显示的丢包率才是准确的。

[peakvision]

@linhua55 因为加了iperf3加了-b去指定使用带宽，所以测不准的问题我也怀疑是iperf3的bug。

[chilejiang1024]

哪个参数是会影响小图片的接收的? 网页上的小图片都收不到....
就是各种用户头像 都是空的...

-crypt salsa20 -nocomp -datashard 90 -parityshard 10 -mtu 1400 -sndwnd 128 -rcvwnd 512 -dscp 46 -autoexpire 300 -keepalive 10 -mode fast

测试丢包率为 10%左右