演示配置，关于配置，请在此thread讨论 about kcptun HOT 11 OPEN

请问最新版这个pprof参数是只加在server端吗？加不加的效果有多大差别？

from kcptun.

这个配置支持tcp，跟udp同时代理不，还有这个没有套用udp2raw,能否把udp2raw也写入到/etc/systemd/system/kcp-ss.service 里面

from kcptun.

SERVER-SIDE {"parityshard": 0}
请问这是关闭服务端发送数据FEC的意思嘛？SIGUSR1的SNMP信息也显示客户端没有接收FEC包了，FECParityShards:0，
请问为什么这样设置？通常来说服务端发送数据到客户端比反过来更容易丢包吧？

from kcptun.

SERVER-SIDE {"parityshard": 0} 请问这是关闭服务端发送数据FEC的意思嘛？SIGUSR1的SNMP信息也显示客户端没有接收FEC包了，FECParityShards:0， 请问为什么这样设置？通常来说服务端发送数据到客户端比反过来更容易丢包吧？

不一定，比如**的网络上下行就是不对称的。

from kcptun.

FEC的疑问：
-mode fast -datashard 5 -parityshard 5 在15%左右丢包率的线路上FECRecovered/FECParityShards只有1%，即使在35%丢包率的线路上也没啥变化，客户端rcvwnd减半或者ds:ps改成10:3、70:30都会让FECRecovered更少，直接掉到0.03%。
请问这种情况是还没凑齐10个包就触发重传造成的么？测试用的是视频流。
RetransSegs/OutSegs两条线路都是比丢包率高2%~5%，丢包率越高快速重传的占比越大，这种重传就解决问题的情形是不是就没必要开FEC了？
client 2024/02/28 11:50:03 KCP SNMP:&{BytesSent:3123502 BytesReceived:4948978821 MaxConn:1 ActiveOpens:1 PassiveOpens:0 CurrEstab:1 InErrs:0 InCsumErrors:0 KCPInErrors:0 InPkts:10399228 OutPkts:241337 InSegs:5260796 OutSegs:4350024 InBytes:12168673893 OutBytes:253130843 RetransSegs:364 FastRetransSegs:0 EarlyRetransSegs:0 LostSegs:364 RepeatSegs:355544 FECRecovered:66582 FECErrs:5 FECParityShards:5225927 FECShortShards:2329}
server 2024/02/28 11:50:04 KCP SNMP:&{BytesSent:4948978893 BytesReceived:3123502 MaxConn:2 ActiveOpens:0 PassiveOpens:2 CurrEstab:1 InErrs:0 InCsumErrors:0 KCPInErrors:4 InPkts:241341 OutPkts:12499432 InSegs:4396665 OutSegs:6274260 InBytes:248304386 OutBytes:14823889445 RetransSegs:1431828 FastRetransSegs:783924 EarlyRetransSegs:14146 LostSegs:633758 RepeatSegs:366 FECRecovered:1344 FECErrs:1 FECParityShards:118325 FECShortShards:0}

from kcptun.

FEC的疑问： -mode fast -datashard 5 -parityshard 5 在15%左右丢包率的线路上FECRecovered/FECParityShards只有1%，即使在35%丢包率的线路上也没啥变化，客户端rcvwnd减半或者ds:ps改成10:3、70:30都会让FECRecovered更少，直接掉到0.03%。 请问这种情况是还没凑齐10个包就触发重传造成的么？测试用的是视频流。 RetransSegs/OutSegs两条线路都是比丢包率高2%~5%，丢包率越高快速重传的占比越大，这种重传就解决问题的情形是不是就没必要开FEC了？

如果用户到服务器的延迟很低，我认为是没有必要开FEC的，重传一次的惩罚并不高，所以实际的优化策略可能还会包含一些RTT测量，再制定策略。

from kcptun.

FEC的疑问： -mode fast -datashard 5 -parityshard 5 在15%左右丢包率的线路上FECRecovered/FECParityShards只有1%，即使在35%丢包率的线路上也没啥变化，客户端rcvwnd减半或者ds:ps改成10:3、70:30都会让FECRecovered更少，直接掉到0.03%。 请问这种情况是还没凑齐10个包就触发重传造成的么？测试用的是视频流。 RetransSegs/OutSegs两条线路都是比丢包率高2%~5%，丢包率越高快速重传的占比越大，这种重传就解决问题的情形是不是就没必要开FEC了？

如果用户到服务器的延迟很低，我认为是没有必要开FEC的，重传一次的惩罚并不高，所以实际的优化策略可能还会包含一些RTT测量，再制定策略。

测试的两条线路延迟分别是200ms和100ms，应该算不上很低吧？想弄明白为何开了如此高(5:5)的FEC，FECRecovered/FECParityShards却只有1%，难道就只是单纯因为这个延迟够低了？

from kcptun.

对，这个延迟很低了，而且线路质量很好。

from kcptun.

这只是一个工具，不是万能的，具体的策略还需要根据测量来动态调整。

from kcptun.

这只是一个工具，不是万能的，具体的策略还需要根据测量来动态调整。

现在正在调整的路上，十分感谢您的解答。

from kcptun.

请问在延迟150ms左右，几乎不丢包的线路上， "datashard" 和 "parityshard" 是否直接设为0比价合适？

from kcptun.