NIC不一致的數據包傳輸，NIC性能測量

我們的客戶之一遇到流應用程序（win32）的問題。看起來UDP（RTP）數據包應該由應用程序以某個恆定的時間間隔（比如說20ms）發送，實際上它們的變化量很大（例如15ms - 25ms - 10ms - 30ms）。這是遇到問題的唯一客戶，因此網卡或其他與操作系統網絡相關的基礎設施是我們的主要嫌疑人。NIC不一致的數據包傳輸，NIC性能測量

的問題是，什麼樣的網絡配置可能會推出這樣的問題（AV？，QOS？）

我怎樣才能衡量之間的實際調用「發送」功能，並在文實際交付的那一刻時間網絡？有沒有可用的工具。

來源

2010-01-21 Boris

夥計們，問題實際上是windows的計時函數，事實證明，Sleep（）的分辨率可能超過15毫秒。除非你以編程方式將其設置爲1ms。所以沒有關係到NIC如此。

來源

2010-06-27 12:56:47 Boris

我懷疑任何網絡問題可能會導致此問題。

基本的UDP沒有QoS（服務質量）的概念（甚至可以丟失數據包，有重複等）。您的網卡必須排隊數據包才能寫入網絡，因此您無法保證交付，因爲它正在排隊來自不同應用程序的數據包。

路由器也可以確定優先級，這將影響這些數據包的規律性。

編輯：你已經指出了本地NIC，所以上面的重新。路由器不適用於這種情況。

簡而言之，沒有任何理由可以期望上述內容是可以接受的。

來源

2010-01-21 18:12:57

這是遇到問題的唯一客戶。沒有人談論完美的時間安排，但與這位客戶的數據包發送時間的差異超出了通常觀察到的範圍 – Boris 2010-01-22 07:04:32

注意我們正在討論捕獲本地NIC，因此不涉及路由器或網絡問題。 – Boris 2010-01-22 07:05:45

如果你是說你直接在計算機的網卡上測量實際產生數據包（即可以打折所有的網絡影響），那麼可能的原因是計算機本身的負載。

如果計算機上運行着許多應用程序，尤其是交互式應用程序和具有強烈用戶交互偏好（大多數調度程序會優先考慮）的應用程序，那麼您可能會發現創建消息的應用程序只是簡單地找到它很難爭取所需的時間。

即使您的所有客戶計算機都加載了相同的軟件，他們實際運行的應用程序以及他們在做什麼可能會產生影響。

來源

2010-06-22 11:01:20 Mick

NIC不一致的數據包傳輸，NIC性能測量

回答

相關問題