診斷 GigE 封包遺失，且不掩蓋故障

本測試要回答的問題

把影像傳輸不完整，與漏觸發和應用程式佇列遺失區分開來。僅靠影格計數器無法判斷是哪一層出了問題。

這是一份與廠商無關的現場調機方法。更改任何設定之前，請先查閱所用具體型號的相機、鏡頭、感測器或控制器手冊。文中的數值範例表為假設資料，既不是 Deyi Vision 的量測結果，也不是產品規格。

前置條件

使用量產時的像素格式、ROI 和觸發方式。打包格式和 chunk 資料都會改變酬載；應採用相機回報的酬載大小，而不是憑猜測的每像素位元組數。

只有先分清漏觸發與不完整的網路影像，才能開始測試。應用程式日誌裡缺少某個工件，也可能是處理失敗或檔案寫入失敗。確認現場的相機和接收端提供哪些計數器，並根據該型號的手冊記下它們的定義。不要把不相關的逾時當作封包遺失計數器來推斷。更改網路卡、封包大小或驅動程式選項之前，先保留出現故障時的原始設定。

測試台與紀錄

準備專用的 NIC 路徑、確認完好的纜線，以及串流、NIC 和應用程式計數器的日誌。更改任何內容之前，先記錄驅動程式、交換器、MTU、封包大小、幀率和 CPU 負載。

畫出從相機經纜線和交換器到主機網路卡的完整路徑。記錄每一段所支援的 MTU、連線速率、網路卡識別資訊、串流參數、影像尺寸、像素打包方式和已啟用的處理。準備一份執行日誌，寫明預期觸發數、收到的影格 ID、不完整影像數、相機回報的重傳統計、已處理的結果和已儲存的檔案。為每次執行使用專門的執行識別碼，避免計數器重設或接收端重新啟動之後，不相關的幾次執行被悄悄合併在一起。

執行測試

1. 讓一台相機直連主機，採用保守且受支援的封包大小，按 10000 個預期影格的量記錄日誌。
2. 按時間區段對照觸發計數、相機影格 ID、完整接收的影格和已處理的結果。
3. 每次只改變一個變數：纜線、封包大小或封包間延遲；並確認整條路徑上的 MTU 是否相容。
4. 逐步加回交換器和其他相機；再帶著量產時的磁碟寫入和 CPU 負載重複測試。

先在不做檢測處理、不寫入磁碟的情況下接收影像，封包大小採用保守且受支援的值，相機取像設定與出故障的那次執行相同。執行前後各讀取一次計數器，然後把處理和儲存分別加回去。兩次執行之間只改動一項傳輸設定；如果它沒有改善所觀察到的故障，就恢復原先的設定。可重複的改善，比一次偶然乾淨的短時擷取更有說服力。

假設範例表

假設 2048 × 1536 像素的 Mono8 影像以 30 fps 傳輸，需要 94.37 MB/s 的酬載。乙太網路開銷和重傳還要另外佔用頻寬，所以這並不能證明連線餘量充足。

payload_rate = payload_bytes * frames_per_second
2048 * 1536 * 1 * 30 = 94371840 B/s
= 94.37 MB/s = 754.97 Mbit/s (payload only)

範例表只估算影像酬載。協定標頭、封包重傳以及共用連線的其他裝置都會佔用額外的容量，所以酬載低於標稱連線速率，並不能證明餘量充足。使用每像素位元組數之前，先確認所選格式是打包的還是補位的。把預期影格數與後續每一級的計數逐級核對；第一個計數不一致的環節，指明了下一步該查哪裡，但並不會自動證明其根本原因。

測試流程

解讀證據

依分段示意圖，從取像一直讀到結果。如果相機的影格 ID 在遞增、完整的影像卻沒有到達，就要查傳輸和接收端的處理。如果完整影像到達了、卻沒有結果，就檢查佇列的所有權和處理例外。如果有結果、檔案卻缺失，就檢查儲存。計數器和有代表性的日誌都要保留：來自另一個影格的、看起來正確的影像，並不能解釋遺失的那一個影格。

故障排除

• 重傳次數上升且伴隨 NIC 錯誤，提示傳輸方面有問題；檢查纜線和整條連線。
• 完整接收而處理結果缺失，說明佇列或處理已經過載。增加緩衝區也許只能延後溢位，並不能解決吞吐量問題。

只有啟用磁碟寫入之後才出故障，提示主機資源競爭，但應關閉儲存再重複測試來加以確認。封包調大之後接收反而變差，可能暴露了路徑中存在不相容的環節；應逐一檢查每個躍點，而不是不加區分地開啟巨型訊框。增大封包間延遲可以緩解突發壓力，但會拉長傳輸時間。要用實際型號檢查由此得到的吞吐量和取像行為，不要想當然地認為原來的幀率仍能達到。

驗收與交接

要求在約定的整個執行期間（包括尖峰負載下），各級影格數一致，且沒有無法解釋的不完整影像。寫明執行時長和觀察到的重傳次數；一次乾淨的短時執行並不能證明系統在任何情況下都可靠。

將原始檔案、設定、樣品識別碼和判定限值一併歸檔。請參照下方相關的產品指南與準備指南，與 Deyi Vision 討論已有文件記載的需求。

用最終設定重複約定的量產工作負載，包括處理、儲存和其他預期會出現的網路流量。對整個預期執行期間的各級計數逐級核對，並明確記錄所允許的遺失策略。只有在生產安全允許時，才加入受控的接收端重新啟動或纜線復原測試，並驗證不完整的影格是如何被拒絕的。發布設定時，要同時交付網路拓樸、計數器定義，以及證明預期工作負載可持續執行的證據。