[玩家限定] VDSL 數據機封包處理能力調查 (第2頁)

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36370935

15分

樓主

2012-06-07 0:31

nacestudio wrote:
hi 我試了一下, ...(恕刪)

小弟在猜
大概是機房那邊卯起來加班
拿了十幾隻小烏龜一隻一隻在測效能
為了怕有其它變因干擾
所以直接把 FTP 站的密碼鎖起來
暫時不給一般人用

您把密碼給爆破了
明天可能又換一組密碼吧

就給機房人員一點空間
別為難底下的小兵

但老實說小弟是因為手邊沒專業設備
才會去拿 FTP 站以及工作管理員
這種人人都可以接觸到的基本配件來架土砲
明明 ftp.speed.hinet.net 本來就是要設置給用戶賽豬公用的
加上機房又花了那麼多錢買下比 SmartBits 還厲害的 ADTech
這種專業機關槍可以掛 TCP flow control 耶
幹麻跑來跟一般用戶搶賽豬公專用土砲玩具啦?

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36373737

15分

樓主

2012-06-07 8:33

既然花店有人在看
那麼還是要展現一下專業
指點迷津

網路上面傳送的封包
會因為各種意想不到的因素
經過 router 的時候被切開
例如在中国使用 VPN 翻牆或是建 GRE Tunnel
一個 1500 byte 的 IP 封包就至少會斷成兩截

TCP 快速傳檔的時候
收兩個封包回一個 ACK
但可能也會有例外
收一回一

所以小烏龜要怎樣開規格?

以 50M (54.4M) 電路來說
假設下行封包切斷之後平均 775 Bytes (含底層封裝)
最大通過率就是 54400000 / 775 / 8 = 8774.19 pps
取個整數算 9000 好了
加上沒被切開的 ACK 上行
總共要 13.5 kpps 不准掉封包
所以每款小烏龜測完不掉包的 pps 數字之後
請至少照下面這個表的規格供應給客戶
如果客戶以後會升速
要嘛到時候換數據機
不然現在就要一次給足 100M 規格
謝謝

這個表僅是半雙工規格
因為目前供裝的頻寬不對稱
上行只是拿來 ACK 而已
如果哪天要推對稱 VDSL
pps 要加一倍

房東的那台 Zyxel P-870H-51 1.00(AWG.3)F3
用 6 條 FTP session 測出來的 13 kpps 是會掉包轉送率
預估不掉包對砍下, 只能穩定用到 24M 而已 (或雙向 12M)
尤其是會跑 GRE Tunnel 的企業用戶

93123211

93123211
個人積分：21分
文章編號：36381192

21分

13樓

2012-06-07 14:10

建議有興趣的朋友，可以向中華要P870-HW51

這台韌體很少更新，若有問題，這台最容易測試出來

小弟等到下禮拜才有辦法拿到這台測試...

nacestudio

nacestudio
個人積分：312分
文章編號：36387475

312分

14樓

2012-06-07 19:07

vcbxnzm wrote:
您把密碼給爆破了
明天可能又換一組密碼吧
就給機房人員一點空間
別為難底下的小兵...(恕刪)

我沒有爆破密碼呀,只是上網google一下就有了,我想應該不是什麼祕密吧
http://speed.hinet.net/index_test02.htm

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36388056

15分

樓主

2012-06-07 19:45

nacestudio wrote:
我沒有爆破密碼呀,只...(恕刪)

昨天的網頁
密碼寫任意輸入
今天早上檢查的時候也是一樣

先後兩次登入的訊息是不同的

ftp.adsl.hinet.net = ftp.speed.hinet.net = 210.61.132.2

看來機房是測完了

如果您在日本的話
也來試一下這台 ftp 可以傳多快
搞不好在日本測
TCP window size 調對的話
會比在台灣用 VDSL 的速度還快咧 orz

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36397394

15分

樓主

2012-06-08 8:34

兩個討論串一件生意都沒上門
看來今晚就會倒閉收場
只好啟動雨天備案

ftp.adsl.hinet.net 換了一個 FTP daemon (說不定機器也換了)
XP 的 TCP 預設值
跑起來的流量圖比先前漂亮一些
猜測是封包送出變得比先前平順
也許 OS 有升級
scheduling 變穩

原本怕說考題出太難沒人願意幫忙測
所以只用預設值
從結果來看還是太難
如果到 deadline 都還沒生意上門
那小弟就直接跟花店硬碰硬了

上回有提過一個 Bandwidth*Delay Product 網頁
這個東西完整的用法要搭配 ping 指令

-l 可以指定 ICMP 的 payload 長度
如果 PPPoE 的 MTU 是 1492
-l 要接 1464
不過小弟的電腦不知何故
MTU 預設值只有 1480
所以 -l 1452 才會通

要去 FTP 站賽豬公的話
小弟這台電腦
指令應該下 -l 1452 這個參數來找到真正的 RTT
封包長短顯然有差

所以把 ping 指令得到的時間延遲拿去 Bandwidth*Delay Product 網頁算一下
54,400,000 bps x 27ms / 8 = 182,250 Bytes
這就是賽豬公的最佳值
但 Window size 通常都會多給一些
我會給 192 KB

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36407265

15分

樓主

2012-06-08 15:36

vcbxnzm wrote:
這是在 scheduling 跟 buffer management 調得不錯的狀況下才有的數字

一早狂測猛測後發現兩個參數

Zyxel P-870H-51 1.00(AWG.3)F3
(1) forwarding process 的 receive buffer 疑似只給了 24 KB
(2) 不掉包轉送率 5.96 kpps

以下是實測過程, 看不懂的話請跳最後一條分隔線, 直接看結論
=============================================================

首先把 MTU 設為 1480 (因為我的電腦不知什麼原因無法設更大的值)
TCP window size 給 10 個封包 (14800 Bytes)
沒掉

32 包 (47360 Bytes)
可以看見幾個 TCP Fast Retransmission
顯然有掉但不算嚴重

17 包 (24.5 KB), 沒掉

20 包 (28.9 KB), 掉了

整條下行的 bottleneck 通常在數據機或 BRAS 上面
從參數可以猜出
28.9 KB 的 TCP window size
有一小部份 (也許一兩包) 卡在網路線跟途中的 router 上
因為網路線有光速的障礙, router 有處理時間
但這個例子, 50M 頻寬只用 30%
所以絕大部分都還是卡在小烏龜 forwarding process 上頭
估計 receive buffer 只給 24 KB 或更少 (如 16 KB)

=============================================================

再來是 forwarding 的處理能力
為了避免被 24 KB 干擾
所以 MTU 用最小值 56
(因為 ethernet 最小值是 64, 少了會補 0, PPPoE 又佔掉 8 Bytes)
TCP window size = 56 x 256 = 14336

這張圖等了五分多鐘終於蹦出來, 瞬間最大值約 14 kpps

之前的流量圖則是一大堆 TCP slow start, 速度歸零

從上面這張圖可以看出來
很多時候碰到第一條刻度線就掉下來
表示雖然會掉包轉送率高達 14kpps
但不掉包轉送率只有 6kpps 附近
土炮就是有這缺點
要透過 MTU / window size 慢慢調參數, 一次次重開機
才能抓到臨界值
有測試設備就好辦了

於是再接再厲繼續測
56 x 128 = 7168

等了一分多鐘, 終於掉封包
8.5 kpps 並不穩, 流量見底表示掉很多包, 所以 slow start

56 x 88 = 4928

因為前一次等很久, 所以把工作管理員改成 2 秒統計一次
結果一下子就出現 fast retransmission

56 x 86 = 4816

等了近 5 分鐘, 完全沒掉包跡象, 5.96 kpps

56 x 87= 4872

同樣沒掉包但是 forwarding rate 慢了一點點
估計是頂到了處理能力邊緣
所以開始有衰退現象, 5.84 kpps

藉由 TCP window size 調整 FTP server 的發送速率
可以發現到
86 包沒事
87 包變慢一點點
88 包出現 packet loss
不掉包轉送率約 5.96 kpps

=============================================================

結論

(1)
工作管理員底下的欄位改成這樣, 上下行分開顯示

上下行封包數
有時 2:3 有時 1:2
因為收到幾個包之後回一個 ACK
是由 OS 的 TCP/IP stack 當中演算法來決定
如果遇到比較早期版本的 OS
也許就是收一回一

所以之前用 1:1 來開規格是有道理的
真的不能太鐵齒, 必須保留一部份安全邊際

(2)
VDSL 數據機的 CPU 不知道是在忙什麼
forwarding rate 最快的瞬間可以飆到 14 kpps
但又可以慢到 5.96 kpps
加上 receive buffer 很短
完全沒有緩衝空間

不知這是否跟 MOD 有關 (小弟的測試環境並沒裝 MOD)
也許小烏龜有很吃重的 process 在處理 MOD 訊務
不管真相如何, 實際可用就只有 5.96 kpps
運氣好的時候下行可以分到 4 kpps
電路層最大封包 1521 Bytes
可以跑到 1521 x 8 x 3973 = 48.3M
問題是 receive buffer 才給 24 KB
實際 TCP window size 前一個回應最底下有寫
要用到 182,250 Bytes 才行
這表示除非換韌體改 receive buffer 參數 (但也不需多到 window size 的 178 KB)
否則根本沒搞頭
CPU 稍微忙一點就掛了

(3)
forwarding rate 飄得很厲害
這表示 OS 的 scheduling 可以改善
比如 forwarding process 改成很平順拿到例如最多 85% 的 CPU time, top priority
處理能力多一倍來到 12 kpps 應該不是問題
不過加入 MOD 的變因之後可能就不是這樣
聽聽便罷

(4)
數據機這種東西大概都是公版
然後為了 cost down
故意用等級很低的 CPU
然後 scheduling 隨便寫寫沒花時間 tuning
buffer 參數也亂給公版預設值, 沒在調校的

花店 hifly 到目前為止恐怕都不知道要開 Packet per Second 的規格
隨便驗收隨便過
如果知道的話就不會亂供裝一通了

(5)
Zyxel P-870H-51 1.00(AWG.3)F3
這台恐怕只能穩定供裝到 36M (FTP 傳檔約 4MB/s)
(5.96 kpps / 2) x 1521 bytes per frame x 8 bits per byte = 36.26 M
而且是上下行不對稱
跟小弟之前對砍亂估的數字差不多

超速就會漸漸容易掉包
沒得商量
申請 50M (54.4M) 結果只能穩跑 32M (36M)
應該退 1/3 電路月租才對
至於企業用戶因為封包很可能會斷開
極端情況下大概只剩 22M (租用 50M 應退 56% 電路月租)

要是按照網頁給的調整檔改 XP
實際結果變這樣

很差勁, 一大堆 TCP slow start
偷

名不虛傳

花店請退 50M / 100M 上市以來
部分受害用戶合理比例已繳電路費
直到數據機問題解決為止

老闆結帳謝謝

93123211

93123211
個人積分：21分
文章編號：36411097

21分

18樓

2012-06-08 18:31

vcbxnzm wrote:
小弟在猜大概是機房那...(恕刪)

給版主打氣一下

民營公用事業監督條例第 14 條

民營公用事業辦理不善，致妨礙用戶利益，或損害社會安全時，經人民陳
訴，由專門技師查明，確有實據者，地方監督機關，得呈准中央主管機關
限令改良。

領過CCNA的應該都算技師，樓主只要找到"地方監督機關"，就可以行文轉請NCC勒令他改善

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36412753

15分

樓主

2012-06-08 20:18

vcbxnzm wrote:
收件截止日只到 6/8 星期五晚上 20:00

生意掛蛋
小弟自己衝了
明天找管媽

vcbxnzm

vcbxnzm
個人積分：15分
文章編號：36437265

15分

樓主

2012-06-10 9:11

錯誤與更正

小弟因為已經有九年沒碰測試
一些小細節已經忘光光還給老師
真不好意思

TCP window size 指的是 TCP payload (L7)
先前計算錯誤
都把 TCP window size 當成 IP packet 長度來算
所以數字有誤
但好在並不影響結果正確性

vcbxnzm wrote:
56 x 86 = 4816

之前測數據機不掉包能力
調整 TCP window size 的目的是控制 FTP server 的傳送速度
TCP window size 應該是 TCP payload 長度的倍數
亦即 MTU - 40 才是 L7 的長度
要用 56 - 40 = 16 的倍數才準確
拿 56 當單位數相當於刻度比較大
控速較不精準

以上面 4816 這個例子來說
4816 / 16 = 301, 剛好整除
實際上, 下行最多有 301 個封包同時在兩部電腦之間流動
而並非先前預期的 86 個

至於先前猜測 receive buffer 有 24 KB
這部分倒不受影響
因為 MTU =1480
每包少 40 Bytes 比例太小
不會影響結果

================================================================

昨天去服務處陳情
結果管媽不在家
由丈夫代打
然後遭到嚴厲的 challenge

這是件好事情
因為受影響人數眾多 (以 10 萬為單位) 的陳情案件
需要用最嚴格的標準再三確認內容的正確性
不然打偏就糗大了
如果只是鄉民鬼叫說網路很慢, 請立委幫忙
並沒有資格得到相當於學位口試般的挑剔

第一階段的測試已經結束
目前已啟動第二階段的陳情與再測試
順利的話估計第二階段一週內可以完成
接下來就立法院見了
花店你趕快投降輸一半
不然就準備好前往交通委員會備詢吧
還可以對著新聞鏡頭說阿木挖底佳唷幫不了你

小弟明天剛好有機會
跟人約好了要去高雄測兩路 50M VDSL 的數據機
希望這兩部數據機不是同一款
回家就會把結果貼上來

至於房東這條 50M 線路
因為週末用的人比較多
上班時間才會沒人用
所以明天或後天也會用更精準的參數重測一遍