私はイーサネットを介してクライアントサーバー構成を実行しており、両端でパケット遅延を測定しています。クライアント（ウィンドウ）は5ミリ秒ごとにパケットを送信しています（ワイヤーシャークで確認済み）。しかし、サーバー（組み込みLinux）は5ms間隔で数秒間だけパケットを受信し、その時点で300msの間停止します。この休憩の後、待ち時間はわずか20秒です。約数秒後に別の休憩が300ミリ秒かかる。これは無期限に繰り返されます（300msのブレーク、20usのパケットレイテンシバースト）。サーバープログラムが中間バーストでIOを読み取るために最適化されているかのようです。なぜこうなった？なぜUDPパケットの受信は一見実行中に最適化されていますか？
免責事項：クライアントとサーバーが複雑なアプリケーションの小さなサブセットであるため、私はコードを掲載していませんが、明白な回答がそれ自体ではない場合は、それを考慮に入れていきたいと思います。
私は1000パケットごとに1つの測定値の間隔を空けて、今はそれ自体が動作しています。私はprintfを5msごとに使用していました。これにより、実行が300ms遅れました。 printfが息を引いた後、プログラムは受信パケットがいっぱいのキューを持っていたので、一見20パケットごとにパケットを受信していました。
これはUDPなので、ハンドシェイクやフロー制御メカニズムはありません。これらの300ミリ秒は、受信したUDPメッセージの処理中にサーバーが行っている作業のためでなければなりません。これらの300ミリ秒の間に、サーバーはクライアントから読み取られなかった約60個のメッセージを確実に失いました。
処理に1つのスレッドを使用する場合は、各メッセージの処理でサーバーが5ミリ秒以上かかることを確認することをお勧めします。サーバーがマルチスレッドを使用してメッセージを処理し、処理に時間がかかる場合は、たとえ1ミリ秒かかる場合でも、ある時点ですべてのスレッドがリソースを競合し、時間通りに終了しない状況にある可能性があります次のメッセージを読んでください。あなたが記述している問題については、私はそのサーバがマルチスレッドであり、その問題を抱えていると思います。私は情報の不足のために100％を保証することはできません。しかし、どのような場合でも、リアルタイムの要件を処理する可能性があるため、メッセージの処理に要する時間を確認する必要があります。
さらに詳しい情報を提供していないことをお詫び申し上げます。プログラムには2つのスレッドしかなく、もう1つのスレッド（別のudpサーバー）にはデータが供給されていませんでした。また、私の関心のスレッドが行う「処理」は、測定が行われたときにコメントアウトされました。 – Ralph
すべてのパケットが受信されていますか？ – EJP
私はそう信じています。私は明日これを確認することができます。 – Ralph
どのようにレイテンシーを測定しますか？リクエストレスポンスはありますか？あなたは原子時計を持っていますか？データグラムのサイズは？ – rodolk