釐清產業用相機通訊停滯數秒的案例

案例概要

這是一個在產業用相機控制中，處理「平常都正常運作，但偶爾通訊只會停滯數秒」現象的案例。 由於看起來既像是應用程式端停止，也像是網路端的問題，因此必須先把「究竟是什麼停住了」分開思考。

症狀

• 通訊以低頻率停滯數秒
• 看起來並不像 UI 或整個行程完全停止
• 在設備控制中，即使只停滯數秒，對現場的衝擊也很大

限制

• 發生頻率低，只靠日誌難以看出重現條件
• 看起來相機 SDK、NIC、交換器、應用程式實作的任何一處都可能是原因
• 必須在不破壞接近正式環境條件的前提下釐清問題

觀測了什麼

• 為了先排除應用程式內部的停止因素，確認處理延遲與有無例外
• 以封包擷取觀測 Retransmission 與時間差
• 確認 TCP 選項與重送等待時間的形狀是否與症狀一致

如何釐清問題

驗證了通訊停滯是否能不當成「應用程式停住了」，而是當成封包遺失後的重送等待來處理。 結果判斷出停滯的真面目並非應用程式的 deadlock，而是 TCP 端的等待時間浮上檯面的結構。

如何改善

• 判斷了 RFC1323 系列的時間戳記設定是否處於會生效的條件
• 調整成能縮短重送等待的架構
• 為了今後也能在 wire 層級觀察，整理了觀測步驟與釐清問題的觀點

本案例連結的服務

本案例同時連結到以證據釐清難以重現的通訊停滯的故障調查・根本原因分析，以及從應用程式端重新檢視通訊設計與監視設計的 Windows 應用程式開發。

相關文章

聯絡我們

如果您遇到的課題與本頁內容相近，歡迎附上目前狀況與所需支援的形式與我們聯絡。