Log for Ubuntu 台灣社群
為了這件事我還開發了一個專門拿來備份重要資料的工具： https://gitlab.com/brlin/migrate-rootfs-utilities
另外再搭配這個把我常用的軟體跟設定統統裝回來： https://gitlab.com/brlin/brlin-os-customizations/
從 400 Mbps 到 1.7 Gbps：一次 Wi‑Fi 7 除錯之旅 （★ 100 分）
作者在準備升級家中網路到 2.5 Gbps 時，換用了支援 Wi‑Fi 7 的 UniFi Dream Router 7，希望搭配 iPhone 17 Pro Max 能充分發揮新規格速度，卻發現實測僅能跑到 400 Mbps。經過多次測試與排查，他先確認有線網路骨幹可達 2.3 Gbps，問題僅出在無線部分。他改用 `iperf3 -R` 的反向傳輸模式、嘗試不同頻寬設定，甚至搬動伺服器端位置，仍然無法超過 700 Mbps。最終發現關鍵錯誤：雖然 SSID 設定為 160 MHz，但實際電波仍以 80 MHz 運作，導致連線受限於 2×2 MIMO 80 MHz 約 1.2 Gbps 的上限。將無線電設定明確指定為 160 MHz 並將傳輸功率調高後，速度立即躍升至 1.6 Gbps，達到理論上 Wi‑Fi 7 160 MHz 4096‑QAM 實際效能的範圍。
文章進一步解釋，`-R` 旗標（反向模式）對無線測速尤其有效，因為基地台的發射功率與天線效能優於手機；同時加上多串流參數（例如 `-P 6`）可突破單一 TCP 流的啟動與緩衝限制。雖然理論上 2×2 160 MHz Wi‑Fi 7 能連線到 2.88 Gbps，但算上 MAC/PHY 開銷、TCP/IP 標頭與加密負擔後，實際可用吞吐率通常只占連線速率 60 % 到 75 %，因此 1.6 Gbps 到 1.9 Gbps 已是合理表現。若要突破 2 Gbps 僅能透過 320 MHz 頻寬、多空間串流（3×3 或 4×4）或 MLO 多頻段聚合等功能，而這些目前都不支援於 iPhone。作者最後列出測速心得：不要在路由器上直接跑伺服程式、確認實際頻寬設定、調高發射功率做測試、使用反向多串流模式並保持適當距離，這些方法能接近真實世界最佳結果。
Hacker News 上的討論延伸到多層面。多人指出作者最初將 iperf 伺服器跑在路由器上導致 CPU 資源競爭是常見錯誤，因為路由器的封包轉發多在硬體完成，但若同時執行 TCP 傳輸軟體便可能成為瓶頸。也有網友分享自己開啟硬體加速或關閉 IDS（入侵偵測系統）後吞吐量大幅改善，顯示 UniFi 軟體設定常有隱藏限制。部分使用者提出功率設定的「囚徒困境」：在密集住宅區若人人都調到高功率，最終只會造成干擾；但也有人指出 6 GHz 頻段穿牆弱、干擾少，實際影響有限。另有留言提醒並非所有 2.5 Gbps USB 網卡在 macOS 下都能完全跑滿，部分 Realtek 晶片受驅動程式限制會卡在 1.9 Gbps。
討論後段出現對家用高速網路需求的辯論，有人質疑為何家裡需要 2.5 Gbps 或 1.7 Gbps 連線，另一派則列舉如大型遊戲下載、RAW 照片處理、虛擬機備份、AI 訓練資料集分發與 VR 串流等應用，說明高頻寬在專業與娛樂場景皆有實際價值。也有技術派指出若美國 FCC 實施 6 GHz 頻段拍賣，可能衝擊 Wi‑Fi 7 的長期發展。整體而言，社群對作者的測試過程給予肯定，認為其詳細的除錯紀錄對想在家重新調校 Wi‑Fi 7 設備、追求高傳輸效能的使用者頗具參考價值。
👥 75 則討論、評論 💬
https://news.ycombinator.com/item?id=45784729
作者在準備升級家中網路到 2.5 Gbps 時，換用了支援 Wi‑Fi 7 的 UniFi Dream Router 7，希望搭配 iPhone 17 Pro Max 能充分發揮新規格速度，卻發現實測僅能跑到 400 Mbps。經過多次測試與排查，他先確認有線網路骨幹可達 2.3 Gbps，問題僅出在無線部分。他改用 `iperf3 -R` 的反向傳輸模式、嘗試不同頻寬設定，甚至搬動伺服器端位置，仍然無法超過 700 Mbps。最終發現關鍵錯誤：雖然 SSID 設定為 160 MHz，但實際電波仍以 80 MHz 運作，導致連線受限於 2×2 MIMO 80 MHz 約 1.2 Gbps 的上限。將無線電設定明確指定為 160 MHz 並將傳輸功率調高後，速度立即躍升至 1.6 Gbps，達到理論上 Wi‑Fi 7 160 MHz 4096‑QAM 實際效能的範圍。
文章進一步解釋，`-R` 旗標（反向模式）對無線測速尤其有效，因為基地台的發射功率與天線效能優於手機；同時加上多串流參數（例如 `-P 6`）可突破單一 TCP 流的啟動與緩衝限制。雖然理論上 2×2 160 MHz Wi‑Fi 7 能連線到 2.88 Gbps，但算上 MAC/PHY 開銷、TCP/IP 標頭與加密負擔後，實際可用吞吐率通常只占連線速率 60 % 到 75 %，因此 1.6 Gbps 到 1.9 Gbps 已是合理表現。若要突破 2 Gbps 僅能透過 320 MHz 頻寬、多空間串流（3×3 或 4×4）或 MLO 多頻段聚合等功能，而這些目前都不支援於 iPhone。作者最後列出測速心得：不要在路由器上直接跑伺服程式、確認實際頻寬設定、調高發射功率做測試、使用反向多串流模式並保持適當距離，這些方法能接近真實世界最佳結果。
Hacker News 上的討論延伸到多層面。多人指出作者最初將 iperf 伺服器跑在路由器上導致 CPU 資源競爭是常見錯誤，因為路由器的封包轉發多在硬體完成，但若同時執行 TCP 傳輸軟體便可能成為瓶頸。也有網友分享自己開啟硬體加速或關閉 IDS（入侵偵測系統）後吞吐量大幅改善，顯示 UniFi 軟體設定常有隱藏限制。部分使用者提出功率設定的「囚徒困境」：在密集住宅區若人人都調到高功率，最終只會造成干擾；但也有人指出 6 GHz 頻段穿牆弱、干擾少，實際影響有限。另有留言提醒並非所有 2.5 Gbps USB 網卡在 macOS 下都能完全跑滿，部分 Realtek 晶片受驅動程式限制會卡在 1.9 Gbps。
討論後段出現對家用高速網路需求的辯論，有人質疑為何家裡需要 2.5 Gbps 或 1.7 Gbps 連線，另一派則列舉如大型遊戲下載、RAW 照片處理、虛擬機備份、AI 訓練資料集分發與 VR 串流等應用，說明高頻寬在專業與娛樂場景皆有實際價值。也有技術派指出若美國 FCC 實施 6 GHz 頻段拍賣，可能衝擊 Wi‑Fi 7 的長期發展。整體而言，社群對作者的測試過程給予肯定，認為其詳細的除錯紀錄對想在家重新調校 Wi‑Fi 7 設備、追求高傳輸效能的使用者頗具參考價值。
👥 75 則討論、評論 💬
https://news.ycombinator.com/item?id=45784729
最近 Firefox(latest/candidate/core24) 分支遇到了一個問題：動畫瘋的影片多快轉的幾次會直接報錯中止播放，不知道有沒有人有遇到同樣的問題？
瀏覽器開發者主控台的錯誤訊息：
瀏覽器開發者主控台的錯誤訊息：
virtual MediaResult mozilla::FFmpegVideoDecoder<60>::DoDecode(MediaRawData *, uint8_t *, int, bool *, MediaDataDecoder::DecodedData &): avcodec_send_packet error: End of file