麻煩討論時不要硬將不知道的領域亂解釋,看了實在讓人無言..
麻煩討論時不要硬將不知道的領域亂解釋,看了實在讓人無言..
基本上內部用的監測網頁就只有從設備讀取 Line Rate 跟 Payload Rate 兩項這項的值,從 Payload Rate 對照 申請速率的值可以知道有沒有設定錯誤,而 Line Rate 高於 Payload Rate 就不會有問題,只要知道這兩項再加上 SNR 和 衰減 加上 有沒有 CRC 或 RS 就可以知道客戶端的線路正不正常了。
當然客戶出狀況時上述的狀況都只是參考值,就有實際的案例是客戶端線路有 T接,可是 Line Rate Rate、SNR、衰減看起來都正常,也沒有 CRC 和 RS ,但是客戶就是會斷線,解 T 之後客戶就不會斷線了,但是上述所有的值都沒有變好或變壞,連 VTU-R 裡面的 Line Rate 也沒有什麼異狀,這個 Case 就是 Zyxel P-872HA。
另外一個 Case 是 DLink 5540C,監測網頁測試的值都沒有問題,但是從電話線路測試發現可能的問題點,發現交接箱跳接線一支腳鬆動,接好之後客戶還是會亮紅燈瞬斷,有電話打入也會亮紅燈。
往客戶端查測以為有 T接,結果是有正常迴路的,發現保安器的碳鋅片拔除後正常,而屋內線也沒照正常配色接法也一並修改,打入電話測試已經不會瞬斷了,再次查看設備數值 Line Rate 沒有變化,SNR 、衰減的差異都在正負 1的範圍內。
所以這些數值都只是參考用的,不需要太拘泥,因為可能看起來正常但是可能線路有問題用起來也有問題,也可能看起來不正常線路卻是正常的用起來也沒有問題。
接二連三的案例可以發現實際上的經驗會比理論來得重要,太拘泥於這些數值反而會被誤導。
至於”因此Payload(人為設定)幾乎會等於Line Rate(自動協定)且幾乎等於Actual Net Data Rate(自動協定)”這是不一定的,因為不同廠商的計算公式或參數可能會有差異。
像 Zyxel 的設備幾乎差異不會差過 1Mbps,但是 DLink 差不多是在 3 以上,所以你說”幾乎等於”就要看這個差異的範圍是多少了。
此文章於 2009-09-19 11:22 PM 被 spooky_mulder 編輯。
大師, 這回又被您料中了??
您不是一會兒懷疑是中華的人亂搞?
一會兒又直指人家設備故障或設備不穩?
然後又一再的扯MOD出來....
可是實際的情況是和MOD根本完全沒關係,
也不是啥機器運算錯誤, 更不是設備故障或不穩,
只不過就是原廠在CPE的使用者界面程式中
把顯示Line rate那行的公式代錯了,
可是, 您又把人家的話解釋成機器內部運算錯誤.....真有你的!!
實際上的Line Rate也不是樓主的VTU-R設定頁裡顯示的那個錯誤的數值.
那麼愛算Line rate和Net data rate, 不妨把ITU-T的建議書看一看吧!
http://www.itu.int/rec/T-REC-G.993.2-200602-I/en
實質意義不大的東西,正不正常的意義也不大。
Actual Net Data Rate 是使用者真正可用的頻寬,有申請 MOD 的話會包含 MOD 的頻寬,而 Actual Net Data Rate 會比 Line Rate 更接近 Payload Rate,為什麼呢,因為 Line Rate 是包含 Actual Net Date Rate 加上 Overhead 所需要的頻寬,所以會不會跟 Payload Rate 差太多,就要看 Overhad 有多大了。
而 CHT 目前用到的 DLink 5540C,以 10M/2M 來說其 Payload Rate 跟 Line Rate 至少差了 3Mbps,所以你說的”Line Rate(自動協定)絕對不會和Payload差太多(過多或過少), 差太多一定是不正常”這個推論是不成立的。
而你這一次又是瞎貓碰上死耗子,又給你矇到了。
你是猜對了,可以你的推論過程是錯的,或是說你根本沒有推論過程。
書籤