遊戲 Lag 白皮書 › L3 家用網路
Bufferbloat（分享器佇列） Bufferbloat
原因 ID hn-bufferbloat · 主要負責 外部（外部） · 協同 遊戲開發團隊（用戶端開發）
在含圖解與實驗的完整版中開啟卡片 →
家人上傳影片或下載大型檔案時，分享器佇列會堆積相當於數百 ms 的封包，遊戲封包也得排在後面等待。
為什麼 家人上傳影片、雲端備份、自己的直播推流、大量下載把線路塞滿 → 於是 分享器或數據機把滿出來的封包堆進很大的佇列 → 畫面上 遊戲封包也排在佇列後面等待，ping 暴增到數百 ms
- 症狀
- 輸入延遲, 快轉, 瞬移
- 因素
- 延遲, 抖動
- 誰會遇到
- 同一個家, 只有我
- 何時
- 偶爾隨機發生, 晚間尖峰時段
- 負責單位
- 主要負責 外部（外部） · 協同 遊戲開發團隊（用戶端開發）
- 遊戲開發團隊要做的事
- ping 突然升到數百 ms 時在畫面上顯示網路狀態（提示可能有同一條線路上的大量傳輸）。
- 外部要做的事
- 引導玩家使用有 SQM（fq_codel、CAKE）或 QoS 的分享器，把 SQM 速率設為線路速度的 90～95%（這樣佇列才會產生在分享器內，才有效果），並限制上傳速度。
- 數值參考
- 上傳 10Mbps 的線路配上 1MB 緩衝區，佇列最長會累積到相當於 800ms 的量。
- 圖表上
- 隨人數／負載上升 · RTT、線路上傳與下載用量
- 查看位置
- 開著 ping 用測速把線路塞滿，或使用量測負載下延遲的網頁測試（Bufferbloat.net 的說明）。與分享器介面上的上傳、下載用量一起查看
- 符合的跡象
- 上傳或下載塞滿線路的期間 ping 升到數百 ms，傳輸結束後恢復（負載下延遲超過 50ms 就值得懷疑）。開啟 SQM 後消失
- 不符合的跡象
- 線路很閒 ping 卻飆高時，是「Wi-Fi 干擾與訊號減弱」或「線路品質不良」
- 確認方式
- 在玩家端環境確認
- 深入了解
- 上傳方向特別容易塞住，因為 Cable 寬頻與行動網路的上傳頻寬往往比下載窄得多。光纖頻寬充足的家庭則是 Wi-Fi 區段成為瓶頸，同樣的情況會發生在分享器的無線佇列。遊戲封包很小，幾乎不占頻寬，但同樣得在佇列中等待。只有上傳方向塞住時，延遲的只有自己的輸入，其他人的動作正常。手機上，同一支手機的照片備份與 App 更新會塞滿手機數據機與基地台的佇列，造成同樣的情況。
出處
- Setting up SQM for CeroWrt 3.10 Bufferbloat.net
要把 SQM 速率降到實測速度的 95%（以宣傳速度為準時為 85%），把瓶頸從電信業者設備移到分享器內才有效果 - SQM (Smart Queue Management) OpenWrt
下載、上傳速度輸入實測值的 90%，佇列演算法建議用 cake（CPU 較弱時用 fq_codel） - Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017) USENIX
Wi-Fi 區段塞滿時，分享器的無線佇列會產生數百 ms 的延遲；改善無線佇列後，負載下的延遲約降為 10 分之 1 - Tests for Bufferbloat Bufferbloat.net
開著 ping 用測速把線路塞滿，ping 上升就是 bufferbloat；負載下延遲超過 50ms（或評等低於 B）時建議採取對策
相關原因
同一層：L3 家用網路
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片