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

allientNekoallientNeko 话题数:161会员, 大佬
最后编辑于 April 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 什麼的
也開始退入歷史了吧.......

--

後記:

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

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

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

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

此话题使用的标签:
此话题使用的标签:

评论

  • liujeliuje 话题数:49会员
    最后编辑于 April 2017 #1

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

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

    這是我自己的使用感覺.

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

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

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

  • 91yun91yun 话题数:223管理员

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

  • allientNekoallientNeko 话题数:161会员, 大佬

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

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

    是用馬甲吧

登录注册后才能评论。