【转载】LKL UML native 的比較: 有用嗎? (數據更新....

[nanqinlang]

转载自原帖： https://www.91yunbbs.com/discussion/229/lkl-uml-native-%E7%9A%84%E6%AF%94%E8%BC%83-%E6%9C%89%E7%94%A8%E5%97%8E-%E6%95%B8%E6%93%9A%E6%9B%B4%E6%96%B0
感谢原作者 neko 大佬

allientNeko 话题数：161会员, 大佬 四月 2017 最后编辑于 四月 2017 在 灌水 #0

昨天打錯了指令 使得數據作廢了.... 這是新的數據

LKL UML native 的比較

醜婦終須見家翁 LKL UML 就是沒速度...

LKL UML 的出現 我本身也只是想要加快一下 TCP congestion control 的發展 因為現行的 kernel module 都有點煩 如果有 LKL UML 就可以加快一點了吧

在 UML 被人們從過去的歷史巨坑中掘起來之後 LKL 又被 @linhua 從 github 的實驗室拉出來

LKL 全名是 Linux Kernel Library UML 是 User-mode Linux

LKL 由 intel 付錢研究 意在把 kernel 當成 library 用 而 UML 就從十幾年前就一直存在

我聽到最多的就是 "在 userspace 開整個 kernel 連 bandwidth 都跑不滿也敢拿出來" "還不如自己寫個 TCP stack"

當然實際的口氣會更糟一點點 不過也表明了 LKL UML 有多不濟了 沒錯 就是連 bandwidth 也跑不滿....

="= 現實一點吧 自己寫一個 TCP stack 很難維護的.... 或者說的人可以半天寫出來 然後可以有時間在github上維護

我戰五渣 就放過我吧

那.... 要用LKL UML 嗎? (以下測試 如果覺得太悶的話 就去看結論吧)

測試開始 client: vultr Frankfurt 4vCPU 這台client 都安裝了 ubuntu 16.04 LTS, lubuntu-core 和 firefox 然後用這一台連去全世界的 SSR server server: vultr 的 1vCPU 1GB port speed: 10Gbps 這樣比較接近大眾的設定

為什麼要用這種笨設定測試? 還不是因為有人說: "看你LKL吹上天 實際開firefox用上來就是渣" 那我就開一台 desktop 來跑跑看

以下統一用 SSR 做測試 每組設定跑 10 次 取平均值的大約數字

LKL + python + TSO 使用的command

LD_PRELOAD="/root/liblkl-hijack.so" \
LKL_HIJACK_NET_QDISC="root|fq" \
LKL_HIJACK_SYSCTL="net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000" \
LKL_HIJACK_NET_IFTYPE="tap" \
LKL_HIJACK_NET_IFPARAMS="tap0" \
LKL_HIJACK_NET_IP="10.0.0.2" \
LKL_HIJACK_NET_NETMASK_LEN="24" \
LKL_HIJACK_NET_GATEWAY="10.0.0.1" \
LKL_HIJACK_OFFLOAD="0x9983" \
python server.py -p 443 -k do-not-hack-me -m aes-256-cfb -O auth_sha1_v4 -o http_simple

LKL + python 使用的command (和 LKL + python + TSO 一樣 不過少了 LKL_HIJACK_OFFLOAD="0x9983")

LKL + HAproxy + TSO

LD_PRELOAD="/root/liblkl-hijack.so" \
LKL_HIJACK_NET_QDISC="root|fq" \
LKL_HIJACK_SYSCTL="net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000" \
LKL_HIJACK_NET_IFTYPE="tap" \
LKL_HIJACK_NET_IFPARAMS="tap0" \
LKL_HIJACK_NET_IP="10.0.0.2" \
LKL_HIJACK_NET_NETMASK_LEN="24" \
LKL_HIJACK_NET_GATEWAY="10.0.0.1" \
LKL_HIJACK_OFFLOAD="0x9983" \
haproxy -f ./haproxy.cfg

LKL + HAproxy (和 LKL + HAproxy + TSO 一樣 不過少了 LKL_HIJACK_OFFLOAD="0x9983")

native SSR 就是直接跑SSR了

without proxy 什麼都不用 直接連上之前測試時用的 speedtest 節點

test environment 1: location: New York speedtest ping 100ms

LKL + python + TSO

download: 90Mbps
upload: 70Mbps
CPU usage: 30%

LKL + python

download: 70Mbps
upload: 85Mbps
CPU usage: 30%

LKL + HAproxy + TSO

download: 90Mbps
upload: 90Mbps
CPU usage(including python): 25%

LKL + HAproxy

download: 45Mbps
upload: 35Mbps
CPU usage(including python): 20%

native SSR

download: 600Mbps
upload: 30Mbps
CPU usage: 90%

without proxy

太快了 firefox 選擇死亡

test environment 2: location: Tokyo speedtest ping 270ms

LKL + python + TSO

download: 60Mbps
upload: 30Mbps
CPU usage: 30%

LKL + python

download: 40Mbps
upload: 15Mbps
CPU usage: 30%

LKL + HAproxy + TSO

download: 35Mbps
upload: 15Mbps
CPU usage(including python): 16%

LKL + HAproxy

download: 20Mbps
upload: 20Mbps
CPU usage(including python): 11%

native SSR

download: 320Mbps
upload: 25Mbps

without proxy

download: 35Mbps
upload: 5Mbps

(不... 是真的... without proxy 比 native proxy 慢 證明了線路還是很重要)

test environment 3: location: Amsterdam speedtest ping 25ms

LKL + python + TSO
download: 200Mbps
upload: 200Mbps
CPU usage: 80%

LKL + python

download: 150Mbps
upload: 150Mbps
CPU usage: 80%

LKL + HAproxy + TSO

download: 230Mbps
upload: 230Mbps
CPU usage(including python): 80%

LKL + HAproxy

download: 100Mbps
upload: 100Mbps
CPU usage(including python): 80%

native SSR

download: 420Mbps
upload: 300Mbps

without proxy

太快了 firefox 選擇死亡

test environment 4: location: Frankfurt speedtest ping 10ms

LKL + python + TSO

download: 250Mbps
upload: 250Mbps
CPU usage: 85%

LKL + python

download: 200Mbps
upload: 200Mbps
CPU usage: 85%

LKL + HAproxy + TSO

download: 350Mbps
upload: 350Mbps
CPU usage(including python): 85%

LKL + HAproxy

download: 150Mbps
upload: 150Mbps
CPU usage(including python): 85%

native SSR

download: 500Mbps
upload: 300Mbps

special LKL + python + TSO (protocol: origin, plain)

download: 400Mbps
upload: 300Mbps

without proxy

太快了 firefox 選擇死亡

--

UML 全世界一個樣

UML + SSR

100Mbps
35Mbps
CPU usage: 85%

UML + HAproxy

150Mbps
45Mbps
CPU usage(including python): 90%

看上去很好 不過 UML 在多CPU下就不行了

結論: 可以看得出來 server只有 1vCPU 100多ms delay 下 LKL 最多跑 90Mbps (多幾個CPU數字上會好不少)

270ms delay下 LKL 只有最高50Mbps

比較有趣的是 當 delay 只有 40~50ms 以下 LKL + HAproxy 就會比 LKL + python 快了 而 TSO 也對 HAproxy 更有效果

理由是因為 HAproxy 不需要太大量的 computing 當 bottleneck 不在線路 那 LKL + HAproxy 就會比 LKL + python 好

而TSO減低CPU處理TCP的使用量時 HAproxy 可用的CPU加大一點也很有效果 而 python 因為要加密解密 CPU 釋放了 也沒有差多少

LKL 和 UML 都很依賴CPU CPU用越多的 放在上面跑就越不利 CPU 只有 2000MHz 1800MHz 的 效率也會打折扣

那麼..... 既然效率這麼差 那要用 LKL UML 嗎?

一. 在這邊的大多數人都知道了 慢 是因為掉包掉包掉包 明明向電訊公司申請的是200Mbps 也可以掉成10Mbps的 而 BBR 就解決了這個問題

二. 100Mbps 應該是大部分人的家用網路速度 UML 和 LKL 對於跑上60Mbps 是有餘力的 100Mbps沒有BBR 和 60Mbps 有BBR 這個就要取捨了 (你相信可以跑滿 100Mbps嗎....?) 暫時我也沒有看到有人電信家寬有10G口可以隨便跑滿的...

三. 你看到的數字都是最高極限 打個比方 downlink 有80Mbps 如果有兩台一起跑測試就每台只有 40Mbps

四. 如果是做機場和機長的 就不要用 LKL UML 了 成本上來說不值得 1Gbps 換成 100Mbps 還要 CPU usage 高 不如好好買一台 BWG 的KVM吧

最後最後 BWG 的KVM 也就3刀一個月 好用皮實 OVZ 什麼的 也開始退入歷史了吧.......

--

後記:

誰再懟我
"聽你吹上天"
"bandwidth 也跑不滿的垃圾"
我就發脾氣了
因為我一直沒有覺得我自己有多厲害
也沒有到處吹
真的沒有....
就只有在 91yun 和 v2ray 上說了一下
LKL和UML給一家4口科學上網用是沒問題
LKL UML和Native比速度的話
就不要想了
還是想要懟的話
就找真的有到處吹的人吧.....

最近遇上兩個想收錢幫人安裝 LKL的
一個在Google+ 一個在Telegram
費用是 45 人民幣
我說: 高延遲的 LKL沒可能跑上 100Mbps
結果被人教育了一番
我有特殊的密集恐懼症
最怕腦袋長滿洞的人

想要吹LKL UML 是沒問題啦
不過我在91yun上看到絕對會代替月亮懲罰你的

另外 這邊可以找到實際YouTube 上的效果 https://www.91yunbbs.com/discussion/comment/1385/#Comment_1385 https://www.91yunbbs.com/discussion/comment/1029/#Comment_1029

[nanqinlang]

评论

liuje
liuje 话题数：49会员
四月 2017 最后编辑于 四月 2017 #1

推一個. 很精僻的分析.
內核能升BBR的, 這肯定是首選.
有的VPS用BBR比較快, 有的反而用老牌 銳速 比較快.
(而像放在台灣的vps, 則 銳速一點鳥用都沒有, BBR的速度直接完勝)

再來就是UML.
如果要再省內存的, 可以用LKL..

這是我自己的使用感覺.

當然, 還得考量一個因素. GFW ... GFW在大陸每個省份表現的特性都不同的.

同一個機場給不同地方的人連接, 速度可能會差非常大的.....

別忘了 GFW 的差異性 ~~ ;)

[nanqinlang]

91yun 话题数：222管理员 四月 2017 #2

都有这钱请人帮忙装lkl了为啥不入KVM。。。小白的钱果然是最好骗的。。。o(╯□╰)o可以曝光下这两骗子，防止混入91yun正义的阵营，哈哈 allientNeko allientNeko 话题数：161会员, 大佬 五月 2017 #3

@91yun 说道：
都有这钱请人帮忙装lkl了为啥不入KVM。。。小白的钱果然是最好骗的。。。o(╯□╰)o可以曝光下这两骗子，防止混入91yun正义的阵营，哈哈

telegram 那個 account 也消失了 Google+ 那個是一個叫 Joseph Milton 的人

是用馬甲吧