2

ハードウェア (データ転送デバイス) に特定のバッファー サイズを供給するプロセスがあります。バッファ アンダーフローが発生しないようにするために、Windows スケジューラ ウィンドウに期待できることは何ですか?

私のバッファのサイズは 32K で、1 秒あたり最大 800k バイト消費されます。

20ms ごとに 1 つのバッチである 16k バイトのバッチで入力するとします。ただし、それを埋めるための下限は何ですか。たとえば、充填ループで sleep(0) を呼び出した場合、合理的な最悪の場合のスケジューリング間隔はどれくらいですか?

OS = Windows XP SP3 デュアルコア 2.2Ghz

バッファ フィル レベルをチェックするための API 呼び出しと、データを渡すためのドライバ API への呼び出しを行っていることに注意してください。これらは、Windows が sleep(0) に加えて利用できるスケジューリング ポイントであると想定しています。

私は（プロセスとして）うまくプレイし、それでもリアルタイムの締め切りに間に合いたいと思っています. マシンはこのタスク専用ですが、ネットワーク経由でデータを受信し、IO デバイスに送信する必要があります。

スケジューラのパフォーマンスについて期待できることは何ですか? 他に何を考慮する必要がありますか。

4

2 に答える 2

3

Windows でのプロセスの最小保証時間は?

保証はありません。Windows はリアルタイム O/S ではありません。

他に何を考慮する必要がありますか

  • マシン上で他に何が実行されているか (優先度の高い何かがあなたを先取りする可能性があります)
  • RAM の容量 (RAM が不足すると、システムのパフォーマンスが大幅に変化します)
  • ドン I/O であるかどうか (たとえば、ディスクまたはネットワーク アクセスの待機中にストールする可能性があるため)

私は（プロセスとして）うまくプレイし、それでもリアルタイムの締め切りに間に合いたいと思っています. マシンはこのタスク専用ですが、ネットワーク経由でデータを受信し、IO デバイスに送信する必要があります。

プロセスやスレッドの優先度を「リアルタイム優先度」に設定することを検討してください。

于 2010-08-24T16:04:18.580 に答える
3

保証された最悪のケースはありません。何百ミリ秒も CPU を失う可能性は十分にあります。カーネルスレッドが何をしているかに左右されます。それらは常に、これまでに得られたよりも高い優先度で実行されます。不適切な動作をする NIC、USB、またはオーディオ ドライバーに遭遇することは、あなたが絶えず戦っている問題です。ハードウェアを制御できない限り。

時折のアンダーランに耐えることができる場合は、デバイス データを取得するために使用する I/O 要求が待機可能なイベントであることを確認してください。Windows は、他のすべての要求よりも先に完了した I/O 要求でブロックしているスレッドをスケジュールすることを好みます。Sleep() を使用したポーリングは、適切な戦略ではありません。不必要に CPU サイクルを消費し、スケジューラはスレッドをまったく優先しません。

アンダーランに耐えられない場合は、デバイス ドライバーを検討する必要があります。

于 2010-08-24T16:07:00.607 に答える