Windowsネットワークでの可変待ち時間

Question

私は、24msごとにUDPパケットを送信するPLCを持っています。 「同時に」（すなわち、数十マイクロ秒または何百マイクロ秒であろうと）、同じPLCがカメラをトリガして画像をスナップする。画像とUDPパケットの両方を受信するWindows 8.1システムと、各画像をPLCからのUDPパケットと照合できるアプリケーションが実行されています。

ほとんどの場合、Windowsアプリケーションに関する限り、2つのイベント間では20ms±5msの間に適度な固定レイテンシがあります。しかし時にはレイテンシが上昇し、決して落ちることはありません。結局、それは私が持っているマッチングバッファの範囲を越え、2つのシステムは自分自身をリセットします。それは常に "通常の"レベルの遅延で始まります。

この可変待ち時間の変動性は私には分かりますが、20ms±5msで終日座ってしまうこともありますが、他の日には定期的かつ急速に増加し、システムが往々にして不自然にリセットされます。

ここで何が起こっている可能性がありますか？それを修正するために何ができるのですか？ WindowsはレイテンシやPLCシステムの可能性のあるソースですか？

99％の疑わしいWindowsは、PLCがリアルタイム応答用に設計されており、Windowsはそうではないためです。 Windowsの場合は「通常」と発音されますか？もしそうなら、ネットワークやその他のリソースに対抗する他のプロセスがあっても、競合が発生したときにレイテンシが上がり、競合が停止した後に通常のレイテンシレベルに戻るのはなぜですか？

FYI：WindowsアプリケーションはSetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS)を呼び出し、各重要スレッドはAfxBeginThread(SomeThread, pSomeParam, THREAD_PRIORITY_TIME_CRITICAL)で開始します。可能な限りシステム上で稼動するアプリケーションはほとんどなく、アプリケーションは使用可能なクアッドコアプロセッサ（ハイパースレッディング、したがって8つの有効なプロセッサ）の約5％しか使用しません。私はそれを考慮していますが、SetThreadAffinityMask()の使用はありません。

Answer 1

したがって、UDPを使用して同じPCにデータを送信するPLCとカメラの2つのデバイスがあります。

90％疑わしいネットワーキング。

あなたのスイッチ/ルータのバッファリング/シェーピングの仕組み（ちなみに、あなたの設定が孤立している、つまり、あなたのハードウェアを忙しい企業のネットワークに接続しただけではない） PLC内のいくつかのカスタム再送メカニズムを使用することができます。 IPとイーサネットの両方のプロトコルは、低レイテンシを保証するものではありませんでした。

確認するには、Wiresharkを使用してネットワークトラフィックを表示します。

最高の実験のために、3枚のネットワークカードを備えた別のPCを使用できます。

3台のデバイス（Windowsクライアント、PLC、カメラ）をそのPCに接続し、network bridge between the 3 cardsを設定します。これにより、2台目のPCがイーサネットスイッチとして機能し、Wiresharkを使用してネットワークトラフィックをすべて捕捉できます。

Answer 2

答えは、複数の要素間の複雑な相互作用であることが判明しました。そのほとんどは、他の人に有用な情報を伝えません。「単に12ヶ月間うまく動作していないすべてが実際にOKだったと仮定するライセンスを与えない

重要な点は、PLCが複数のI/Oモジュールが接続されたBeckhoffのデバイスであることでした。これらのモジュールが増えれば増えるほど、プロセッサ時間とネットワーク帯域幅が十分にあるにもかかわらず、PLCがUDPパケットを送信する能力が低下することが判明しました。これは、我々が解決していない何らかの種類のリソース競合問題のように見えます。より強力なPLCデバイスにアップグレードすることを選択しました。そのデバイスには依然として同じ問題がありますが、約24msではなく約10msごとに送信しようとすると問題が発生します。

私たちのPLCアプリケーションがUDP送信機能のしきい値で正しく動作していたため、問題が発生しました。 PLCは、送信を行うためにステートマシン内の状態を進める必要があります。 PLCサイクルが2msの場合、接続されたI/Oモジュールを備えたステートマシンの状態を一番速く通過することができたのは22msごとでした。

最後に、PLCの起動時に重要で無関係な変更であると思われるものは、それを端に突き刺し、時折、通常の24ms送信サイクルに追いつくことができませんでした。だから、徐々に後退し、待ち時間がますます増えるでしょう。

私はいくつかのWiresharkのキャプチャの慎重な分析が何が起こっていたのロックを解除するためのキーだったので、@スンツの答えを受け入れています。