Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

演示配置,关于配置,请在此thread讨论 #923

Open
xtaci opened this issue Jun 24, 2023 · 12 comments
Open

演示配置,关于配置,请在此thread讨论 #923

xtaci opened this issue Jun 24, 2023 · 12 comments
Labels

Comments

@xtaci
Copy link
Owner

xtaci commented Jun 24, 2023

CLIENT SIDE

$ cat /home/user/local-ss.json

{
        "smuxver": 2,
        "localaddr": ":2000", //  修改此处, 此处接受连入,比如ss-local通过此端口连入ss-server
        "remoteaddr": "IP.IP.IP.IP:33666-34690", // 修改此处,指向kcp服务器
        "key": "PASSWORDPASSWORDPASSWORDPASSWORD",  // 修改此处
        "crypt": "twofish",
        "mode": "fast3",
        "mtu": 1400,
        "sndwnd": 256,
        "rcvwnd": 2048,
        "datashard": 10,
        "parityshard": 3,
        "dscp": 0,
        "nocomp": true,
        "acknodelay": false,
        "nodelay": 1,
        "interval": 20,
        "resend": 2,
        "nc": 1,
        "sockbuf": 16777217,
        "smuxbuf": 16777217,
        "streambuf":4194304,
        "keepalive": 5,
        "autoexpire":600,
        "quiet":false,
        "tcp":false
}

$ cat /etc/systemd/system/kcp-ss.service

Description=kcp-ss

Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
Environment=GOGC=20
ExecStart=/home/user/client_linux_amd64 -c /home/user/local-ss.json // 修改此处指向正确的json文件位置
Restart=on-failure
RestartSec=10
KillMode=process
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

SERVER-SIDE

$ cat server_ss.json

{
        "smuxver": 2,
        "listen": ":33666-34690", 
        "target": "127.0.0.1:2000", // 修改此处,指向:例如ss-server
        "key": "PASSWORDPASSWORDPASSWORDPASSWORD", // 修改此处
        "crypt": "twofish",
        "mode": "fast3",
        "mtu": 1400,
        "sndwnd": 2048,
        "rcvwnd": 2048,
        "datashard": 10,
        "parityshard": 0,
        "dscp": 0,
        "nocomp": true,
        "acknodelay": false,
        "nodelay": 1,
        "interval": 20,
        "resend": 2,
        "nc": 1,
        "sockbuf": 16777217,
        "smuxbuf": 16777217,
        "streambuf":4194304,
        "keepalive": 10,
        "pprof":false,
        "quiet":false,
        "tcp":false
}

./server_linux_amd64 -c server_ss.json

@xtaci xtaci pinned this issue Jun 24, 2023
@xtaci xtaci added the FAQ label Jun 30, 2023
@szhangcn
Copy link

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

@maojianyou
Copy link

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

@monkeylab
Copy link

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

@xtaci
Copy link
Owner Author

xtaci commented Feb 27, 2024

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

不一定,比如中国的网络上下行就是不对称的。

@monkeylab
Copy link

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}

@xtaci
Copy link
Owner Author

xtaci commented Feb 28, 2024

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测量,再制定策略。

@monkeylab
Copy link

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%,难道就只是单纯因为这个延迟够低了?

@xtaci
Copy link
Owner Author

xtaci commented Feb 28, 2024

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

@xtaci
Copy link
Owner Author

xtaci commented Feb 28, 2024

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

@monkeylab
Copy link

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

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

@szhangcn
Copy link

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

@weili0677
Copy link

weili0677 commented Oct 15, 2024

server_windows_386.exe -t "127.0.0.1:4001" -l ":4001" -mode fast3 -smuxver 2
我用上面的命令,cpu占用很高怎么办?内存只占用4m,这是服务端,大概有100-200的连接

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants