• 5

[玩家限定] VDSL 數據機封包處理能力調查

來介紹一款江湖失傳已久的神兵利器
RASPPPOE
雖說 XP 之後的作業系統都可以撥 PPPoE
但這款軟體除了給 95/98/ME/2K 補丁之外
XP 也好用
而且非常精簡
比 Enternet 快多了

首先安裝通訊協定驅動程式
裝好之後像這樣


厲害的來了
除了 MTU 預設值是 1492 之外 (XP 預設值 1480, 還調不上去)
還可以手動指定連線速率刻度, 把 100% 對應的速率填進去 (如下圖 12784)
然後工作管理員看到的 PPPoE 連線速率
就不再是比照實體網卡


另一個厲害的地方是
以前 Enternet 可選填 service name
但這功能 XP 以後的 OS 都省略掉了
這代表 LAN 上只能有一條 xDSL
可 RASPPPOE 並沒有閹割掉這個功能


所以假設有一路 ADSL 一路 VDSL, 分屬不同 ISP
就可以把兩隻小烏龜的 LAN 用一條網路線串在一起
PC 接到 LAN 之後
就能同時看到兩家 ISP 的 BRAS (如上圖)
然後個別設定帳號密碼
神奇的秘技是
一台 PC 可以同時撥兩路 PPPoE 出去
相當於有兩個 WAN, 接到不同的 ISP
再搭配 route 指令後
就可以做 load balancing
怕了吧

vcbxnzm wrote:
來介紹一款江湖失傳已...(恕刪)


想請教大哥一下

中華一個HN可以同時撥八個,但我同台電腦撥同一BRAS第二次就會顯示數據機被占用中

是有哪裡設定錯誤?? 還是同時只能和一台BRAS一個SESSION?
93123211 wrote:
但我同台電腦撥同一BRAS第二次就會顯示數據機被占用中


IP 分享器兩個 WAN 可以在同一條電路撥兩個 PPPoE session
那是因為兩個 WAN 用了兩個 MAC address 的關係
如果要用同一台電腦撥號的話
猜測也許要用不同的卡號才行
踹看看吧
今天測試的是 D-Link DSL-6641K 1.0.3.bbtj.6641kS6 (101 年 3 月交貨)




這台數據機的功能很妙
除了 WLAN 之外
最有趣的地方莫過於分享器功能
NAT 打開之後
四個 LAN 孔仍舊可以同時撥 PPPoE
這代表可以用數據機拿固定 IP
但臨時需要浮動 IP 的時候 (例如免空要抓第二個檔案)
撥一下馬上有
至於一般 IP 分享器也可以做同樣的事情
只要把小烏龜的兩個 LAN 孔
一條接分享器的 WAN
一條接分享器的 LAN
這樣一來也有同樣效果
但是接之前要注意
通常 IP 分享器跟小烏龜都用 192.168.1.1
小烏龜會報修更換
建議把 IP 分享器改成 192.168.1.254 比較沒困擾

==================================================================
FTP 賽豬公 (MTU = 1492)

首先用下面四個指令比較 RTT
>ping 168.95.98.254 -n 32 -l 0
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 16ms, Maximum = 18ms, Average = 16ms

>ping 168.95.98.254 -n 32 -f -l 1464
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 20ms, Maximum = 21ms, Average = 20ms

>ping 210.61.132.2 -n 32 -l 0
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 21ms, Maximum = 22ms, Average = 21ms

>ping 210.61.132.2 -n 32 -f -l 1464
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 25ms, Maximum = 26ms, Average = 25ms

168.95.98.254 猜測是 BRAS 的 virtual interface
似乎很多台 BRAS 都用這個 IP 的樣子
210.61.132.2 則是 ftp.adsl.hinet.net
至於 -f -l 1464 參數
可證明 MTU 確實是 1492 無誤
54.4M x 25 ms / 8 (bits per Byte) = 170,000 Bytes
170,000 x (1452/1521) = 162,288
這就是 TCP window size 的理論值

由於時間有點趕
沒辦法在別人家裡仔細測
只能重點挑幾個值來取樣

工作管理員欄位


TCP window size = 65535
65535 / 1452 = 45.13 (45 包)




TCP window size = 192 KB
196608 / 1452 = 135.41 (135 包)




TCP window size = 1 MB
1048576 / 1452 = 722.16 (722 包)




流量圖每 0.5 秒統計一次
由於灌了 RASPPPOE, 指定 100% = 54336 kbps
1% = 543 kbps
所以跟 XP 內建的介面不大一樣

TCP window 是 pipeline 的概念
照說 192 KB 的流量應該是 64 KB 的三倍
但因為已經頂到瓶頸
所以三倍不到
這也證實了理論值 170,000 Bytes 是合理的推測

至於 1MB 的瞬間值比 192 KB 還高
猜測原因跟小烏龜的 dispatch 演算法有關
因為機器是別人的
縱使測試時沒其他人用網路
但小弟還是不敢關掉裡面的分享器
也許 192 KB 時 queue 比較短
有保留頻寬給內建分享器
但 1MB 時 queue 拉很長
所以搶到比較多頻寬
很遺憾
這部份只能淪為猜測
畢竟小弟沒有 lab 環境可亂玩

喜歡賽豬公的網友們
看到了吧
TCP window size 搞得無敵長
只會造成很多不必要的 slow start
192 KB 沒大坑洞
正常情況下會跑得比 1MB 要快才對
親愛的 TTC, 就別再抄了吧


之前猜測 Zyxel 舊款數據機的 receive buffer 只有 24 KB 或更少
原因是基於 VDSL 電路頻寬沒有用完
bottleneck 落在小烏龜的 forwarding process 上面
至於上面 1MB 的測試
因為 50M 頻寬用滿了
bottleneck 落在 BRAS 上面
顯然 BRAS 給的 buffer 不到 1MB
所以才會一下就掉包
啟動 slow start

也因為小烏龜跑得快
這個環境沒法猜 receive buffer
或許 VDSL 電路調到超過 100M
就可以見真章

==================================================================
封包轉送率測試 (MTU = 88)

為了去別人家測試卻怕開機太慢
所以重灌了 XP
結果卻沒辦法讓 MTU < 88 Bytes
好在這也不算太差, 電路層的封包長度從 85 Bytes 拉長到 117 Bytes

TCP window size = 480 Bytes (10 包)



TCP window size = 4800 Bytes (100 包)



TCP window size = 48000 Bytes (1000 包)


開 2 條 FTP 連線

開 6 條 FTP 連線


因為今天上午高雄下雨下得跟颱風天一樣
最前面第三張圖的 15 分鐘錯誤封包 (FEC) 有 149
10 包流量圖的那個坑
大概是被雷打到的關係
忽略這個變因不談
上下行封包速率大約每秒 600 個
(最右邊那一欄, 半秒統計一次, 270 ~ 330 之間跳動)
而 100 包的封包速率果然是每秒 6 kpps
果然有等比例增加

但 1000 包咧? 頂到了處理極限
不掉包速率每秒不到 30 kpps

假設理想狀況上下行封包數比例 1:2
封包也沒斷開
30 kpps 的下行速率是 30k x 2/3 x 1521 x 8 = 243.36 Mbps
夠用了

而上下行封包數比例 1:1
封包又斷開的話
下傳速率剩 30k x 2/3 x 775 x 8 = 124 Mbps
100M 速率也還是夠用

但如果是企業型
不只由外往內抓檔, 也要開 server 由內往外傳檔
雙向 100M 肯定不夠用, 大概只能跑七折速度而已
另一台是姐妹機 D-Link DSL-6541K


跑 12M (12784 kbps)
這台有重要的低流量即時訊務在跑
不敢殘殘就給它喬落去
所以數據僅供參考, 無法列入正式樣本

==================================================================
Round Trip Time

>ping 168.95.98.254 -n 32 -l 0
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 16ms, Maximum = 30ms, Average = 16ms

>ping 168.95.98.254 -n 32 -f -l 1464
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 23ms, Maximum = 63ms, Average = 32ms

>ping 210.61.132.2 -n 32 -l 0
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 22ms, Maximum = 39ms, Average = 22ms

>ping 210.61.132.2 -n 32 -f -l 1464
Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),
Minimum = 28ms, Maximum = 47ms, Average = 29ms

12784 kbps x 28 ms / 8 (bits per Byte) x (1452/1521) = 42,714 Bytes
TCP window size 大約給 48 KB 就夠用

從 50M/5M 跟 12M/3M 的 RTT 來比較
短封包短距離下
這兩路幾乎沒有時間差
又假設 BRAS 的反應時間在 1ms 之內
代表短封包穿過數據機大概需要 7 ms
去回各一次就 14 ms
跟 FTTx 火拼 online game 大概就中槍了

至於長短封包兩相比較
估計長封包穿過數據機兩頭大約 9 ms (VTU-R + VTU-C)
顯然用軟體檢查標頭少說要花 6 ms
烏龜果然名符其實

==================================================================
封包轉送率測試 (MTU = 88)

10 包



100 包



200 包



300 包



不好意思因為不敢超限測試
所以沒開很多路 FTP 亂灌封包
300 包到此為止

10 -> 100 有等比例增加
100 -> 200 沒倍增
200 -> 300 也不是 1.5 倍
顯然也是跟姐妹機一樣
有個演算法在配 CPU time
但不論如何
這台拿來跑 50M 是夠用
但 100M 要把 TCP window size 不合理加長才有機會用到滿
50M 可 100M 不優
我目前用光世代50M/5M,可以把原本的DSL-5540c換成Vigor 2750??
vcbxnzm wrote:
另一個厲害的地方是
以前 Enternet 可選填 service name
但這功能 XP 以後的 OS 都省略掉了...(恕刪)

Service Name可在"內容"裡面指定

圖片來源
1tac wrote:
Service Na...(恕刪)


是沒錯可以自己
可是沒得看沒得
沒軟體的話根本不知道要填什麼

以前用 Enternet 撥號的時候可以抓
RASPPPOE 也可以列出來
但 XP 的內建撥號沒得抓
或者是小弟比較笨沒找到功能

機房有個大絕招
萬一 BRAS 壞掉的時候
直接拔網路線插到備用機上
這時候 service name 會跑掉
還有一種情況是整體的用戶用量持續成長
必須降低集縮比的時候
也會有改接的情形發生

所以一般情況下並不建議填這個值
Sasukeevil wrote:
可以把原本的DSL-5540c換成Vigor 2750??


真是傷腦筋
小弟不是廠商
用型號搜尋而已並沒指定特定頁面 (當然也沒向站方買廣告)
結果剛剛的留言一下子就被河蟹掉

這問題請跟店家問吧
還可以盧七日鑑賞期
小弟等您的開箱文

-----------------------------

站方言論審查的幹法
害我想起孫大砲的寓言故事

站方把網友開箱熱情聚集出來的點閱市場
拿來開發商業利益
景點書事件沒比照光碟月刊把廠商告到賠錢, 網友已經是很客氣了
想不到收割完利益之後竟還要回頭打壓這股不求回報的熱情
只因為疑似會擋到自己財路?

這真是遺憾啊

開箱文又不只是該篇文章而已
前置作業算不算?
網友間評估購買的討論過程
也要羅織入罪?
哪豈不跟 NCC 有拼?

小弟開始懷疑
m01 的開箱文到底剩多少比例不是商業廣告?
能不能深入探究產品的特質呢?
該不會只剩下文案人員的作文比賽吧?


m01 正往超頻者天堂之路邁進
趁這幾天熱情還在
趕快多寫點密技
不然小弟一再被嚴重侵害言論的審查規矩惹毛了
應該會用腳投票

TCP window size 是 pipeline 的概念
資訊科系的人一聽到關鍵字就知道意思了
但還是要解釋一下這啥玩意兒

汽車組裝或者像富士康這類 EMS 的流水線是最明顯的例子
一條組裝線可以把所有工序分解成一個個單一動作
每個人只需專注做好各自的動作
假設全部過程可以拆成 100 個單一動作 (stage)
當流水線全速運轉的時候
一個單位時間就能夠產出一台
而每一台成品都需要經過 100 個單位時間通過這 100 關
這就是所謂的 pipeline
當然也可以努力訓練出熟練 100 道工序的師傅
再僱 100 個師傅來達到同樣產出
比較貴而已

封包在網路上流動的時候
通過每個節點都需要花時間判斷下一步往哪邊走
此外節點之間的網路線也有光速障礙
通過總需要花點時間
這就跟組裝一樣, 有一大堆工序

如果發一個封包之後
必須等對方回應了 "收到" (ACK) 才能送下一包
速度會很慢
例如 50M VDSL 抓檔的 RTT 需要 25 ms
代表每秒只能送 40 包, 也就是 40 x 1.5 KB = 60 KB/s
這就好比只請了一個全能師傅來慢慢組裝
而 TCP window 的概念
就像那 100 道工序一樣
讓網路上隨時有 N 個封包在流動
只不過最佳的 N 值 (stage) 要用 ping 指令來找
而且每個網站的 N 都不同
N 給少了, 流水線沒辦法滿速運轉
但給多了, 也只是把半成品積在流水線最慢的關卡而已
N 不小心給太多?
流水線瓶頸處的工作空間 (buffer) 大概會塞爆掉

再回到 50M VDSL 的例子
抓檔的 RTT 需要 25 ms
假設 TCP Window Size 給 150 KB
而每個封包的 MSS (MTU 扣掉 TCP/IP 標頭) 大小剛好 1536 Bytes (但實際上不能這麼設定)
表示有 100 個包在半路上流動不用收 ACK
這樣一來就可以把 50M 的頻寬用將近滿載
例如 server 目前剛收到編號 017314 的 ACK
就可以把直到編號 017414 的所有封包都送出去

流水線太長有個缺點
如果中間有一關的員工肚子痛離開座位
整條生產線就會卡關停下來
如果產品有作業時間限制的話 (食品生鮮類?)
丟掉半成品重新啟動得再花 100 單位時間才有第一個產出
TCP window size 拉很長
同樣怕掉封包
對方回報資料沒收到時
slow start 必須從斷點開始全部重傳

TCP Window Size 給得霹靂大
只會讓流水線的瓶頸爆掉
啟動重傳機制而已
所以跑不快


這麼說明總該明白
TTC 的肉腳程度了吧
  • 5
內文搜尋
X
評分
評分
複製連結
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?