我正在準備對教室 WiFi 系統進行負載測試。學生在課程開始時都會打開筆記型電腦，這會啟動網頁瀏覽器，然後他們開始課程 - 這涉及下載基於 Flash 的課程（從學校內的伺服器），通常下載一半到 2 MB。
在某些情況下，載入時間會延長至 5 或 10 分鐘。因此，我想監控系統的所有部分，以便自信地說出瓶頸在哪裡，以及有多少客戶可以合理地使用單一 wifi 接入點。因此，我們計劃對最多50 個客戶端進行測試，看看會發生什麼（我知道大多數人建議每個接入點20-25 個客戶端，但客戶端想要對此進行測試- 並且我想要獲得良好的數據來向客戶端展示不管怎樣）。
我已經知道如何監控伺服器了。 wifi接入點支援SNMP，並且似乎提供了相當多的變量，但我不想費力地了解太多。
所以問題是，當系統過載、客戶端等待、發生衝突等時，哪些與 wifi 相關的變數是需要監控的關鍵變數？
我很高興被告知應該在那裡的通用名稱，並自己搜索文件，但如果您想/需要查看詳細信息，那麼我們使用的接入點是無所不在的 Nanostation 2。 Ubiquity 產品的 MIB 檔案從底部鏈接他們的 SNMP 頁面。雖然我也發現他們似乎至少支持部分米克羅蒂克 MIB。
答案1
簡單的方法只是定期監視IF-MIB::ifInOctets.<ifIndex>/ IF-MIB::ifOutOctets.<ifIndex>OID 並檢查可用頻寬。從連結的 MikroTik MIB 中，您可以透過讀取 mtxrWlStatTxRate:1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex>和 mtxrWlStatRxRate:來發現目前設定的速率1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>。這當然不會考慮無線細節，但能夠讓您粗略地了解介面上的總可用頻寬是否是瓶頸（如果您看到接近總頻道容量的使用情況，則很可能是瓶頸）。
一般來說，除非您的站或天線位置不佳且以太在所選通道頻率上是乾淨的，否則您可以預期單個 G 通道的吞吐量約為 2-3 MB/s (54 MBps 2.4 GHz)。
如果您需要來自 AP 端的更多有關重試和錯誤的具體信息，您可以閱讀dot11CountersIEEE802dot11 MIB 的表 - 特別是相應實例的dot11RetryCount、dot11MultipleRetryCount和值。dot11FailedCount
802.11 沒有任何衝突，但有物理載波偵聽和可選的RTS/CTS 握手在傳輸幀之前。監視dot11RTSFailureCount可以讓您粗略地了解 CTS 未回覆 RTS 請求的頻率，從而不向發送站授予頻道。
請注意，如果您的存取點產生了絕大多數流量（即網站主要接收資料），您可能會看到相對較少的重試和 RTS 失敗次數。您可能想要查看IF-MIB::ifOutDiscards.<ifIndex>無線接口或IF-MIB::ifInDiscards.<ifIndex>有線接口，只要緩衝區已滿並且無法接收任何其他幀（即 AP 以全速率發送，但以太網接口上的幀），這些數字就會增加繼續以更快的速度到達）。
答案2
如果您想要做的只是向客戶端證明它們正在使 AP 過載，則可以使用 dot11RetryCount 和 dot11MultipleRetryCount OID。
dot11重試計數 - 1.2.840.10036.2.2.1.4
dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5
這將使您粗略估計空氣的擁擠程度。一旦重試計數達到 dot11TransmissedFrameCount 的 10% 以上，您將開始看到速度變慢。
這是 Cisco 的 MIB 物件遍歷器 - 如果您需要找出其他要檢查的 OID，它應該會有所幫助。