【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行 II」
巻頭言 981 「Hyper-Threading──嗚呼、Freeze模様」
Super πとTMPGEncの同時実行テストで思わぬトラブルを招来してしまったが、これが「Dual Xeon 2.20GHz ＋ Tyan Thunder i860 S2603 ＋ Hyper-Threading OFF」によるものかを検証したい。
（ところで前回（昨日）、「場合によっては、午後あたりに加筆するかもしれないが──」としていたが、単に記述するだけならそれも可能だったのだが、今回は帰宅して自宅マシンでの検証を要するために結果としてできなかった。帰宅したのが午前様では、無理というものであったといえようか。）
Super πとTMPGEnc同時実行テストにおいて、4CPU状態でまったく問題が発生しないのに、「/numproc=2」オプションを追加して強制的に 2CPU状態（いずれも物理プロセッサ有効）にすると、Freezeしてしまう。ちなみにこのようなFreezeは、Thunder i860をベースにしたDual Xeonマシンでは、Xeon 1.70GHzを使っていた時まで含めて初めてのことである。それだけ安定度の高かったものが、こうもあっさりFreezeしてしまうということは、単純に考えても強制的に2CPU状態にしたことが原因であるとしか考えられない。
本来なら、BIOS設定で「Jackson Techonogy」をEnabledからDisabledにすればいいのだろうが、以前の巻頭言でもふれたように、BIOS設定での「Jackson Techonogy」をどちらにしても、Windows XPはHyper-Threadingテクノロジを有効にしてしまう。なので、このBIOS設定をEnabledからDisabledに変えても意味はないと思いつつ、念のためということで「Jackson Techonogy」をEnabledからDisabledに設定変更し、かつ「/numproc=2」オプションを追加して2CPU状態で起動した Windows XP Professionalで、再度同時実行テストを行った。しかし、結果は同じようにFreezeしてしまったのである（なお、Super πとTMPGEncのCPU割り当てをそれぞれ独立して与えても、結果は変わらなかった）。
Super πとTMPGEnc同時実行中Freezeした画面写真（擬似的にHyper-ThreadingをOFF）
やはり、Thunder i860のBIOS（バージョン1.04）での「Jackson Technology」設定は、Windows XPにおいては事実上無意味であることが再確認できたに過ぎなかった。それでは、2CPUであることが問題という可能性を消し去るため、Windows XP Home Editionで起動し、Hyper-Threadingを有効にした2CPU状態（物理プロセッサとしては１つ、論理プロセッサとして２つ）で同時実行テストを行った。結果は予想どおり、無事にテストは終了し、実行タイムはSuper π（52万桁）が59秒、TMPGEncが1分47秒という結果となり、Dualプロセッサでの実行タイムとは大幅に遅れたことから、物理プロセッサは１つであることが裏付けられた。厳密に言えば、OS環境が異なっているので、今度はWindows XP Home Editionのboot.ini中に「/numproc=1」と設定することで、強制的に1CPU状態とし、Hyper-ThreadingをOFFにして同時実行テストを行った。これでFreezeすれば、ほぼ間違いなく、Hyper-Threadingがらみの問題となるが、これも予想どおり処理の途中でFreezeした。
以上のことから、次のことがいえるだろう。
『Hyper-Threadingテクノロジが有効にされているXeonプロセッサをTyan Thunder i860（BIOSバージョン1.04）に搭載し、OSにWindows XPをインストールすると、BIOSの設定いかんにかかわらず、常にHyper-Threadingテクノロジは有効になり、OSからは論理プロセッサの総数が認識されるようになる。これに「/numproc」オプションで、OSのサポートするCPU数を減らし、見かけ上物理プロセッサだけを有効にした状態で、Super πとTMPGEncを同時実行すると、処理の途中で常にFreezeする。』
なぜ、Freezeするのか？という根本的な原因は、とにかくエラーログがまったく出力されず、完全なFreeze状態になってしまうため、どういった理由でFreezeしたかはわからない。ICEを利用したり、リモートデバッグを行う等すれば、ある程度原因の取っ掛かりを掴めるかも知れないが、とてもではないがそこまで行う労力は割けない。
とはいいつつも、理由がまったくわからないわけでもない。推測ではあるが、おそらく「/numproc」オプションでCPU数を制限することが、 Hyper-Threadingテクノロジを考慮に入れていないか、またはThunder i860のBIOS設定でHyper-Threadingテクノロジを上手に殺していないための不具合ではないかと思われる。いずれにしても、 Hyper-Threadingテクノロジを下手に制限しない方がいいということだけは間違いないだろう。
聞くところによれば、Hyper-Threadingテクノロジは、システム（BIOS）上の設定でサーバ向けでなければEnableされないという話があるが、私のThunder i860の環境においては、現段階でという条件付きだが、下手にHyper-ThreadingテクノロジをDisableする方が却って不具合が起こるという結果となった。いや、むしろBIOSでDisableにしても、Windows XPがHyper-Threadingテクノロジを有効にしてしまうことが問題かもしれない。いやいや、それ以前の問題として、Windows 2000 Professional上でのSandra 2002の挙動も気にかかる。Windows 2000は、Hyper-Threadingをサポートしていないが、Sandra 2002はおそらくXeonの設定（CPUID）から判断してHyper-Threadingを有効とみなしているので、ソフトウェアの適用によってこのあたりの挙動は左右されるといっていいかもしれない。つまり、Hyper-ThreadingのEnabled/Disabledの判断は、もっともっと根源的なところで行わなければならないのに、私の使用するThunder i860ではそれができていないのではないか、という可能性の問題である。
さて、Hyper-Threadingの総括をそろそろ行う予定だが、それは次回以降とさせていただくつもりである。（2002/1/25）
【当時を思い起こして】
今では液晶ディスプレイは当たり前だが、当時は性能も今一つで解像度も低く、やたらと高価だったので、ノートPC以外での選択肢は私は想定外だった。この画面写真も今はなき、トリニトロンディスプレイである。ブラウン管タイプは、もうほとんど見なくなったなぁ。
コメント