Kcptun: 参数组合分享贴

[xtaci]

{
"localaddr": "127.0.0.1:1080",
"remoteaddr": "SERVERIP:4000",
"key": "x",
"crypt": "aes-128",
"mode": "manual",
"conn": 1,
"autoexpire": 300,
"mtu": 1400,
"sndwnd": 128,
"rcvwnd": 1024,
"datashard": 30,
"parityshard": 15,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10,
"log": "/var/log/kcptun.log"
}

{
"listen": ":4000",
"target": "127.0.0.1:1080",
"key": "x",
"crypt": "aes-128",
"mode": "manual",
"mtu": 1400,
"sndwnd": 1024,
"rcvwnd": 1024,
"datashard": 30,
"parityshard": 15,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}

特点: 30/15的fec比例，33%以下的丢包率可以基本还原

[dearneo]

感谢 @xtaci 大大分享
在这里也分享一下自己用的参数

先说一下基本情况：
坐标广州，电信100M， 新加坡小主机，直连速度弱鸡，只有几十KB/s。（这里吐个槽，主机ip一度被墙，电信网络连ping都ping不同，开ticket找客服，客服大方的加了个ip，测试依然被墙(lll￢ω￢)，看来是整个ip段都被墙了。。手机移动4G反而能通，且速度不错，能到2MB/s，所以也就一直给手机翻墙用，上play市场更新个软件什么的。几个月前发现电信居然又能通了，只是速度弱鸡(lll￢ω￢)，呵呵~）

由于小主机流量有限，本人的目标是在速度可接受的情况下尽量提高数据的载荷比。
通过监测主机网卡发送流量、接收到的KCP流量以及原始有效数据，改变多个参数组合，得出：
1.主机的UDP丢包率（接收到的KCP流量/主机网卡发送流量）约为40%。
2.开启FEC对提高数据载荷比无帮助，由于丢包率很高，开启后载荷比（原始有效数据/主机网卡流量）下降明显，fast模式下甚至不到10%，但响应速度和传输速度确实大幅提升，壕可随意。但感觉这么疯狂发包主机容易被封啊。。

以下是本人经过多次测试后得出的参数，得出以下参数，此参数下速度一般，但载荷比可达50%左右，考虑到原始UDP丢包率为40%，这个数据已经很好了，且看1080p视频基本无卡顿，下载速度在400KB/s~1500KB/s之间跳动。

主机：
--conn 1 --crypt aes-128 --mode manual --nodelay 0 --resend 0 --nc 1 --interval 40 --datashard 0 --parityshard 0 --sndwnd 2048 --rcvwnd 2048 --mtu 1400 --dscp 0 --autoexpire 0 --sockbuf 4194304 --acknodelay false --keepalive 10

客户端：
--conn 1 --crypt aes-128 --mode manual --nodelay 0 --resend 0 --nc 1 --interval 40 --datashard 0 --parityshard 0 --sndwnd 8 --rcvwnd 2048 --mtu 512 --dscp 0 --autoexpire 0 --sockbuf 4194304 --acknodelay false --keepalive 10

-------------------------update-------------------------
刚刚看了下其他issue，发现发送最大速率对丢包率也有影响！！
果然把客户端的sndwnd ，rcvwnd ，mtu 调小后，丢包率大幅下降！！

以下是最新的客户端参数：
--conn 1 --crypt aes-128 --mode manual --nodelay 0 --resend 0 --nc 1 --interval 40 --datashard 0 --parityshard 0 --sndwnd 8 --rcvwnd 512 --mtu 256 --dscp 0 --autoexpire 0 --sockbuf 4194304 --acknodelay false --keepalive 10

[baggiogogo]

10M联通光纤，实际端口是15M。
因为线路本身较稳定，尽量以一个较温柔的参数，利用KCP的特性达到YOUTUBE立竿见影的效果（同一视屏上图没有使用KCPTUN，下图使用，差不多五倍的差别），同时达到减少流量消耗并且减少对他人影响的目的。

[bettermanbao]

我也分享一下，电信200M宽带，VPS是9刀3年的sentris，client是mt7620的路由器同时部署ss和kcptun。VPS流量一大就会被suspend，路由器流量一大kcptun进程就会被kill。ping延时200ms，sndwnd rcvwnd 都设成128，直接用fast mode，youtube全时段1080p流畅播放，目前稳定运行。

[LiR1cky]

"mode": "manual",
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,

这应该就是mode fast吧？

[xtaci]

是的

[sxml]

小白弱弱问下 "nocomp": true, 这是压缩还是没压缩? 压不压缩对什么有影响

[xtaci]

nocomp = no compression

[caicy1991]

@xtaci 你好，想问下设置nocomp后是关闭压缩，看到提示是可能会降低延迟，这个是指延迟减小嘛（响应速度提升）？还是延迟效果下降？

[xtaci]

这个问题很简单嘛， 压缩会计算，计算会消耗时间，必然延迟就高了啊。

[caicy1991]

@xtaci 谢谢讲解，那是不是可以理解为，开启压缩，消耗时间但降低流量消耗，关闭压缩，不能降低流量消耗，但不耗时间。

[xtaci]

是的

[choicky]

我之前用fast2与fast3，发现两者在网速、流量耗用方面差异很小。

最近几天使用 @xtaci 的参数，发现网速能快一倍，但如使用 xtaci 的参数，会不定时出现断流，即使降低 mtu 以及 收发窗口也会断流。不知道原因在哪。

所以今晚又改为
-crypt salsa20
-mode fast2
-autoexpire 60
-keepalive 10
-nocomp
了。

因为kcptun同时在家里路由器以及其他地方的电脑用，所以加上 nocomp 参数，否则路由器cpu耗用率很高且网速非常慢，估计路由器性能不好，无法支撑解压工作了。

btw，路由器上，究竟是 xor 好还是 salsa20 好呢？

fast2 fast3不会断流，就是网速比 xtaci 的参数少一半。

[baggiogogo]

跟踪补充：
今天统计了下11月的流量消耗，在上面那组参数情况下，到今天为止，流量消耗大约是正常情况下的1.3倍，到月底估计也就是1.5倍，应该说是很不错了。
（紫色代表VPS上传流量，蓝色下载流量）

[Y1ph]

来分享一发，基于@xtaci 大大的参数。
客户端是ipv6校园网，服务端是digitalocean每月5刀的版本，地点sfo2（但是ip查询是纽约，？？？）
好像会减少丢包的情况，流量情况没有统计。
服务端：
{
"listen": ":PORT",
"target": "127.0.0.1:PORT",
"key": "KEY",
"crypt": "salsa20",
"mode": "manual",
"mtu": 1350,
"sndwnd": 256,
"rcvwnd": 256,
"datashard": 70,
"parityshard": 40,
"dscp": 0,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 0,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}
客户端：
{
"localaddr": "127.0.0.1:PORT",
"remoteaddr": "SERVERIP:PORT",
"key": "KEY",
"crypt": "salsa20",
"mode": "manual",
"conn": 1,
"autoexpire": 0,
"mtu": 1350,
"sndwnd": 60,
"rcvwnd": 180,
"datashard": 70,
"parityshard": 40,
"dscp": 0,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 0,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}

[terrytw]

分享一下
服务端
{
"crypt": "aes-128",
"mode": "fast2",
"conn": 1,
"autoexpire": 60,
"mtu": 1400,
"sndwnd": 2048,
"rcvwnd": 2048,
"datashard": 0,
"parityshard": 0,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}
客户端
{
"crypt": "aes-128",
"mode": "fast2",
"conn": 1,
"autoexpire": 60,
"mtu": 1400,
"sndwnd": 128,
"rcvwnd": 1024,
"datashard": 0,
"parityshard": 0,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}
网络是上海电信50M+BANDWANGON19刀
datashard和parityshard试过30:15，10:3，15:3，24:3，基本上YOUTUBE都是2000-3000Kb，后来直接换了0:0反而可以到4000-5000
MTU和RCVWND调小之后速度也会明显下降，所以就维持在1400和1024了

感谢@bettermanbao 编译的OPENWRT-KCPTUN，看1080P的时候大概也就只占用50%内存

更新：
又折腾了一下，试了FAST,FAST2和MANUAL以重传为主的设置（fec (0,0), -nodelay 1 -resend 2 -nc 1 -interval 20），和各种FEC比的搭配
证实楼下CHOICKY的猜测，也就是：
在路由器上部署OPENWRT-KCPTUN，最关键的是关闭FEC，其他设置带来的改变相当有限

RCVWND可以下调到512，MTU在512和1400之间来回试了好多次，感觉1400快一些，但是结果都不稳定

[bettermanbao]

@terrytw 同是魔都电信表示rcvwnd 256就能跑到4Mbps了，你竟然用1024。另外路由器上建议用salsa20加密，cpu占用率可以继续降低。

[terrytw]

@bettermanbao 如同XTACI在另外一贴所说，因为各人网络环境的不同，这些设置其实很多时候是瞎猫碰死耗子...
不过同是上海电信的你这么一说我也开始怀疑，是不是我昨晚从10点鼓捣到了12点，网络本身负载下降了才导致速度提升，今晚回去再试试
当然FEC比改成0:0之后效果还是很明显的，这个肯定不是错觉

[choicky]

@terrybw @bettermanbao
据我的经验，路由器上开启压缩以及fec，网速反而变慢。

所以路由器建议加上 -nocomp true 以及
datashard": 0,
"parityshard": 0,

加密方法方面，据说salsa20比较省资源。

[LiR1cky]

魔都电信200M，Virmach Phoenix机房。客户端是跑在X86的nas上
测试下来fast+fec (30,15)效果最佳，可以达到16000-20000kbps
fec对魔都电信这种高UDP丢包率还是很有效果的，我用fec(0,0)只能4000-5000kbps

[terrytw]

@LiR1cky 请问一下你如果不用KCPTUN大概是多少速度？SS用的是哪个版本？SSR还是LIBEV？

[terrytw]

@choicky @LiR1cky @bettermanbao
从我们几个人的情况来看，设置这个东西的确是因人而异....

[choicky]

我是深圳电信光纤100m
之前强迫症地做了测试，日本新加坡美国的机房都测过，大体感觉如下：
客户端安装再电脑上时，fec（30, 15）最有最大网速，但网速有波动。总体上，还是默认的 fec (10, 3)比较均衡。

客户端在路由器上就是关闭fec与压缩才具有相对理想的效果。

[choicky]

@terrytw 参数是个人不一样，甚至同一套参数在同一个人在不同时间的效果也不一样。
但目前常用的路由器性能有限，关闭压缩是较优方案。我的路由器是关闭fec比较好。

[LiR1cky]

@terrytw 因为我是KVM所以不用kcptun的话也用锐速，锐速就难说了网络情况好的话甚至不比kcptun慢多少，但网络情况差的时候也就1000kbps。。。

现在我用ss-libev，之前用过一阵子SSR但感觉加了混淆反而慢且非常容易断流。

[terrytw]

@choicky 感谢你的分享
你的关于路由器部署KCPTUN的感受和我差不多

@LiR1cky 我自己的感受是，用了参数优化过的KCPTUN大概能加速3倍以上，默认参数大概是2倍
通过设置能提升的终归是有限的
你可以跑15-20m，可能是你的线路先天比较好，不加速也有5m左右
或者是CHOICKY所说，客户端部署在电脑上比路由器上效果好，对应的最优参数设置也不同

[LiR1cky]

@terrytw 部署在x86的nas上性能确实比直接在Merlin的路由器上效果好不少，而且稳定得多。

[LiR1cky]

@terrytw 如果不用kcptun和锐速，我肯定是跑不到5000k的，顶多1000-2000kbps了。

[xtaci]

路由器运行的最大问题是：golang目前并没有提供官方的编译器

mips32的编译器是非官方制作(https://github.com/gomini/go-mips32)，因此在性能，兼容性上有比较大的问题。 好消息是go1.8 (明年2月release)包含了官方的mips32的平台支持。 如果go1.8有rc版本，我会同时把mips32编译出来，相信速度和可靠性会高很多。

[terrytw]

@LiR1cky 那有可能是NAS和路由器的差异
不管如何今晚回去试试FAST+FEC30:15,之前一直都用FAST2

[LiR1cky]

@xtaci Merlin的路由器上用的应该是arm的版本，用salsa20+nocomp的话还行，但加速性能达不到x86的nas上的效果。另外稳定性还不是很好，可能还没有很好的定期重启机制。NAS上我是自定义每天凌晨重启kcptun client的，在此基础上可以很稳定地使用了。

[xtaci]

嗯，还是计算能力不够的问题, 压缩和FEC都比较费CPU

[bettermanbao]

试了下关闭fec，确实速度有所提高。
看了下路由器的cpu占用，应该是性能不足造成的。

[xtaci]

@bettermanbao 帮忙测试下https://github.com/xtaci/kcptun/releases/tag/v20161202 mipsle版本
我没有路由器可用。

[bettermanbao]

@xtaci 好的，这几天出差，下周回来就试试看。

[dearneo]

我又来了。。经过了多次测试，终于找到了一组非常适合自己的参数，感觉比我之前分享的参数好太多了，这里再和大家分享下。

server端：
-mtu 1300 -sndwnd 2048 -rcvwnd 512 -crypt aes-128 -datashard 0 -parityshard 0 -mode manual -nodelay 1 -resend 0 -nc 1 -interval 500 -nocomp

client端：
--crypt aes-128 --nocomp --mode manual --nodelay 1 --resend 0 --nc 1 --interval 500 --datashard 0 --parityshard 0 --sndwnd 512 --rcvwnd 2048 --mtu 1300 --dscp 0 --autoexpire 0 --sockbuf 4194304 --acknodelay false --keepalive 10

先说说效果，高峰时期youtube 720p基本无压力，网页打开速度能接受，无断流。且有效数据载荷率非常高，client端接收到的的数据与原始数据基本不超过是1.2 : 1，感觉那个20%基本就是KCP协议自身的开销了，除去20%左右的丢包率，有效载荷大于60%。

这组参数关于interval这参数测试过不少数值，自带的模式里面数值都设得很低，但发现设得小的时候client端接受到的冗余数据包高不少，接受数据和有效数据比值基本是1.5 : 1，感觉是服务端重发了不必重发的包。把interval调高以后，我这里选择参数差不多是1.5倍于自身线路时延，也就是是500，发现效果非常好，速度快且有效载荷高，不需要把MTU和rcvwnd 调太小，使用几天也没发现断流，非常满意。

[choicky]

@dearneo

你是哪里的破vps，竟然以720p为目标啊...

年付20美元左右的vps，直接用fast都应该能1080p流畅的。

你的参数方案有效载荷高，一方面是禁用了fec，另一方面是禁用了resend。

我刚才 issue 里面查了下， @xtaci 解释过 interval 的作用是控制 flush 的时间间隔，主要控制 cpu 的耗用。你vps可能严格控制了cps的耗用，所以扩大 interval 能够避免断流。

[dearneo]

@choicky
不太喜欢你这种口吻。
我只说高峰时段720p没问题，是往保守的方向说的，目前的参数看2K也没问题，如果你非要看4K，那你自己喜欢就好。

我当然是为了高有效载荷才关FEC和rescend的，不然呢？（手动白眼）
fast模式不是没有试过，我的情况是fast模式下即使是关闭FEC，只要窗口数稍大，有效数据载荷就会大幅降低，甚至低于30%。且实际速度也没有比目前的参数好到哪里，且疯狂发包对VPS不够友好，还有被服务商封的可能。窗口数减小似乎会好点，但速度又上不去。当然各个地区墙的高度是不同的，请不要一概而论。

我的VPS对CPU耗用有没有限制我不清楚，但应该是没有的。而且就算开fast模式+fec+压缩也没多高。interval是kcp协议内部工作的间隔，这个我知道啊，KCP的Readme.里面就有说明。这里我降低的flush的频率的确是提升了有效载荷，且速度也十分理想，那有样的参数不用难道我用fast模式？Are you kidding me？

[choicky]

@dearneo 你想多了。但我的语气确实会误导人。

Sorry。

[bettermanbao]

FEC我也关了，在我的网络下也没有用，反而白白浪费带宽。
调大interval对速度有帮助，挺有意思的实践，等待 @xtaci 大神说说什么原因。

[dearneo]

@bettermanbao
我是开启nodelay情况下调大了interval，感觉效果的确很好，高载荷且速度不错，缺点是速度曲线不是那么平滑

@choicky
没事。我只是分享一下我的发现，让其他人可以参考一下。

[baggiogogo]

曲线不平滑的话，不一定是参数有问题，有时vps与客户端之间的链路是完全没问题的，但母鸡上折腾的人特多会造成波动，或者正好同时大家一同挤占带宽也会造成波动，G口的vps情况多数要好于100M口，2048窗口挺大了，如果在我这差不多要150M带宽。

[linhua55]

@dearneo
感谢，改了interval确实有效

选择参数差不多是1.5倍于自身线路时延，也就是是500，发现效果非常好

你ping得到的往返时间是 666 = 2* 500/1.5？不会这么高吧！！

我的ping是160，设置的是 120 = 1.5* 160/2 (也是1.5倍)，感觉不错

[bettermanbao]

@dearneo 我试了调大inerval到200和500，在我这边传输速度没有fast2快。看来这个interval对不同网络影响不同。

[dearneo]

@baggiogogo
我这里rtt比较高，所以窗口就设得大了些

@linhua55
我的ping的时间大约是是350ms左右，我之前可能说错了。应该是1.5倍的rtt

@bettermanbao
速度应该没有fast2快正常吧，毕竟没有开快速重发，只开了nodelay。
重要的是interval设的大些可以增加有效数据的载荷，也就是减少了服务器重复发送无需发送的数据包，而速度也不会差太多。
当然这样可能会让线路延迟不稳定，比较适合我这种上上网看看youtube的，对实时要求比较高的可能就不适合了

[xtaci]

发送方对是否丢包的判断，就是根据RTT，做一定的浮动，基本上，就是蒙。

那么interval加大，就是判定逻辑再多等了一下下，就是蒙对了，数据包到了。

那么，如果是蒙错了呢。。。

速度一定会变慢的嘛。

FEC是什么？ FEC是对于RTO的一种补充，在蒙错了的时候，有个前向的纠错机制。

也就是说，可以降低速率的抖动。

[baggiogogo]

KCP SNMP:&{BytesSent:540509 BytesReceived:89154650 MaxConn:3 ActiveOpens:4 PassiveOpens:0 CurrEstab:3 InErrs:0 InCsumErrors:175 KCPInErrors:0 InSegs:202743 OutSegs:18242 InBytes:266884104 OutBytes:9504878 RetransSegs:130 FastRetransSegs:0 EarlyRetransSegs:29 LostSegs:101 RepeatSegs:88294 FECRecovered:79858 FECErrs:0 FECSegs:101335}

这两天抽风抽厉害，配了30/30的FEC，尚能饭，HOHO。

[LiR1cky]

@baggiogogo 确实，抽风厉害的时候FEC是大救星。。。

[bettermanbao]

其实我一直想提的这一个功能增强是动态调整FEC。算法可以是根据丢包率自动调整，kcptun启动后默认FEC 0:0，通过计算fastretransseg，earlyretransseg和lostseg，自动调大fec或者减小fec。调整目标可以自己设定，比如我希望fec以后的丢包率控制在10%，或者5%。不知道实际实现是否困难？@xtaci

[xtaci]

这个问题很难， 算法做不好，可能越调整，离目标越远。

[bettermanbao]

理解算法很难，所以我们一起讨论嘛。因为我觉得这个功能还是很有意义的。不同isp在不同时段的丢包率可能差别很大，使用固定的fec确实不是一个很好的方案。如果server端可以知道实际的丢包率，那理论上调大fec肯定是可以降低丢包率的。增加fec mode fixed和dynamic，datashard任然由用户指定，parityshard根据实际丢包率加权调整，比如每10分钟调整一次。dynamic模式下client端的fec自动跟随server端动态调整。

[xtaci]

这个问题是在, datashard, parityshard, interval, nc ....等这一大堆参数中（多维），求一个局部极值（假设有极值）。

基本方法是，梯度下降方法，线性规划方法。

这种方法要成立，那么这个多维平面局部存在极值的假设要成立，否则函数就不能收敛，即越调越烂。

[xtaci]

你想要找的，就是这个高维空间的局部极值点。

[baggiogogo]

可否“半自动”，即FEC参数以客户端为准，服务端自动侦测客户端参数，像窗口一样。

[bettermanbao]

或者说增加fec mode: normal fast fast2 fast3 manual，让后输入参数是datashard, parityshard, weight, feedback interval, seglost target，开放这些参数后，由用户使用预置参数或者自己调整。

[xtaci]

应该归入机器学习的范畴了，这个问题我是这么认为的。

持续采集数据，送入模型学习，最后不断的反馈调整。

要做好这个事，应该这么做。

否则你求不出来最大值的。

[linhua55]

测试，可以在 空闲时（没有流量，或流量较少时）进行测试，确定 “实时”（这一阶段）参数。

测试时，可以 先让用户输入 期望平均速度 期望响应时间，然后程序开始自动调整参数并进行测试 以达到或接近于 用户期望水平。 如果用户期望较低，可能很快会找到合适的参数，如果期望较高，则会比较费时间或者根本达不到。

[bettermanbao]

也许我的想法比较简单，lost_rate(n+1)=lost_rate(n)+delta_lost_rate * weight_fact，以上更新每隔一个interval，更新一次。datashard固定为用户输入值，parityshard(n+1)通过datashard和lostrate自动计算得出，由客户端通知服务器端。不知是否可行？

[xtaci]

一共8个参数可调， 你固定其中7个，当然可以用线性方式就一个部分极值（波峰）。
但本质上，你这个公式就是梯度下降的一维版本。

[baggiogogo]

明白了，好比八个点固定一个平面，这头压下那头翘，可以这么理解吧。
TX们，还有个问题无法言表，以前说过，动态调参很调皮容易被打屁股。

[bettermanbao]

所以我觉得不用上升到人机学习那么高的境界，kcptun只要提供一个简单的模型，参数什么的交给用户根据自己的环境自己去实践。不高兴实践的用户可以继续使用固定fec或者直接关fec。

[baggiogogo]

@LiR1cky 前两天宽带续费，一起升级了带宽，现在配置FEC没那么纠结了,以前基本都是直接换VPS。

[xtaci]

有简单的办法当然更好，需要自动调整参数的数量变少当然更好。

[linhua55]

咱们可不可以把 这几个参数 的 函数/方程 列出来。

1. datashard和中parityshard与丢包率曲线的概率分布有关

[baggiogogo]

KCP SNMP:&{BytesSent:1161686 BytesReceived:373772811 MaxConn:4 ActiveOpens:9 PassiveOpens:0 CurrEstab:2 InErrs:0 InCsumErrors:647 KCPInErrors:0 InSegs:771590 OutSegs:58720 InBytes:1035468082 OutBytes:7131109 RetransSegs:43 FastRetransSegs:0 EarlyRetransSegs:0 LostSegs:43 RepeatSegs:413541 FECRecovered:385466 FECErrs:0 FECSegs:385839}

借着抽风，晚上实验性质折腾了一番，尝试配了5：5比值的各种FEC数值，最终定格在2/2上。Recovered比例基本1：1，而相对大的数值比如30/30、45/45等，Recovered比例大概在0.9:1，另外强迫症最爱，我尝试看了一集青云志，7630这个数值我真没发现变动过，介个，新蜜蜂。

关于带宽利用，一开始就决定总体控制在了20M以内，最终大约18M保证了8M的有效带宽，大概就这个比例。既满足了愉快的1080需求（无论视屏打开速度、拖动进度条速度，我想都是令人满意的），也不至于太放肆，和谐为主。算是个比较均衡的数值，对于youtube来说。

俺的线路脾气俺清楚，说不定明天就没事人一样，但对于线路基础差是常态的同学来说，我想还是有借鉴意义的，即便FEC比例相同，但各种数值多尝试，也许真能求到一个极值？HOHO，祝好运。

[bettermanbao]

所以如果datashard设置为10，parityshard只要能够在0-10之间根据丢包率自动调节，应该就能简单的最大化fec的作用。

[Matrix6677]

@dearneo 你的参数很稳定速度也很快，希望有更好的参数分享，不过你分享的第二组参数在手机上的效果不怎么好

[ninggu2008]

尝试把fec设成0：0，cpu占用一下子就下来了。我这里丢包率不高，ping测试丢5%（电信），速度好像还略微提升。
尝试5:5，服务器端速度非常高，但是客户端并没任何提高。

[berryyan]

大家有没有路由器的推荐配置，使用人大概是3-5个设备 已看YouTube广告片为主的需求

[choicky]

华硕 ac68U

[ACG-MM]

{
"localaddr": "127.0.0.1:1080",
"remoteaddr": "SERVERIP:4000",
"key": "x",
"crypt": "aes-128",
"mode": "manual",
"conn": 1,
"autoexpire": 300,
"mtu": 1400,
"sndwnd": 128,
"rcvwnd": 1024,
"datashard": 30,
"parityshard": 15,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10,
"log": "/var/log/kcptun.log"
}
{
"listen": ":4000",
"target": "127.0.0.1:1080",
"key": "x",
"crypt": "aes-128",
"mode": "manual",
"mtu": 1400,
"sndwnd": 1024,
"rcvwnd": 1024,
"datashard": 30,
"parityshard": 15,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}
特点: 30/15的fec比例，33%以下的丢包率可以基本还原

哪个是服务端？。。

"mode": "manual",
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,
这应该就是mode fast吧？

fast3怎么设置？