顧客の 1 人が、ストリーミング アプリケーション (win32) で問題を経験しています。アプリケーションによって一定の間隔 (たとえば 20 ミリ秒) で送信されるべき UDP (RTP) パケットが、実際には大きく変動するデルタ (たとえば 15 ミリ秒 - 25 ミリ秒 - 10 ミリ秒 - 30 ミリ秒) で送信されるようです。これは、この問題が発生した唯一の顧客であるため、ネットワーク カードまたはその他の OS ネットワーク関連インフラストラクチャが主な原因であると考えられます。
問題は、どのようなネットワーク構成がそのような問題を引き起こす可能性があるかです (AV?、QOS?)
また、実際に「送信」関数を呼び出してから、パケットが実際にネットワークに配信されるまでの時間をどのように測定できますか? それに利用できるツールはありますか。
ネットワークの問題がこの問題を引き起こす可能性があると思います。
基本的なUDPにはQoS（サービス品質）の概念はありません（パケットが失われたり、重複したりする可能性さえあります）。ネットワーク カードはネットワークに書き込むためにパケットをキューに入れる必要があり、別のアプリケーションからのパケットをキューに入れているため、配信を保証できません。
ルーターも優先順位を付けることができ、それはこれらのパケットの規則性に影響します。
編集：ローカルNICを指摘したので、上記のre。この状況では、ルーターは適用されません。
要するに、上記が受け入れられないものであると期待する理由はまったくありません。
実際にパケットを生成しているコンピュータの NIC でこれを直接測定している場合 (つまり、すべてのネットワークの影響を無視できる場合)、考えられる原因はコンピュータ自体の負荷です。
コンピューター上で多くのアプリケーションが実行されている場合、特に対話型のアプリケーションや、ユーザーとの対話に大きな偏りがあるアプリケーション (ほとんどのスケジューラから優先される傾向にあります) がある場合、メッセージを作成するアプリケーションが競合するのが難しいと感じる場合があります。必要な時間。
すべての顧客のコンピューターに同じソフトウェアがロードされている場合でも、実際に実行しているアプリケーションとその使用方法が影響を与える可能性があります。
問題は、実際にはウィンドウのタイミング機能でした。実際、Sleep() の解像度は 15 ミリ秒を超える可能性があります。プログラムで1ミリ秒に設定しない限り。したがって、NIC とは何の関係もありません。