(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第４３０回］
●ＨＩＤ送信速度の怪
前回、ＷｒｉｔｅＦｉｌｅとＲｅａｄＦｉｌｅをペアにして、６４バイトのデータを１００００回送受信して、それにかかった時間を測定したところ、約２４秒かかりました、という説明をいたしました。
１回の送受信データは６４バイト×２＝１２８バイトですから、１００００回の繰り返しによって送受信したデータは１２８００００バイトです。
それを２４秒で行ったのですから、１２８００００／２４＝５３３３３バイト、約５３ＫＢ／秒の通信速度である、という結果が得られました。
ＨＩＤのインタラプト転送での最高通信速度は６４ＫＢ／秒ですから、その８割強というパフォーマンスです。
しかし、この数字には、じつはウラがあります、というところまでが、前回のお話でした。
どういうウラなのか、それを説明するために、前回行ったテストプログラムを少し変更して、もう一度実行してみることにします。
どう変更するか、といいますと、前回は最初にＷｒｉｔｅＦｉｌｅを、続いてＲｅａｄＦｉｌｅを実行するという、Ｗｒｉｔｅ／Ｒｅａｄのペアを１００００回繰り返しましたが、今回はＲｅａｄＦｉｌｅは行わず、ＷｒｉｔｅＦｉｌｅのみ１００００回実行するようにしたのです。
ＷｒｉｔｅＦｉｌｅもＲｅａｄＦｉｌｅも１回の実行でどちらも６４バイトを送っていたところを、ＷｒｉｔｅＦｉｌｅのみ６４バイトを送り、ＲｅａｄＦｉｌｅは実行しないように変更したのですから、トータルの総通信バイト数は前回の半分になります。
ということは、そのＷｒｉｔｅＦｉｌｅのみの１００００回の実行時間は、前回の半分、約１２秒であることが予想されます。
ところが、ところが、実際に実行してみると、意外な結果になってしまうのです。
画面右のＤＯＳ窓が、その実行結果です。
比較のために、先に前回実行したｈｉｄｔｅｓｔ２ｆ．ｅｘｅを実行してから、今回のｈｉｄｔｅｓｔ２ｇ．ｅｘｅを実行してみました。
ｈｉｄｔｅｓｔ２ｆ．ｅｘｅは、ＷｒｉｔｅＦｉｌｅとＲｅａｄｆｉｌｅを各１００００回実行しますが、ｈｉｄｔｅｓｔ２ｇ．ｅｘｅはＷｒｉｔｅＦｉｌｅだけを１００００回実行します。
ｈｉｄｔｅｓｔ２ｆ．ｅｘｅは前回は２４秒でしたが今回は２３秒です。どういうわけか今回は１秒短縮されています（このあたりもなんだか怪しいなあ、という感じがしますねえ）。
で、肝心の、ｈｉｄｔｅｓｔ２ｇ．ｅｘｅの結果なのですが、なんと予測を大きくはずれて、２０秒もかかってしまいました。
これって、どういうこと？
●ＨＩＤの意外な振舞い
３．１からはじまったＷｉｎｄｏｗｓも９５、９８、ＸＰ、ＶＩＳＴＡと続き、今またＷｉｎｄｏｗｓ７がリリースされました。
その昔と比べれば、ハードもソフトも飛躍的な進歩を遂げた、はずなのですが…。
失ってしまったものもまた大きい、と思います。
上で説明したような状況に直面してしまうと、もうさすがのＷｉｎｄｏｗｓもアウトです。
これ以上はなんともなりませぬ。
この局面を打開するには、原始的なレベルでの操作が必要になってきます。
ハードの技術、知識を伴わない、高級言語オンリーの「開発担当者」は、ここで完全にリタイアせざるを得なくなります。
ハードやマシン語レベルの知識、技術を有するものだけが、この先に進むことができます。
ここは、ＰＩＣ１８Ｆ４５５０の側からのアプローチが有効なようです。
まずは、ＨＩＤクラスの意外な振舞いを知るための細工をＰＩＣに施します。
といっても、おまじないをしよう、というわけではありません。
ＰＩＣ１８Ｆ４５５０に対して、ホストからＩＮトランザクションの開始信号（ＩＮトークン）が送られてきたら、特定のポートからＨパルスを出力する、というプログラムを仕込んだのです。
すると、こういう結果になりました。
画面がちょっと傾いてしまいました。
きっちり１ｍｓごとにパルスが出力されています。
それが、一体どうしたというの？
実は、ＰＩＣ１８Ｆ４５５０をＵＳＢケーブルに接続しただけで、まだホストは何もプログラムは実行していないのです。
つまり、アプリケーションの側からは、何もまだＰＩＣに要求していませんし、データの送信も受信も行っていないのです。
もちろんＷｒｉｔｅＦｉｌｅもＲｅａｄＦｉｌｅもまだ実行されてはいません。
それなのに、ＵＳＢケーブルに接続したＰＩＣ１８Ｆ４５５０がＨＩＤデバイスとして認識された直後から、１ｍｓ間隔で、ホストからは、ＩＮトランザクション（ＰＩＣからホストへのデータ送信）の開始要求（ＩＮトークン）が連続して送られるのです。
どうもこのあたりに、ＲｅａｄＦｉｌｅがうまく実行できなかったカギがあるようです。
つまりＨＩＤでは、たとえばインタラプト転送でトランザクションの実行間隔（インターバル）を１ｍｓに設定すると（その設定の方法については、いずれ説明をするつもりです）、実際にＲｅａｄＦｉｌｅを実行する、しないにかかわらず、１ｍｓ間隔で、デバイスに対してＩＮトランザクションが発行される（デバイスに、データを送れという要求、ＩＮトークンパケットが、ホストから送られる）、らしいのです。
では、そのことが、さきほどの、ＷｒｉｔｅＦｉｌｅ、ＲｅａｄＦｉｌｅの実行時間と、ＷｒｉｔｅＦｉｌｅのみの実行時間との食い違いに、どのように関係してくるのでしょうか？
ＷｅｂにはＵＳＢについて解説しているサイトもそこそこありますし、ＨＩＤについてのサイトはそれほど多くはありませんが、それもまあ、そこそこはあるようです。
しかし、こういう切り口でＨＩＤにせまる、というサイトはほかにはないように思うのですが、いかがでしょうか？
目からウロコ、をご体験いただけますでしょうか？
話をもとに戻します。
そのあたりのことを、もう少しあきらかにするために、今度は、ホストからデータの送信を受けるたびに、ポートの出力をインクリメントするようにしておいて、ホストがＷｒｉｔｅＦｉｌｅを連続で実行して、つまりホストからＰＩＣに対して連続でデータを送信するようにしてみました。
このＰＩＣのプログラムは［第４２２回］で使ったのと同じものです。
ＰＩＣは受信するたびにＰＯＲＴＣの出力をインクリメント（＋１）します。
そしてそのＰＯＲＴＣ出力の下位２ビットをオシロで観測したのが下の写真です。
上側（ＣＨ１）がＰＯＲＴＣのビット０（ＲＣ０）で下側がビット１（ＲＣ１）です。
ホストからデータは１ｍｓごとに送られているはず、なのですが、実際にはＰＯＲＴＣの出力は、２ｍｓごとに変化しています。
なぜなのでしょうか？
そこで、さきほどお見せした写真が利いてくるのです。
つまり、ＨＩＤでは、ホストがアプリケーションでＲｅａｄＦｉｌｅを実行していなくても、１ｍｓごとにＩＮトランザクションが「勝手に」実行されてしまうのです。
そして、そこにＷｒｉｔｅＦｉｌｅがやはり１ｍｓごとに実行されるために、ＯＵＴトランザクションと（ダミーの）ＩＮトランザクションが交互に実行される形になるため、写真のように、１回のホストからのデータを受信するのに２ｍｓかかってしまう、のだと考えられます。
このことは、最初にお見せした、Ｃ＋＋プログラムでのＷｒｉｔｅＦｉｌｅのみの１００００回の実行結果が２０秒であったこととぴったり一致します。
ところで、どうせならば、フレームはがら空き状態のはずなので、同じ１ｍｓのフレームにＯＵＴトランザクションとＩＮトランザクションをいっしょにのっけてくれれば、ＯＵＴとＩＮをあわせて１ｍｓで済んでしまうはずなのに、と思うのですが、そこが、どうも［第４２７回］でご説明しましたように、「ホストコントローラ様の勝手だよん」のようです。
さて、ではＷｒｉｔｅＦｉｌｅとＲｅａｄＦｉｌｅを実行したときの、ＰＯＲＴＣの出力はどのようになるでしょうか。
今度は、２ｍｓと３ｍｓが交互にあらわれているようです。
ホストの側のプログラムは、ＷｒｉｔｅＦｉｌｅとＲｅａｄＦｉｌｅを交互に実行していますから、ＯＵＴトランザクションとＩＮトランザクションも交互に実行される、と思うのですけれど、そこにときどきダミーのＩＮトランザクションが入り込むのではないか、と推測しています。
というか、うまくダミーのＩＮトランザクションのタイミングとＲｅａｄＦｉｌｅの実行により発行されるＩＮトランザクションのタイミングが合うときと、それがずれて両方のＩＮトランザクションが発行されてしまうときが、ちょうど交互に出現しているように思われます。
写真の波形から、ＯＵＴ２回の実行時間が５ｍｓですから、（この間にＩＮも２回実行されているはずなので）、ＷｒｉｔｅＦｉｌｅとＲｅａｄＦｉｌｅを合わせた一回の実行時間は平均２．５ｍｓということになります。
これは、前回おこなったテストの１００００回の実行結果の２４秒を裏付けるものといえるでしょう。
また、同じプログラムを実行したのに、今回は２３秒であった、ということも、上で説明しましたように、ダミーのＩＮトランザクションとＲｅａｄＦｉｌｅの実行によるＩＮトランザクションの重なり具合に、パソコン内の資源状態からくる「ゆらぎ」がからんでいる、と考えると納得できる、のではないかと思います。
２０１０．２．４ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る