bin-bowスパコンの製作日記

　

この日記は研究調査の覚え書きだ。信用して失敗しても関知しない。だが、「ここんところは、こうだ」と知っているなら教えてくれ、いや、教えて下さい。

型落ちで捨てられていたWin マシンを拾ってきてあったのだ。しみったれているが仕方がない。Pentium-II, 80 MHzで、CPUクーラも止まりがちだ。Unix users のVine-linuxを入れた。以前のlinux ディストリビューションはVideo カードの設定がネックだったので大きなディスプレイを使えなかったのだ。Matrox-G200をサポートしているので使ってやったのだ。

Unix users はモジュールに問題多し、の声があるのでRed Hat 5.2 も注文しておいた。BIOS が古くてCD-ROM ブーツができなかったのでブーツフロッピを作らなきゃならん。手持ちのDOSではCD-ROMを認識できなかったのでドライバを入れた。ドライバを入れたら、DOSが古いせいかMSなんたらモジュールがないとインストールできないと言ってきた。箱をあさってDOS6.xを探して、そのなんたらモジュールを入れたらCD-ROMを認識した。それからブーツフロッピのイメージを探してダンプした。面倒なり（後でこのフロッピーを別の用途に使ったらまた必要になって同じ手順を二度繰り返したぞ。間抜けだ。）。

廃棄されるというHPのワークステーションから取り分けおいた21インチディスプレイが役立つ時がやってきた（さらに旧いHPのディスプレイはRGB入力だけのGシンクだ。MIRAGE Z-128というカードがこの旧い、Gシンクのディスプレイを使えるというので、わざわざ輸入したことがある。ちゃんと働いたんだが不安定で、いじり回しているうちにリセットできなくなってしまい、これはゴミ箱行きにした）。

元々ついていたS3カードではうまく行かなかったのが、Matrox-G200にしたらすんなり動いたぞ。ついでに余っていたISA SCSI カードがあったので差し込んでこれも廃棄した計算機から外してあったIBM の4G ドライブを二つくっつけた。ワシはMac使いなのでサーバにできるか確かめるつもりだ。今はWin NT 3.x サーバをMacのために奉仕させているのだ。NTは2.xから3.xにする時MSが差分のディスクしか出さなかったので、もう使ってやらないことにしている。でも世の中にはNTがイイという人もいるから、好きずきと言うしかない。

実はこのマシンには最初、BeOS-R4を入れたのだ。Matrox-G200はこのBeがサポートしている少ないビデオカードの一つだったので買っておいたのだ（OPEN-GLアクセラレータとして使えないと文句を言ったやつがいたそうだ）。さて前回にも書いたように、SCSIの設定をするんだった。その前にDOSでフォーマットしなきゃならん。AHA1542は自動的に自分のドライバをBIOSにくっつけたので何もしなくてもすんなりいった。

後でRAIDにすることも考えて4Gドライブを二つ入れることにしたのだが、ATマシンの市販ケースと言うのはどれもこれも帯に短したすきに長し、を地でいっている。入りそうで入らない、変なところがすきまだらけ、なのはどうしたわけだ。ドライブが旧くてフルハイトのせいもあり入らない。ケースの5インチ用のところに縦にして置いた（おい、ケースを横にすると落ちるぞ）。neta-talkの設定は殆どなにもせずにうまくいって、Macから使えるようになった。AppleShareのIPバージョンもちゃんとサポートしている。いいぞ。

[top]

注文してあったRedHat5.2が来たのでVineと入れ替えた（アップグレードにした）。Xの設定をしたとことろ、なんたらSIGで途中からエラーが起きてWindowMakerが表示されないぞ。面倒くさいから、最初からインストールしたらうまくいったぞ。

[top]

はまってしまったぞ。ワシの考えているスパコンはディスクレスのクラスタでできたネットワークが主になるから、これをインターネット側と切り離すために、当然ゲイトウェイを作らなきゃならん。そこでetherの2枚差しが必要だ。手持ちのカードはISAの3C509B、ISAのNE2000コンパチ、昔のSMC-Elite、それに新しく買った3C905だ。3C905は100Baseをサポートしているから一応フロントエンドに置くとして、ISAのカードを入れるのだがどいつもこいつも動かん。片方が動いても（Pingを打ったら答えても）、片方は動かない（Pingが返ってこない）。/etc/conf.modulesにIRQとbase-addressをいろいろ変えて書いたり、BIOS設定を変えてもだめだ。ISAの２枚ならばと代えてもやっぱりだめだった。

3C905がおかしいのかと注文してあったW-5HUBC+LAN（4ポートハブ内蔵10Base-T LANカードだ。ハブが別になくても、カード自体にハブの機能があるのだ。すごいだろ（本当か）。話が前後するが、このカードはRealTek RTL8029を使っている。さてどのドライバを使えばよいのでしょうかーne2kpciが正解）に代えても同じだった。すったもんだのあげく（どこも吸ってないぞ（本当は擦ったなのだが））PCIカードを２枚（3C905とこの４ポート内蔵カード）を使うのが答えだった。長かった。ISAの２枚ざしならうまくいったという話があるので、PCIとISAを混ぜるのはよくないかも知れない（考えれば当たり前か。旧いISAカードを後生大事に持っていたワシが貧乏くさかったか）。

[top]

etherが２枚使えるようになったのでIP-Masqueradeを試してみたぞ。RedHatは今や色んなサーバがだまっていても入っているから楽だ。GUIの設定サービスもあるから至れりつくせりだぞ。ここで少しまた、はまった。グローバルの方のカードにIPのフォワードを許す設定を見落としたのだ。

[top]

勢いでDHCPも設定した。２枚差しのetherの場合、グローバルの方のサブネットについても中身はなしでconfigファイルに設定しておくのがコツだ。昔は大変だったぞ。Webはないしマニュアルは不備だったし、第一、Xの設定に間違うとリセットするしか手がなかったのじゃ。

[top]

さてクラスタをディスクレスブートさせるためにはブートの仕掛けを用意しなくてはならん。普通はether カードのPROMソケットにPROMを用意して差し込むんだが、PROMイメージをBIOSに書き加える方法もあるようだ。初めにカードにPROMを準備することを考えた。ソフトを探してROMライターで書き込むのは考えただけでも面倒なので買うことを考えると、ブート関連ソフトのメーカがあった。殆どのカードをサポートしているようだし、DHCP/BOOTPの両方が使えるようなことを書いてある。先々、クラスタノードのホットスワップもしたいな（できればだ）、のことを考えると、一々、MACアドレスとIPを指定するBOOTPよりDHCPを使いたい。ところが、よく調べてみるとこのメーカのROMでDHCPをサポートするのはごく一部のカードであることがわかってきた。

残念ながら、BIOSに書き込むことができて、今のところ一番入手が簡単で使い易いと思われる、Network Boot Kit はBOOTPしかサポートしていないようだ。ということで、今度はBOOTPサーバのインストールにあいなった。

BOOTPサーバとTFTPサーバはRedHatのCDROMにRPMで書いてあるので簡単にインストールできた。少しはまったのは/etc/bootptab の書き方だ。クライアントのIPパラメータについてmanでは「ホストのIP」と説明してある。おまけにDNSサーバ設定パラメータもあってよくわからんぞ。この辺りはHPの「HP-UX10.0 InterNet サービスのインストール／管理ガイド」の方が親切だったぞ。ちゃんと「ipタグは、BOOTPクライアントのIPアドレス」と書いてあるぞ。

というわけでBOOTPサービスは動いたのだが、etherカード２枚差しの場合、bootptabにはサーバホストを設定する（etherカードを指示する）タグが見つからない。だからワシの場合ether0をサーバホストとして認識する。ether1を指定するにはどうしたらよいのじゃ。

[top]

クラスタノード（ディスクレスlinux）のブートには、できればBIOSの変更だけで対処したい。Award のCBROM.EXE（BIOS ROM combination Utility)が使えそうだ、ということでVer.1.11のドキュメントを読んだら、気になる記述がある。「You can combine other ROMS ... For example, ... LAN card boot ROM」とここまではいいのだが、「NOTE: This function requires specially modified source code. Contact Award ....」これはどうもまずい気がする。

もしかしたらワンボードコンピュータメーカーにだけ出している、つまりワンボードコンピュータの付属ユーティリティでなくては、BIOSへのブートデータの書き込みはできないかも、知れない。そうだとすると別手段としてLANカード用にROMライタを準備しなければならない（秋月通商で売ってるぞ）。BIOS書き込みだけなら、BIOSのROMバックアップ専用のハードが出たばかりなので、調子よく行くかなと予想していなのに。なかなか面倒なことになってくるなコリャ。

[top]

しばらくlinuxから離れていたな。他の仕事だってあるのだ。

というわけでNetBootに戻るのだが、少し問題が起きた。サーバに置いておくカーネルイメージにはNICドライバが必要なのはもちろんなのだが、このドライバはモジュールではなく最初からカーネルに組み込まなきゃならない（そりゃそうだろうそれで？）、で組み込み用のNICドライバは最新のイーサカードに必ずしも対応していないようなのだ。おまけに、クライアント側のイーサカードのIRQやらIOアドレスも設定しなきゃならないようだ（まだ詳しく調べていないのだがEtherBootならこのあたりのドライバは改善されているようだ）。

クライアントのクラスタを作るのが最終目的だから、フロッピーからブートするミニマルシステムにした方がいいかも知れない。'The Linux Bootdisk HOWTO' や、UNIXマガジン（99年3月号）にもあったが、こんなのもあったぞ。ここらあたりで両者を比較してみよう。

	ネットワークブート	フロッピーシステム
初期設定の手順	1. bootp設定 2. tftp設定 3. nfs設定 4. クライアントNICのMACアドレス取得 5. bootptab設定 6. クライアントNICのIRQ設定 7. クライアントのカーネルイメージ作成 8. NetBootもしくはEtherBootのROMへの焼き込み	1. DHCP設定 2. nfs設定 3. クライアントフロッピー作成
クライアント増設の手順	上記4から8の繰り返し	上記3の繰り返し
ハードウェア的なpros & cons	pros ・適切なボード、NTXフィギュア、などを選べば、マザーボード１枚で済む cons ・ROMへの焼き込みまで考えるとボードの選択範囲が狭まる	pros ・一般的なボードが自由に選べる cons ・フロッピードライブを取り付ける必要がある ・電源ラインが余分に必要となる
ソフトウェア的なpros & cons	pros cons ・ボードを増設する度にボード固有の情報を取得し、サーバに設定しなければならない	pros ・ボードの増設はハードだけを考えていればよいので、クライアントのソフト的な一様性が高い cons

こうしてみるとネットワークブートの方が、ハードウェア的にはスマートだな。格好いいのが（最終的には）作れるぞ。だが、現実的に色々なボードをクライアントに使うことを考えると、フロッピーをベースにしたシステムの方が運用の簡単さ、セットアップの単純さを考えると妥当だな。方針を変更した方がいいかも知れん。この間、音楽配信のためにPCベースのlinuxを２千台も集めてクラスタにした、という記事をどこかで見たぞ（雑誌だったか？Webでサーチしたが見つからなかった）。このシステムがやはりフロッピーでブートするようになっていたな。

つまりだな、最終目標がある時、色々な達成手段がある。最右翼に来るのがカスタマイズしたハードウェアだ（例えば、line-by-line 計算をDSPで実現する場合だ。一般にDSPは32bit精度だから、計算に必要と考えられる倍精度演算をソフト的に実行するか、あるいは元のアルゴリズムが32bit精度で十分かどうかは検討する必要がある）。次がワンボード式のクライアント方式だ（これだって特注すればいけるぞ。昔に比べて安くできるかも知れん）。一番チープなのはボックスを買ってきて揃えることだな。ただし、DSPを使った場合を除けば、残るのは格好の良さとスペースだけの問題になる。つまり選択肢は、DSPとそれ以外で質的なジャンプがある。DSPを除けば、残りはほぼ連続的にまた少しずつオーバーラップした選択肢に過ぎん。こう考えると、ネットワークブートにするかどうかは運用の手間と格好良さについてのみのトレードオフになるな。

[top]

前のフロッピーブートの話しは少し不十分なところがあったな。フロッピーブートと言っても、(A）ブートしてサーバからルートファイルを含めて全部持ってくるものと、(B）フロッピー単独でlinuxが動作してファイルシステムはメモリディスクに展開されるもの、に分けられる。また(B）においてはnfs可能なものもあり、もともと、ルーターやら、レスキューディスクのためのものらしい。

よく分からないのは、（A）のタイプでramdisk を使うものがないのかどうかだ。nfsだけでは速度的に問題があるんじゃなかろうか。ただし(A）はnetboot とetherboot しかないようなので、もともと開発したときのアイデアがROMだけでブートするのだが、そのテストのため、フロッピーイメージにすることもできる、というものらしい。わしの考えているものと違うのかもしれん。

[top]

しばらく間が空いてしまった。また読み返さないと大分忘れているぞ（海馬の老化かもしれん。側頭葉だったか？）。本当はここらあたりから、外注に頼もうと思っていたのに、予算がないので、やっぱり自分で少しずつ始めることにしたぞ。

実はパラレル計算については、昨年度、といっても今年の春だが、ある程度進んでいる。ALPHA を6台、スイッチで繋いでプロトタイプを作ったのだ。メッセージパッシングにMPI（Message Passing Ingerface） を実装したMPICH を使っている。このプロトタイプで計算機台数とターゲットにしているプログラムの処理能力がほぼ比例することは確かめてある。勿論、アルゴリズムがパラレル計算に合致しているからだ。何でも速くなるってことはないぞ。

[top]

どういうタイプのディスクレスにしようとも、RAMDISKは必要だ。調べると〜、まず　mknod でデバイスを作るんだな。/dev/ramdisk みたいな名前だ。それからファイルシステムを作る。mke2fs -xxと言う具合だ。そしてマウントする。mount -t ext2 xxx という風にだな。で、サイズは/etc/lilo.conf にRAMDISK_SIZE=nnn とする、RAMDISKはスワップにも使えるらしい。mkswap xdevice , swapon xdevice だな。

ところでブーツはどんな風に始まるんだったか。LILO がRAMDISK を作って、compress されたイメージをフロッピから転送して、uncompress するんだったな。確か、compress されてないイメージでも転送できた筈だ。とすると、LILO がmk2fs とmount するんだったか？また、これから調べ直しだな。んと、RAMDISK については/usr/src/linux/Documentation/ramdisk.txt にあると書いてある。

読み進むと、bootプロセスについては、フロッピの場合、BIOS はLILO あるいはカーネルイメージを読み込んでロードすることができると書いてあるぞ。でカーネルが読み込まれた後、カーネルはルートファイルシステムがどこにあるか、知らされなきゃいかんとある。

ブートフロッピーを作る過程で、あれこれするらしいぞ。まずカーネルをフロッピーに書いた後に、rdev でフロッピーをルートデバイスにする、とある。ramdisk のセットアップについては、カーネルイメージの中のramdisk word の0-10 bitでカーネルのメモリ上の最後の部分のオフセットをramdisk の始まりの場所にするとある。bit14はルートファイルシステムをramdiskにロードすることを指示する。で、このramdisk word はredev -r でセットする、とあるな。で、ルートファイルそのものはフロッピーの、カーネルに続くブロックに書き込むようだ。

そうすると、nfs でルートをマウントするにはどうしたらいいんだろうか？というのも、フロッピーにルートfs を書き込むのはサイズ的に苦しいだろうし、DHCP なんかを使うとなるとカーネルが大きくなると思うからだ。だが、ネットワーク関係はルートがマウントされてからセットアップされるんだったな。さて？？？

[top]

Netboot パッケージをインストールするとmkbi-linuux というコマンドが利用できて、これで、ルートファイルシステムをnfs マウント、したり、ramdisk を使ったりできるらしい。例えばnfs ルートファイルシステムを使うブートイメージを作成するには、
mknbi-linux -d rom -i rom -k zimage -o bootimage
とする。この時、nfs を使うためにサーバーのbootpd テーブルに、クライアントのアドレスと一緒に、rp タグでエクスポートするルートファイルシステムを明示すればよいのだ。で、さらに、サーバーに置いておく、ルートファイルシステムがramdisk にできるようなブートイメージを作るには、
mknbi-linux -d ram -i rom -r ramImage.gz -k zimage -o bootimage
とするらしい、ここでramimage.gz はramdisk 上のルートファイルシステムをgzip したものだ。ここで、この前の問題の答えが分かった。このルートファイルシステムのinit でnfs を利用すればよいのだ。話が面倒だからまた、取りまとめておこう。

1.　netboot するためのbootimage をmknbi-linux コマンドで作る。この時、ルートファイルシステムをramdisk におくか、nfs マウントするかを選べる。
2.　bootptab にbootimage のパス、MAC アドレス、IP アドレス等を書き込む。
3.　make bootrom でクライアントのためのブートカーネルを作る。この時、NIC のドライバがパッケージに含まれていない場合、フルパスを与えるだけで好きなドライバが選べる、となっている。このブートカーネルは16KBのサイズにおさまるが、フロッピーを使うつもりなら、ディスプレイドライバなんぞをつけることも可能なようだ。

[top]

今までの話しはBootPrompt Howto に書いてあった。ルートファイルシステムがどこにあるとか、ramdisk をどう使うか、はカーネルイメージの中にカーネルのブート引数として書かれてあって、rdev がこれを書き換えることができるのだ。またnfs についても'nfsroot=" 引数と'nfsaddrs=' 引数が用意されている。で、nfsroot 引数が与えられていると、nfsaddrs 引数がなくともカーネルがRARP と、BOOTP を使ってサーバーのIP を取得するのだ。ところで、BOOTP とRARP とDHCP の関係はどうなっていたんだろうか。まずRARP サーバーはカーネルを再構築する時、.config でCONFIG_INET_RARP=y でサポートされるようだ。RARP ではIP がわかるだけでサブネットマスクなんかが分からないので、BOOTP がその替わりをするのだが、ブートの説明では、rarp and/or bootp なんて曖昧に書いてあるな。rarp の意味をもう一度調べる時なんぞはASCIIのグロッサリーサービスが便利だ。

さてBOOTP とDHCP の関係だがRFC1541 にはDHCP サーバーはBOOTP クライアントの面倒を見なきゃならんと書いてあるらしいのだが、それ以上ではない。結局のところ、linux カーネルとしては、DHCP のクライアント部分はもっていないようだ。だからネットワークブートするためには必ずBOOTP を使わなきゃならない。つまり、MACアドレスがNIC のどこかに書かれていなければ（調べたらアドレスのシールを貼ってあるのとないのとがあるな）、ディスクレスクラスタのノードをオフザシェルフで使うことはできない、ということだ。将来のノードのホットスワップまで考えると（BOOTPtab をノードの入れ替えのために書き換えなきゃならんからな）、linuxカーネルがDHCPcd を持っていない限り、フロッピーで立ち上げる方が簡単だ。話が元に戻ったな。

そこで次の方針にする。
1. フロッピーブートとする。
2. ルートファイルシステムとramdisk もフロッピーに組み込む。
3. ルートファイルシステムはramdisk に置く。
4. DHCP によりネットワークを設定する。
5. フロッピーに入り切らないファイルはnfs マウントする（あるいは、ルートファイルシステムを改めてnfs マウントする）。
6. スワップもramdisk に置く（スワップを作らないというのは可能なんだろうか？）。

[top]

ここでちょいと別の事も考えてみた。ノードのクラスタはどのくらいの値段でできるだろうか。浮動小数点計算の速度からみると、Pen3とCeleron はあまり変わらない。Celeron にはL2キャッシュがない？ことと、マザーボードのシステムバスが今のところ66MHzに限定されているところが違うところだ。目的としているコードのクリティカルな部分は各ノードでは、ほぼL1キャッシュに入ると思われるので、メモリアクセス速度はあまり問題にならないだろうと思われる。また各ノードに必要なデータは全量メモリに入れてしまえば、ディスクアクセス速度も関係なくなる。

とすると、Celeron を使うとすると、各ノードあたり、
Celeron 500MHz　￥20k
M-ATX マザーボード　￥13k
DIMM メモリ 64MB x 3　￥15k
フロッピー　￥3k
3C905B　￥7k
M-ATX ケース　￥8k
で合計　￥66k になる。サイズは330H*180W*380D だ。

さらに、これをNLX のベアボーンにするとサイズは280H*90W*360D になる。ラックに入れると、丁度M-ATX の半分のサイズだな。値段は少し高いぐらいだから、こっちの方がいいかも知れん。ただしDIMMが2枚しか入らないな。さらにサイズを小さくするためにケースなしでマザーボードを並べる手があるが、8k 円のケース分でボードのサポート、電源の別購入、と取り付け、フロッピーの取り付け、はちょっと難しい。Celeron のNLX ベアボーンで決まりだな。1台70k として100台でも7000k 円だ。1400H*1800W のラックに入るぞ。

[top]

10月から別の急な仕事が入ってしまって、何もできなかった。ぐずぐずしているうちに、IntelからCoppermine が出るという話しになってきた。Coppermine は2次キャッシュまでダイに作り込んであるので、キャッシュとCPUのバンドが広い。1G byte/sを超える速度だというんだからスパコン顔負けだな。おまけにこのCoppermine 、例のインテルスロットの他に370ソケット用のパッケージももうすぐ出すんだそうだ。クロックは700MHzぐらいのが一番のボリュームになりそうだから、Cerelon でクラスタノードを組んでしまうと最初から型落ちになってしまうぞ。ま、買わなくて良かったとも言えるな。

[top]

またしばらく間が空いてしまった。するとすぐにハードが進んでしまうぞ。ところで、もう長いことNTサーバをMacのためのファイルサーバにしているが、そろそろディスクが危ない気がする。何せ、このNTサーバ、HP製なのだが、入れた時分にはNetWare用で、NTはサポートし始めたばかりだったのだ。もう相当に長い間、ディスクアレイが動きっぱなしなのだが、故障した時、果たして警報が出るのかどうかも分からないし、マニュアルもないのだ。

ということで、しっかりしたファイルサーバを作りたい。取りあえず、空いていたMac8100をファイルサーバにすることにした。余っていた4GのSCSIを2台つっこんでRAID1にしょうと思って、あれこれ調べた。だがハード的に実現するのはコストを考えると有利ではない。しかしREMUSというソフトRAID用のツールが見つかった。一方、ファイルの安全性を考えるならば、バックアップという手もある。そこで、Macのバックアップ用ソフトを最初に導入することにした。つまり2台のSCSIの内、１台をサーバー用にエキスポートし、夜中にこれをもう1台にバックアップするわけだ。バックアップ結果をメールで報告することもできる。だが、実際に運用してみると、SCSIディスクがかなり熱くなる。Macではどうも冷却に不安があるな。

それでは、LINUXでRAIDを組むことを考える。ハード的に構成することもできるが、どうもRAIDボードは高そうだな。もう一度原点に戻る必要があるぞ。ファイルサーバの目的は大容量のデータを安全に提供することだ。アクセススピードはあまり問題にならない。そうすると、現在のIDEディスクのコスト、容量を考えると、SCSIではなくIDEを使うべきだな。しかも、数年経てば、ハードウェアは陳腐化するから、ホットスワップもあまり必要がないだろう。すると、十分な容量のIDEでRAID1を組むのが今のところ一番適切だ。

LINUXのソフトRAIDが安くできそうだ、というので調べると、IDEを2台以上一つのポートにつなげるとまずいように書いてあるな。ポートを別にする手もあるが、SCSIとの機能の違いが出ているのだ。さらに調べると、カーネルに手を入れなければいけないらしい。また、クラッシュした時に後の手続きが面倒なようだな。

IDEであれば、ハード的にポートを分岐してRAID1を作ることのできるハードがあった。DupliDiskというカードだな。ステータスの表示装置も付いていて安いぞ。第一にソフトウェア透過的に使えるのがいいな。現在IDEは10Gで１万円という安さだから、これを2台組み込むのが正解のようだ。ただし、速度はU/DMA33どまりなんだな、まだ。

[top]

クラスタノードをどんなふうにブーツするかで考え込んでしまったが、やはりハードの進歩の方が早いな。IDEのコネクタに直接差し込む、シリコンディスクがあったのだ。DiskOnModuleという名前だ。フラッシュメモリで構成されていて、４Mで4800円、16Mで9800円だ。もっと大容量のものもある。ボードに差し込んだ状態でも高さ30mm弱だし、電源はIDEディスク用が使える。これが一番簡単な気がする。もう、フロッピーにどんなふうに詰め込もうかと考える必要はない。だんだんに技術がいらなくなるな。

[top]

自分の予算はとっくに赤字だったが、よそさんのお蔭であれこれ買い込むことができた。最初はMac本体も買ってもらおうかと思って予算の確保まで行ったのだが、これは途中で気が変わった。Power-PCの高速版がどうも今年中には出そうなので、今、G4を買うのは少し早すぎ、の気がしたからだ。と言うのも、手許の8500にはついこの間、最後の予算でG3の400Mボードを突っ込んであったので、計算速度の面ではもうこれ以上、速くならないのだ（メモリも増やしたし）。だが、MacのG4はディスク等の足回りをうんと強化することができる。実際のところ、Ultra160SCSIの64bitカードが使えるのは他にないぞ。だがドライブが出始めでまだ割高だ。折角、新しく買ってくれるというのだから今のを捨ててもと、かなり心が動いたが、「CPU速度は変らないじゃないか、主にパワーを使うのはMathematicaだけなんだから」、という良心の声に従って、取り替えるのは止めた（ゴミも減らせるし）。

その代わり、使っている8500用にUltra2SCSIカードと、これ用9Gディスク2台を買った。カードは32bitPCIだがbusが2チャンネル付いている。各バスに1台ずつくっ付けて使い、例のソフトRAIDを組んで、どの位、足回りが強化できるか調べようというわけだな。ついでにディスク２台を取り付けるクーラー付きのアダプタも入れた。さて、このソフトRAID、RAID0とRAID1を混在して作成することができるという。それではよろしく、というので2つのボリュームを作ったぞ。ミラーとストライプだな。

カード付属のチェッカーでテストしてみると転送サイズによるのだが、128kBでは両者同じくらいで、readにSustainedで、60MBの値を出したな。サイズが512kBになると両者の違いが出て、RAID0では、read:51M、write:27M、RAID1では、read:13M、write:13M、になったが、これは効く。普段、使い始めると元には戻れなくなってしまったぞ。速くて（この調子だとUltra160に10000rpmディスクを組み合わせたら相当のもんだな。やっぱりG4を買えば良かった。酸っぱそうな色だったけれど）。

後で調べたらUltra2SCSI(LVD)の場合、内部ターミネータを持っておらず別にターミネータを付けなきゃいけないことが分かった（付けていないんだが）。最初のネゴシエーションの時、ターミネータがないせいで単なるUltraSCSIと看做されることが起きるかどうかは不明だ。だが安心、上のWWWデータシートには、Sustained data rate: 12.7 to 20.2 MB/sec、と書いてあるな。じゃ、2台並列でも40MBにしかならないじゃないか。上のテスト結果は何なんだ？？

ところで、ソフトRAIDなので、問題がある。ブータブルにできるのだが、今まで使っていたブートディスクが活きているとブートしない。これを外さなきゃブートしないのだ。どうもソフトRAIDの仕掛けのせいらしい。このソフトRAID、読み込まれたブートブロックは最初にRAMディスクを作成して、このRAMディスクがブータブルディスクであることをMacのブーツプログラムに知らせるらしいのだ。だから、ソフトRAIDのブーツブロックにおかしなことが起きると、別のデバイスから立ち上げなけりゃならなくなる（最後の最後、今まで使っていたディスクからRAIDにファイルを転送して、外箱を取り付けた後で、これが起ってしまった。ウムムのム。

たぶん、ターミネータなしでディスクをつないでいたので、何かが起きたんだろうと思うんだが。結局、同じ作業を繰り返してRAIDを再構築するはめになったぞ（おまけにこの9GBのディスク、適当なドライバがないせいか単独では、ブーツしないのだ。参った））。ここんところは、LINUXでソフトRAIDを組むと同じようなことが起きるんだろうと思われる。

というところで、これまた注文しておいた、IDE用のRAID1ハードウェアが届いたぞ。UltraATA33どまりだが、モニタや自動再構成、ホットスワップもできる。5インチベイ2台分にぴったり収まるようになっているぞ。

　[top]

今日のニュースでAMDが1G Athlonを売り出した、とあった。Intel もPen III を今週中に出すそうだな。そのデッドヒートの様子がここに詳しく書かれているぞ。どうもAMDはIntelに先行しつつあるらし。Intelは1Gを発表したものの、採れる（野菜のようだな）チップの割合が低いらしい。今のPen IIIでは構造的に無理があるらしいからだ。Intelのコアが新しくなるのは次のWillametteからだから、半年位はAMDにアドバンテージがある。AMDは2次キャッシュをオンダイにするという手が残っているので切り札の数が多い。それにWillametteはRAMBUSをデュアルにしてメモリバス幅を稼いでいるのだが、RAMBUSの旗色が悪いのマイナスポイントだな。マザーボード開発側から言えば、今まで通りのPC100を使って足りなかったらこれをデュアルにした方が作りやすいと思うぞ。

IntelのIA-64の影がだんだん薄くなっていく感じがするな。AMDは今のコアをそのまま64ビットにスケールアップすると言っているので、対抗上、IntelもWillametteを64ビット化するんじゃなかろうか。PCはCPUだけでなく、チップセットこみのマザーボード上で動くから、マザーボードを作っているのが利に聡い台湾メーカである限り、ユーザとしてはIA-64より当然のように確実にマザーボードが安く供給されるAMD-64を使うだろうからだ。IA-64の元はHPのVLIWマシンだったのだが、最初HPジャーナルにこの話しが掲載された時には、すごい技術があるもんだと感心した覚えがある。だが、随分昔の話だ。結局IA-64はスジがいいと皆に期待されている内に年とってしまった野球選手のようになるんじゃなかろうか。

さて前回のお買い物週間の時に買っておいたパーツで１台組んでみた。ただCPUにはCoppermineの600MHzを買ったのだったが、買ったとたんに値下げがアナウンスされた。だが、マザーボードの方はApollo Pro133Aチップセットの載ったEPoX のEP-3VCAだから、メモリをPC133対応に換えれば、800Mのプロセッサにも対応できるぞ。一応FSB133にしてx8にすれば１Gになるんだが、まだソケット370の1Gは出ていないから、Intel からは買ってやらないぞ。全体の流れを言えば、Intel ではなくてApollo Pro133Aチップセットになり、RAMBUS ではなくてPC133に、Sloto１ではなくて、ソケット370になるんではないかとワシは予想する。つまり、使う方から言うと、あまりIntel 一辺倒というのは気が進まないのだ。だが、安ければ使う、というのが節操のないところだな。

ディスクには買っておいたIDE用のRAID1ハードウェアを入れたのだが、少しはまった。ブーツの時にBIOSが認識しないし、RAIDがビープし続けるのだ。内蔵ディスクの設定が悪いのかとあれこれ調べたが変わらない。マニュアル（薄いマニュアルしかついていなかった）にはビープすることも書いていないぞ。でしばらくあれこれした後、ホットスワップディスクが勝手に引き出されないようにするキーロックがスイッチになっているのに気がついた。つまりディスクロック位置にスイッチされていないと、電源が入ったとたんにビープが鳴るしかけだったのだ。

で、作ったマシンを今後のクラスタマシンの起点にするぞ。16ポートのスイッチングハブも買い物週間の時に買ってあるのだ。クラスタの方はやはりフロッピーブーツにすることにした。例のetherboot はDHCP にも対応しているのが、昨年度の調査で分かったのだ。予算は余りないだろうが、方向性はこれで決まったぞ。つまりソケット370マザー、LAN付き、Pen III 800M以上、フロッピーブーツだ。フロッピーはサポートしないマザーボードも出てきているらしいので、この場合は例のDiskOnModuleだな。だが箱に入れると中がスカスカになってしまう。コンパクトなシステムにしてみたいぞ。1G-LANもそろそろ出てきているがハブも含めて値段がこなれてくるのは来年以降になるだろうから、検討は後回しだ。

　[top]

しばらく間が空いてしまった。遊んでいたわけではないぞ。おおもとの、計算アルゴリズムの見直しをしていたのだ。かなり手探り状態のところもあったが、なんとかまとまった。さすがにMathematicaがあると違うな。ところで、あてにしていた外部予算も先が暗いな。雨模様だ。こういう時は自分で少しずつ始めるしかないぞ。これまでに揃えてあった部品で組んだマシンにlinux6.0を入れた。たまたま買ったハードディスクのおまけに付いていたのだ。LASER5のパッケージだ。RedHatが直接の日本進出を決めたので、LASER5もなんとかユーザを増やしたいところなんだろう。

他に以前からあったlinux5.2をクラスタの１台に見立てて、ディスクレスマシンとして立ち上げることにしたんだが、ここではまってしまった。linux6.0、カーネルは2.2.3なのだが、これでディスクレスブート用のフロッピーブートカーネルを作った。このカーネル、bootpでipを取得してnfsでルートをマウントするのだ。ところが、ipを取得するまではいくものの、その後、だんまりを決め込んでしまう。make manuconfigであれこれ設定を変えてみたがさっぱりだ。で、以前の5.2のマシンでブートディスクを作るとうまくブートしてルートをnfsマウントし、ログインはいくではないか。5.2と6.0ではカーネルやlibにかなりの変更があるというので、今さらサーバーを5.2に戻すのも何だ。

２日間程、あれこれいじりまわしたが、結局解決できなかった。そこで外部の応援を頼むことにした。彼等も忙しいらしく（今年は契約もしていないんだが）、２時間ほど来てくれることになった。で、結局、カーネルの2.2.3自体がうまくない、ことが分かった。最新の2.2.15で作るとうまく働いたからだ。大分回り道をしてしまった。

ところでディスクレスマシンの使い勝手なのだが、いきなり電源断にできるのは確かに気が楽だ。しかし、サーバ側にクラスタ１台毎にルートファイルシステムが必要なことが分った。つまりetcやvarは書き込みがあるので別として、bin, sbin, boot, root, なんかもリンクを張るだけではまずくて、実体が必要なのだ。また、サーバ側にdhcpを用意しても、クライアントがbootpでip要求を出す設定にしかできないので（EtherBootを使えばなんとかなるようだが）、結局NICアドレスのメンテが必要になるし、サーバ側の準備も必要だ。というようりもbootpでipを取得した後、ルートファイルはnfsでマウントという設定にしてあっても、最初はtftpでファイルを読み込む必要があるのだ。ここらあたりの関係はよくわからないな。調べる必要があるだろう。

その他に、bootpでipを取得するのにも結構時間がかかる。おまけにフロッピードライブが足りず（今までにフロッピードライブをわざわざ買ったことなどなかったので）クラスタ１台分しかテストできない。カーネルの再コンパイルが割合に簡単なことが分ったので、ここは、シリコンディスクの出番かもしれないな。〜ん、だがシリコンディスクではいきなりの電源断はできないかも知れないな。

　[top]

ディスクレスのコンフィギュアにはまってしまった。昔は車が泥道にはまり込んだら、スタックと言わず、えんこ、と言ったのだが、今はあまり聞かないな。さて、はまった原因から言うと、make menuconfig の後、make zdisk、あるいはmake bzdisk をすると、ブートディスクが作られるのだが、これでは、メモリに展開された後、カーネルに渡されるboot パラメータが不十分だったらしいのだ。だから、make zdisk の後、makenod /dev/boot255 c 0 255 でデバイスを作り、次にrdev を使って、/usr/sbin/rdev /dev/fdo /dev/boot255 として、カーネルに必要なブートパラメータを送らなければならないことが分った。ブートして、カーネルが展開され、bootp を出してip を取得するまではうまくいくので、まさかroot の取得の設定がまずい、とは思わなかった。コンパイルの時にはnfs でroot をマウント、と設定するんだからな。

ここに来るまで、カーネルのバージョンが低いせいか（例の外注メーカに聞いたら、2.2.5 だからだめだと言ってきたので思い込んでしまった）と思い違いをして、あれこれ、昔の2.0 や雑誌の付録やまた元の2.2.5 やら2.3 のカーネルまで出し入れしたり、xconfig が使えるのにmenuconfig が使えなかったり（curses.h がない、と言われるのだが君、知ってたら教えてくれ）１週間ぐらいスタックしてしまったぞ。おまけに、シリコンディスクを使っていて、ハードディスクのブートブロックを壊してしまったり、痛い目にもあったな。だがおかげで、rpmの使い方だとか、カーネルのコンパイルの仕方だとか、patch の当て方なんかを知ることができたな。おい、君、転んでもただでは起きないことが重要だぞ。

このスタックの最中に、MSIのベアボーンを買った。133MHz までのFSB とCoppermine が使える。おまけにディスプレイチップやIntel の100MHz LAN チップまでオンボードで搭載されている。このベアボーンと733MHz のCoppermine 、128Mメモリ、フロッピードライブで10万円を切るな。Coppermine の値段はどんどん下がっているので、すぐにもっと安い値段で1GHz まで行くぞ。で、このベアボーンをいじり回している内、LAN のROM にEPX Etherboot が書き込まれていることが分った。これならば、フロッピードライブもいらなくなって、サーバ側だけの準備でよくなるぞ。ただし、他のベアボーンがLANブート用のROMを搭載しているかどうか不明なので、両方をテストしていく必要があるだろう。だが、このベアボーン、フロッピードライブをブートに指定していても勝手にLANブートを始める場合がある。ドライブの取り付けネジを緩めると元に戻ったりするので、ノイズだと思うんだが、よく分からんぞ。

まだ分からないことの一つに、dhcpd がブートされる時、eth0、eth1のパラメータがくっついているのを見つけた。しかし、このパラメータ、何時、付けられのかが分からない。init.d にもそれらしいのがないのだ。これが分かれば、dhcpd.conf に余計なeth1の設定を書かなくても済むんだが（もちろん、eth1はグローバル側だが、君がこのdhcp に問い合わせしても何も答えないぞ）。

--追記--これは、スタート時のrunlevel （この場合3）にあるdhcpd の起動スクリプトをdaemon /sbin/dhcpd eth0 というふうにすればよいのがわかった。デフォルトではdhcpd は起動すると勝手にネットワークを調べて、その全てについてdhcp サービスを始めることになっていたのだ--

　[top]

森首相が「国体の護持」だなんて言い出すもんだから、こっちの作業も支那事変のように泥沼化しているぞ（関係ないが）。作業しているサーバはNICカードの２枚差しをしているので、グローバル側にもアクセスすることができる。で、ブラウザを動かしているとハングしてしまった。topで調べるとメモリが64Mしか認識されていない。確か、カーネル2.2.x以上はメモリの自動認識をするんじゃなかったかと思っていたもんだから、configの時に無視していたのが間違いの元だった。

lilo.configでメモリの追加を書くというはうろ覚えで覚えていたので、append="mem=256M"としたのが大きな間違い。メモリサイズはBIOSのレポートするサイズより小さくする必要があり、なおかつ、Mで設定するとサイズの切り上げが起きるのでオーバーフローしてしまった。おまけにブートフロッピーは作ってあっても、ルートの入った２番目のレスキューディスクを作っていなかったので、また最初からやり直すことになってしまった。

だが、いくら何でも学習効果が働いていたので、アップデートで実際にはliloのブートレコードだけを書き換えることに気が付いた。が、ここにもワナがあったな。RedhatのCDからではブートレコードの書き換えができないのだ。そこでDOSのフロッピーでブートし、fdisk MBRで書き換えてもまだいけない。format Cでやっときれいに掃除して、その後でCDのインストールプロセスの中でlilo用のブートレコードに書き込むことができた。append="mem=xxxxk"というように、BIOSのレポートより少し小さめのメモリをkサイズで指定するのがコツだ。だが、2.2.14では確かに自動認識するんだな、これが。

さて、クラスタ部分はフロッピーブートできたが、rootではrloginできない。これはFAQでhost.equivなんかをいじれば何とかなるらしいのだが、世の中の趨勢に流されることにして、別ユーザで素直にログインすることにした。

　[top]

さて、ベアボーンにはLAN が作り付けになっていることが多くて、この前買ったのにもIntel のチップがついている。おまけにLANブートROMが入っているのを見つけて、これを何とか利用しようとぬかるみに嵌まってしまったのが昨日までの顛末だ。

まずこのROMに書き込み済みのローダーだが、PXEという、Intel 独自の仕様だ。これを使ったソフト開発はライセンスがいるらしいので、linux 界隈ではあまり拡がっていないのだと思われる。だが、これ用にBpBatch というインタプリタがある。BpBatch はクライアントのPXEからの要求に答えて（というよりdhcpd.conf にfilename　"bpbatch.xx"というように書いておくと）サーバの/tftpboot ディレクトリからダウンロードされる。その後BpBatchは各種OSをtftp を通してダウンロードできるようだ。BpBatch はその他に画面にグラフィックを書いたり、キー入力の判断コマンドなんかを備えている。

だが、このソフト、クライアントにディスクがあることを前提に、ブートの度に必要な部分をサーバから強制的にローカルディスクに書き込むことができることが売り、のようだな。学校なんか向けのようだ。BpBatchのマニュアルにはdiskless-linux にも対応しているように書いてあるのだが、どうもダウンロード後にディスクに書き込もうとする。ディスクを使わない、というフラグを立てても状況変わらずだ。

で、PXEがIntel 独自なのを嫌ってEtherBoot なんてのが開発されているんだが、これは前にも書いたように独自のROMを作ることまでできるので、よっぽどクライアントの数があって、しかも同一機種、というような状況でなければ使うのは、難しそうだぞ。さらに調べるとPXE を使ってlinux をブートする仕掛けがあった。Pxelinux、というやつだ。ベータバージョンというところを見ると、あまり広く使われているようではないな。こいつはPXE の機能をlinux カーネルに取り込もうというプロジェクトなんだが、その派生ソフトとしてPXE を使ってリモートブートする、というのがあった。これはBpbatch と同じようなもんだが、confファイルでダウンロードするカーネルを直接、指定するようになっている。

これを/tftpbootに置いて、クライアントからアクセスすると、うまくいくじゃないか。ところがtftp のところでつまってしまう。普通のtftp ではなくて転送サイズを指定できるtftp-hpa が必要だ、というのだ。ところが、これを持ってきて、./configure, make するとwarning しか出ていないのに、xx.out を作る時にエラーになってしまう。別のバージョンを試したり、a.out をサポートしていないlinuxカーネルなのかと疑ってみたが、らちが開かない。

もう、やめ、と思ったが最後に思い直してrpm になっているものがないかと探したら、ありました。で、zImageをダウンロードするようにconfファイルに書いておくと、うまく、と思ったが最後にもうひとつまづき、があって、カーネルの2.2.15で作ったものでなければ、ルートをnfsマウントしなかったのだが。が、とうとう成功したな、これが。これはcool と呼ぶべきなんだろうが、ぬかるみを歩いてきた身にすれば、固い地面を見つけてひと休み、というところだな。

だが、まだ灰色なのはzImage の作り方だ。make zImage ではうまく行かず、make zdisk の後、rdev してから、逆にddを使って/dev/fd0 から吸い上げたzImage でなければいけないようなのだ。慎重にやらんと何もかもブートしなくなる気がするので、まだ完全にはクリアにしていないぞ。

ところで、このpxelinux、やっぱりMACアドレスが必要なようなんだな。というより、PXE がdhcp.conf にハードウェアアドレスを記述しないとip を受取らないのだ。

−−−追記（2000/9/20）
SoftwareDesign 誌 2000/10月号に、PXE とBpBatch の解説が出たな。これでは、BpBatch の環境変数を set CachNever = "ON" にすると、ローカルディスクに書き込もうとはしない、なんて書いてあるぞ。もう確かめる気はないんだが。

　[top]

前回までで、やっとハードに目処がついた。ここから、本番の計算プログラムの導入を始めることにした。というのも当てにしていた外部予算が相手方内部の計画変更のあおりを喰って0になってしまったので、外注を頼むことができなくなったからだな。パラレル計算はMPIをベースに開発してきたのだが、いよいよ自分でやらなきゃならん。

さて、中身はこれまで外注先に頼みっぱなしだったので、インストールのところからよく分からない。外注先から納品されたマニュアルにはmpirun -np x -machinefile ./xx ./xxx で起動する、位しか書いていない。当然のごとくエラーが出て、うまく走らないな。まず、root で動かすのはまずい、というので実行用のユーザを設定する必要がある。rsh が動くようにhome に.rhosts も設定する必要がある、ここらあたりは納品物に書いてあったな。だがそれでも動かない。

ここにきて、そもそもMPIがどんなふうに動くか、がよく分からない。調べてみると、日本IBMがMPIの入門書を出しているらしいことがわかった。「虎の巻シリーズ１〜３」の２のMPI編だ（青山 幸也、日本アイ・ビー・エム株式会社、〒103-8510 東京都中央区日本橋箱崎町19-21、TEL ：03-3808-5538、FAX ：03-3664-4762、E-mail：golgo13@jp.ibm.com）早速、送ってもらったぞ。本来はRS6000シリーズ用に書かれたものなのだが、MPIの動作環境やMPI関数の説明等があってわかりやすい。読んでみると、成る程、MPIの実行コードは同一のものが各ノードに置かれて実行される、というのが分った。forkと同じだな。同一コピーがこの場合、MPI_COMM_RANKという関数を通じて、自分のランクというかid を取得してid の違いから自分の動きを決定するわけだな。

ということで、各クラスタはこの実行コードに関して同じ動作環境（ファイルシステムやetc、ユーザの設定なんかだな）を持たねばならないことが理解できる。で、この場合、mpirun がリソース（クラスタの状態なんか）や、コードの複製とロード、なんかを実行するわけだ。ここにきて、なぜ、最初のうち、Permission error が起ったのかが分った。実行環境がサーバとクライアントで違っていたのだな。原理の理解はいつも必要だ、という格言だぞ。

だが、まだ動かん。-machinfile パラメータにクライアントしか記述していないファイル名を渡しているのに、サーバも動いてしまうし、ノード間のデータ交換がうまくいかないようなのだ。

　[top]

この前の話しはMPIのインプリメンテーションの内、mpichについてだった。だが、この上で開発した本番用のプログラムがなかなか動かないので、開発元に何回かメールで聞いたのだが、一般的な答えしか返ってこない。そのうち、なしのつぶてになってしまった。まあ、ただでやってもらっているし（昨年度納入品の瑕疵条項なんてのがないからな。役人だったら脅かして、ただ働きさせるんだろうが）、今年の契約も、どうも怪しそうだ、というのであんまり手間ひまかけられないんだろう。とは思うものの、少し寂しいな（かなりか）。

で、気を取り直して、MPIについても自分でやってみることにした。で、このmpich ではどうも見通しが悪い。MPIはその環境設定にかなりの準備が必要な筈なのだが、mpich はmpirun の中で色んなマシン環境（各種パラレルマシンを含む）で動くように、複雑なスクリプトが組まれていて、問題が起きた時、面倒なのだ。またMakefile も同じ考え方で作られているので途中でひっかかると実際には手が付けられない。

探すと、MPIの別のインプリメンテーションがあった。LAMというんだが。このパッケージのポイントは各ノードにあらかじめデーモンを動かしておくところだ。これで、MPIの複雑な環境設定が緩和されている。おまけにlinux用のRPMパッケージもあるし、環境設定後のテストスクリプトがあるのも心強い（気がした）。で、ダウンロードしようとしたら、Netscape がダウンロードのところでハングしてしまう。以前にはできていたのだから、あれこれ、システムをいじっている内におかしくなったんだろうと思うが、原因がわからない。再インストールしても同じだな。linux はネットワーク関係を設定する場所があちこちにあるし、GUIで全部できるわけでもないので、よくわからん（君は分かると思うんだが）。

結局、Macで落としてからFTPしてしまった。さて、ここからが大はまりが始まったな。LAMは各種設定の後、recon というスクリプトでノードの設定が正しいかどうかを調べることになっている。これはOKだったな。次にlamboot でデモンを各ノードで順番に動かしていく算段だぞ。だが、lamboot、これを起動するノード（この場合サーバだが）はうまく処理できるのだが、次のノードに行ったところでハングアップしてしまう。ーdオプションや、lambootの中身のhboot を動かしたりして調べると、kernel (bind ) Permission error 、と出るな。当然、DNSの関係だと思い込んだな（premission error というところがDNS とどういう関係にあるのか、少し変だなとは思ったんだが）。LAMのサイトのFAQはかなり充実しているのだが、見つからないぞ。

で、一週間程、毎日、DNSやネットワーク設定ファイルをああでもない、こうでもないといじったがらちが開かないんだな、これが。サーバとクライアントのカーネルのバージョンが違うのが気になるのでサーバ側を入れ替えようか、とも思ったが、これまでの経験上、最後にとっておくことにした。あれこれいじっている内、新たなエラーメッセージが出てきて、これにlamboot は/tmpに書き込むので云々、というのがあったな。それでchmod 777 /tmp にしたらあっさり動いた。つまり、クライアント用の/tmp はroot で作っていたので、root 権限でしか書きこめないようになっていたのだ。わたしがバカでした。

実にLAM、一週間のはまり道、まよい道、くねくね、だったな（そう言えばそんな歌もあったのを思い出した）。ところで、LAM といえばLAMB だな。またジンギスカン鍋でビールが飲みたいぞ。

　[top]

以前なら（また昔の話しか）MPI 設定後、本番のアプリケーションまで一気に突き進む、という馬力もあったが、今回は気分的にのらないので中休みをとった（やっと棚と鉢の準備ができてこれからどんなふうに盆栽を仕立てるか、の気分だな）。確かにlinux、MPI、C では、結果が出るまでの見通しが悪いな。研究の核心部分のモチベーションの維持が難しいのだ。ワシの経験から言えば（そら出た）。最終結論までの道が長いので、途中のプログラミング部分で仕事をした気分になってしまうんだな。君もそうじゃないのか。

繰り返しになるがMathematica なんかは、この最終結論に行くまでの道のりを明確にするのに役立つ。理論の筋道立て、これを支えるアルゴリズムの検討、結果の評価、本文の作成までが目に見える形にできる。色んな認識や記憶は地図のように頭ん中に展開されていると思うんだが（よく記憶術で言われるな。身の回りのものに言葉を対応させるやり方だ。だが問題認識の時にもこれは役立つぞ。個々の事象をネットワークにしてその関係を調べてみるのだ。

UNIX はそうなっていない。ユーザに対して認識のための地図は与えず、論理的なツリーがあるだけだからな。Mac は机とフォルダ、指のメタファーとしてのマウスを通じて認識のための地図を、いわば身体的に提供しているところが革新的だったのだ。身体的というのは、我々の認識が身体を通じて行われている、という意味だ。Alto が先だと言うが、マウスボタンが複数、というのが何のメタファーか分からん、という点で未完成だったとワシは思う。この流れでUNIX のGUI は3ボタンマウスを要求するが、なじめないな。そう言えば、スクロールホイールまでサポートしているOSがあるが、一体、何を考えているのだと言いたい。

というわけで、パラレルアプリケーションに手をつける前に、環境整備ということで、まずサーバのメモリを増やした。256Mを入れたな。３万円弱だったので、ひと頃より値上がりしているんじゃないか。lilo.conf を書き換えてlilo 実行ですんなりこれは動いた。次に気になっていたクライアントが動いているかどうかを調べるスクリプトを作った。クライアントの電源を入れた後、これまでは一々ping かrsh で調べていたので面倒なのだ。先の形としてはGUI で自動監視しているようなものにしたい。で、ping を打つと止まっているクライアントに対してはSIG を送らなければ、行ったきりで何も返ってこないところが問題だ。

確か、HPのping は-c の数だけping したらシェルに返ってくるのだが、linux は行きっぱなしになってしまう。だからping をバックグラウンドにして、後でステータスを調べる、というふうにした。ping のid でコントロールするのだが、ps を使うのではなく、ping を発行する度にリストに付け加えるところが考えたところだな。このリストでfor を駆動するなっている。ワシもリストを使ってfor を回すようにするのは知らなかったのだ。

だが、スクリプトをいじり回すのは形式論理主義者の喜びだな。やり過ぎてはいかんぞ。昔はよかったな（また出た）、環境が単純であった。MKS Toolkit という、DOS のためのツールがあって（今でもあるんだなこれが）、unixのかなりの部分が提供されていた。DOS上ながら強力なところが気にいっていたぞ。特にこのマニュアルが使いやすいのでワシは今も愛用しておるぞ。

　[top]

さて、なかなか本番に進まないな。今日も横道にそれて、昨日作ったスクリプトをGUI 化してみたぞ。普通GUI を作るのはおおごとだ。使って天国作って地獄だな。Tcl/Tk を使うのがまっとうなんだろうが、ワシの年令ではもう気力が湧かない。そこで以前から愛用のMetaCard のお出ましだ。こいつは今はなきHyperCard の末裔だな。HyperCard が顧みられなくなって久しいが、残念なことだ。VB がはびこっているな、世も末だ。

さてオブジェクトに対してメッセージを送ることでプログラムが動く、という環境を一般ユーザが使えたのはHyperCard が最初でほぼ最後だな。だから、最後の砦のMetaCard に対しては応援している（995ドルも出して買ったからな）。実装が極めて軽いのも気にいっているところだ。

というわけでクライアントが生きているかどうかを調べるスクリプトのためのGUI なんだが、ボタンを3つ付けた。GUI を活かすためのstart ボタン、止めるためのabort ボタン、クライアントの数やらの環境を設定するconfigure ボタンだ（まだ中身はないが）。それとクライアントの状態表示ランプ。

最初に、こうだったらいいな、と思う機能を設定する。まず、start ボタンを押すとGUI が活きて、同時にGUI 自体が活きていることを示すために3秒に１回、0.1秒だけこのボタンの色が黄色でフラッシュするようにする。それから、start 後、abort ボタンが押されるまで、10秒に1回、昨日作ったスクリプトを動かして結果を取り出し、その結果を状態表示ランプに設定する（生きていたら赤くなるようにした。青でもいいんだが）、だな。その他にも暗黙の了解として、いつどのボタンを押しても機能が破綻しないことや、start ボタンとabort ボタンの動作は排他的になっていなくちゃならない、なんかがある。

ポイントはwait なんかは使わないで、ある一定時間毎にメッセージを相手や自分自身に送るところだ。Tcl/Tk を使ったことはないが、こんな風に働くインターフェースを作るのが大変そうなのは予想できるぞ。MetaCard では全部で60行位か。また格言だ。必要なものは高くても買え、だな。

-追記−　クライアントが生きているかどうかを調べるスクリプトはMetaCard から呼ぶようにしてあったんだが、shell スクリプトの見通しのよくないところが何となく気にいらず、結局７月末にMetaCard のスクリプトで書き直してしまった。

　[top]

前回までにLAMMPI の設定は終わった。ということでいよいよ本番へと進もう。だが、その前に、作ったGUI にもう少し手を加えることにした。本番では、各ノードで果たしてプログラムが実行されているのかどうか、CPU の負荷状況を調べたい。今までは各ノードにログインしてTOP なんかで表示していたのだが、一々面倒だ。そこで、作っておいたこの前のGUI に、各ノードの負荷を表示するバーを付けた。このバー、スクロールバーの変型なのだが、よくあるように負荷に応じてカラーバーが伸びるようにした。負荷の状況はrsh とuptime で取得するようにしたぞ。

さて、外注したプログラムはそのままでは動かない。コンパイルエラーが起きるのだ。ある関数がない、と言ってくるので、調べるとmpich のinclude ファイルにあるパラメータ、この場合MPI_2REAL はLAMMPI ではMPI_DOUBLE にしなければならないのだ。その他、MPI_STATUS_SIZE なんかも違った。

予想されたことだが、MPI はそのインターフェースが定義されているだけなので、細かな定義は、各インプリメンテーションで違う、ということだな。だが、あまり大きな違いでなかったので良かった。これに関連してMakefile もいじんなきゃならなかった。その後、コンパイルは無事終ったが、実行時にエラーが出る。開発元に聞いてみようかとも思ったが、思い直してソースをみたらファイルのオープンエラーらしいことが分った。これはchmod で直り、うまく実行が終了したぞ。これで、Stage-I クリア、だな。

次はplot プログラムのGUI 化、クラスタのタイマの同期システム設定なんかの片手間仕事、それに本番プログラムの書き換えだ。面倒なのはプログラム書き換えだな。Mathematica で開発したアルゴリズムは外注先に出した後、大幅に換わっているのだ。外注先で開発したのはCで書いてある。ワシは昔の人間だからFORTRAN が好きなのだ（大体、UNIX 自体がなかった時代だったからな、ワシがプログラムを始めた頃は。今、FORTRAN プログラマは化石扱いされるんだが、FORTRAN だって万能だし、pointerを使わないのでメモリリークエラーが起きにくいんだぞ）、が、FORTRAN に書き換えるよりはCで書き換えをした方が、時間が少なくて済むのは明らかだ。Cは殆ど書いたことがないので、少し気が重いぞ。

だが、これでC使いになれる、と思えばいいのだ。

　[top]

さて、頼みの綱からの連絡は入らないな。しょうがないからCのコーディングを始めたぞ。まず、外注先で作ってもらったプログムを解読するところから始めなきゃならん。読んでみると一般的な書き方でしっかり書かれているようなので、理解できた。

だが、金額が安かったせいもあるので、入出力の部分が簡略化されているな。この金額では一々発注元の意見を聞いて、将来の拡張性を考えながら、なんてことはできないのも無理はない。大体、昔から入出力が一番手間がかかることになっているのだ。以前にどこかに書いたが、昔は画面１枚あたりの設計でいくら、という見積もりが行われていたぐらいだからな。

本番プログラムは、これからかなり拡張しなきゃならないし、使いやすくなきゃならない。このあたりは、自分で使うのだから動きゃいいんだ、という考え方もあるんだが、バグ取りしながらコーディングすることを考えると入出力、特に入力パラメータは取り扱いが簡単になっている方が結局時間短縮になる、というのがワシの経験則だな。

そこで、入力パラメータはGUIにすることも考え、free-form 形式にして、なおかつパラメータの順番も自由にできるようにする、という方針にした。これは以前から使っているコードがヒジョーに面倒な入力形式を要求していて、その面倒さに往生した経験があるからだ。

free-form の入力を整えるのにはbash のスクリプトとsed を組み合わせたものを作った。次にフォーマット化された入力パラメータをメインプログラムで読むようにした。だが、scanf ライブラリの使い方でかなり難渋したな。パラメータのキーワードを検索した後、改行までの部分を読み飛ばすところが中々正解にならなかったのだ。とっておいたHPのマニュアルがここでも役立ったぞ。ここらあたりは、家に帰ってから頭の中を整理して、また次の日に続けるといい結果が得られるな。

だが、プログラムを作るにはどうしてもエディタが必要だ。emacs はどうも使う気にならない。キーバインドが覚えられないのだ。若いころなら、指が覚えたと思うんだが、Mac に慣れてしまうと指を総動員してプログラムを書くのには戻れないな。だが仕方がないのでvi を使うことにした。必要に迫られてyy、p、R、Ctrl-z、:set num、なんてコマンドを覚えたな（最初から覚えておけってか）。

そう言えばこれまであんまりvi は使ってこなかったな。昔、プログラミングによく使ったのはTECO の流れをくんだHPのラインエディタだった。それから大型のPDF だったかを使わにゃならんはめになったな。こいつは面倒なばかりで全然パワーが足りなかったな。後はTurbo のエディタやDOS 上でWord なんかも使っていたぞ（このころのMS Wordは良かったな）。VZ なんかも良かった。もう10年以上前になるか、LispMachine のエディタにも触ってみたが、もうMeta キーが付いていて、キーバインドの面倒さに一寸違和感を覚えたな。少し前まで予算のあった時は、HPsoftbench なんて高級なものを買ったんだが、ブタに真珠であったぞ。

取りあえず、パラメータを読んで別ファイルから計算の元になるデータを読み込むところまでは行ったな。やっと外堀が埋まった。

　[top]

ここんところは、本体プログラムの核心部分を書き直していた。前にも言ったが外注先に作ってもらってから、大分日がたっていて、アルゴリズム自体が変化しているからだ。だが暑いせいか、なかなか気合いが入らないな。均すと一日あたり10行ぐらいしか書いていないんじゃないか。将来のアルゴリズムの変更を考えたり、もとのMathematica の中身に何が書いてあるのかを思い出しながら、あちこち、手直ししながらとなると、ま、こんなもんだろ。

途中でひっつまづいたのは、fgetpos 関数のところだな。ファイルポインタを読み書きする関数だ。データはファイルから読み込むんだが読むべきデータの数は、実行しなければ分からないアルゴリズムになっている。それは仕方がないことなのだが、このfgetpos 関数でcore ダンプされてしまう。boot 直後だとある程度進むことがわかったので、どうもハードがらみのようだ。だがうまく行く時もあるのが困るな。

原因はあてずっぽうだが、ディスク回り、たぶんハードウェアディスクアレイの部分にあるような気がする。前にも言ったが、組上げたサーバにはハードでRAID1を入れてある。こいつは、本来一つのディスクドライブに行く信号を横取りして二つのディスクに振り分け、RAID1を構成しているんだが、時々ミスするんだな。普通に使っていてもごくたまに地味なエラーが出ることには前から気付いてはいたのだ。で結局、コンパイルオプションの-O 、つまりオプチマイズを外すとうまく働くことがわかった。いかにもそれらしい結果ではあったな。こういう問題解決法は気持ちが悪い、というやつがいるんだろうが、要はうまく行けばいいのだ。ただし、記録を残しておく必要はあるぞ。

他には、外注のプログラムでは各種パラメータをstructure にしてから引数にして渡していた。ここらあたりは考え方の違いと、プログラムサイズにもよるんだろうが、ワシとしては1~2回しか使われないような引数にstructure を使うのはこだわりがあるぞ（ところで、こだわり、というのはネガティブな意味で使うべきだと思うんだが、このごろは、「こだわりのラーメン」みたいにポジティブな意味合いで使っている例が多いな。ネガティブな表現法だからなくても良い、というのは脳天気と呼ぶべきではないのか）。というわけでこの部分はグローバルな定義に置き換えた。

ところで並列化するにはMPIランクをそれぞれのノードが取得してそのid に従って並列に実行されるわけだ。今のところ、本体の二重ループの部分でだけ、この並列実行が行われるようになっている。最終目標である計算モデルでは、この他に二つのループも並列対象になるな。しかし、ここまで話しを広げると収拾がつかなくなるな。眠っている間に考えることにしよう。

しかし、この間来た某社 のH氏に、このプログラミングの様子をみせたら「その年で自分でやっちゃいけねーよ」と言われたな。正論だ。方針自体も考えなきゃいけないな。当面目標は別のところにあるのだから、あんまりプログラミングばっかりというのも遠回りなのだぞ。

[top]

もう８月になってしまった。光陰矢の如し、いつまでもあると思うな親と金だな。ちなみに「いつまでも...親と金」は江戸期の川柳が諺になったものだ。昔の人は情緒が豊かだったんだと思うぞ。今日の新聞、西部邁のコラムに「米国とこれに追従する日本は未来を技術的操作対象として捉えている」の言があったが、興味深いものがある。

で、上の話しと全く関係がないのだが、プログラミングというのはなかなか進まないな。並列計算では、MPIプロセスの数により対象数列あるいはアレイを分割するのだが、必ずしも整数で割り切れるわけではないので少し面倒なのだ。これを計算する短い関数を例のIBMの青山氏のテキストから拾ってきた。ここらあたりはさすがIBMの余裕だな。そのうちIBMのパラレルマシンを買ってくれるかも知れん、というのでただのテキストを配っているのだから。しかもこのテキスト、非常に役立つ。

ここまではプログラムもきちんと動くようだぞ。具体的にはrecon で並列環境を調べた後（これはシステム構築時に１回やればいいんだな）、lamboot でデーモンを立ち上げ、mpirun -np N Main_Program Parameter_File と実行すれば、それらしく振る舞うことまで確認した。ここでN はクライアントの数だな。サーバも含めて、今のところはN= 3 だ。終わったらlamclean で後始末をするように、とマニュアルにあるが、mpirun を繰り返しても大丈夫なようだ。

さて次はいよいよフーリエ変換部分のインプリメンテーションだな。外注先が探してきたフーリエ変換プログラムはMPI にも対応している。もっとも外注先のソースを見たら、MPI は使っていないのだが。問題は、元のアルゴリズムでは、Mathematica で書いたため、全ての変数が複素数になっているところだ。で、虚数部分の数列も変換時に使ってアルゴリズムを書いてあるので、Cに書き直す時に面倒が起きる。Cではフーリエ変換に持っていくまでは、簡単のため実数だけを使いたい。ここらあたりはMathematica に戻って実数で計算するアルゴリズムを書き出す必要があるだろうな。一寸面倒だぞ。

あとgnuplot もそろそろ準備しなきゃいけないな。それにこの前プリンタを設定してうまくいった筈なのに、今日はプリントしないな。ユーザによって違うのか？時計がいつもずれているのも何とかしなきゃいけないな。以前、うまくtime server の設定ができたのに、メモをとっていなかったので忘れてしまったのだ。UNIX はユーザに記憶しておくことを強要する点がいやなところだな。君みたいに覚えがよい人間に向いているのではないか。

[top]

昨日の話しの続きで、元のアルゴリズムをreal to complex にしたらどうなるか、Mathematica で考えたら、ちょいと面倒だな。real 部分を２倍のサイズにすればいいのだが、フーリエ変換後の仕上がりの波数範囲に関係しているので、あれこれ手直ししなきゃいけない。そこで、例のフーリエ変換プログラム、FFTW というインプリメンテーションなんだが、マニュアルを印刷してみてから読んだら、ちゃんとcomplex to complex 変換があって、最初に説明があったぞ。real to complex だとIm 部分が0になるので、メモリ利用効率が悪くなる。このためにFFTW でも特別に工夫したreal to complex があるのだが、complex to complex が素直なのは言うまでもない。

その他の案件としては、本体をさらに高速化することがあるんだが、まだ手を付けていない。考え方としては、カーネル部分がExp(u)* {Cos(v)+ i* Sin(v)} の形式になっているので、Exp 部分を曲線で近似して、さらにCos とSin をテーブルにする、というのが考えられるな。これはそのうち、ということにしよう。

ところで、並列計算機と言えばCM-5で、これを考え付いたのが当時、院生だったダニエル・ヒリスだったんだが、ビル・ジョイと友達だったんだな。この話しはMACPOWER.2000.8月号に載っていたぞ。ヒリスはS・ウルフラムとも知り合いだというから、才能のある人間というのは集まるもんか。ワシの場合、せいぜい、朱に交われば赤くなる、程度なのが残念でした。

[top]

さて、fftw を使うのは簡単だ。3行程、書き加えればよい。だがローダのところでつまづいた。まず、fftw のライブラリは/usr/local/lib に入るのでここを探すように指示しなければならない。ld のman を見ると-L オプションを付ければよいと書いてあった。がうまくリンクしないじゃないか。cc の代わりにMPI 用のhcc が使われているからかと思ったが違う気もする。少し頭を冷やしてから、-L /usr/local/lib -lfftw -lm -o ... となっているのを逆にして、-o ... -L /usr/local/lob -lfftw ... としたらリンクした。どうも納得がいかないが、しようがない。

MPI はクローンプロセスが同時に動くので、ファイルの読み書きも同じことを実行する。本体プログラムは結果をファイルに書き出すようにしてあるんだが。ん〜、そうするとクライアントは部分的な結果しかファイルに書いていないことになるな。今使っているサーバは２台のクライアントに比べて遅い。でデータを集めたサーバが最後に結果を書き出しているんでまともに見えることになっているのか？これは再チェックだな。

さて結果はグラフにしなきゃよくわからん。gnuplot が入っていなかったのでgrpm を使ってインストールした。以前にgnuplot のコントローラをMetaCard で書いてあったので、これは以前のワークステーションからftp (x版が使いやすいな）で持ってきた。で、取りあえずコマンドからplot してみると、それらしい吸収線パターンが出たな。数字の桁数がむやみに大きいのをみると、まだバグがあるが、なんとかなるだろ。

本体のコードは今のところ440行位だ。プログラムを始めてから20日間だから、やはり10行強／日だな。大分、先が見えてきたぞ。♪一つ山越しゃだな。だが実際のところ結果評価の話しが全然目処が立っていないから、山また山、だぞ。早い内にどこかと協力関係を結ばなきゃならんな。

[top]

夏休み〜その１〜をとっている間にまた日が大分過ぎてしまった。ニュースによるとAMDがx86の64bit 版の概念を発表した。前から言われていたようにx86をそのまま64bit にしたものだ。64bitモードを使うとアドレスがフラットになって、あの面倒なセグメントレジスタを使わなくてもよくなるという。その割りにはゲート数で5%ぐらいしか増えないというから、コストもかからずに直ぐに出荷されるんじゃなかろうか。今までのx86コードはそのままフルスピードで走るから、どうもIA-64の分が悪いな。

Hammerというファミリ名になるらしいが、取りあえずの目的はデータベース等のサーバ用とされているようだ。だが、これだけのアドレススペースがあれば、今の調子でディスクサイズが大きくなっていっても当分の間、これを直接アドレシングすることができるな。そうすると、例えばファイルシステムという概念を超えて全てをメモリに展開するコンピュータシステムなんてのが実際にできてくるかも知れないな（勿論、実メモリではない。ページングでディスク上に展開するのだが）。

だがこのHammer、浮動小数点については使えるレジスタの数が倍になるものの、大きな変更はないようなのだ。だから、これをすぐにクラスタに導入する必要はないと思われるな。これに対してIntel のPen-IV、Willametteとか呼ばれていたやつだな、やっぱりこれはRambus をやめて普通のSDRAMインターフェースになるようだ。思ったとおりだな。こっちの方はクロックが高くてパイプラインが深いから、Windos なんかに使っても殆ど効果はないだろうが、ナンバークランチャにぴったりだな。出てきたら直ぐに使ってやろうじゃないか。

ついでだが、ソニーはCrusoeを使ったVAIOを出すらしいな。 Cyrixもクロック数だけは高いやつを出すらしい。だがどちらも浮動小数点計算は遅いようだな。だからクラスタの候補にはなり難いだろう。ただし、Crusoe はメモリインタフェースのバンドが広い（速い）らしいので、省電力型のワンボードタイプが出てくれば、選択肢の一つになるかも知れん。消費者がクロック数だけで選ぶのでメーカもこれに応えて、中身じゃなくてとにかくクロックの数字だけで勝負する、というのはこれからどんな風に展開するのか興味あるな。

前回は、今が胸突き八丁、もう少し、なんて言っていたが暑くなってくるとやっぱり休んじゃうんだな、これが。だから今回はただの評論家になってしまったぞ。

[top]

Mathematica 版とMPI 上のC版の結果がやっと一致した。5桁目あたりから違っているが、まあこんなもんだろ。ここに来るまで、二日程はまってしまった。MPI はクラスタ間でデータを転送するのだが、この時、double までしかサポートしていないのを忘れていて、complex をそのまま渡していたため、データが転送途中で落っこちていたのだ。途中経過をグラフにするまで分からなかったぞ。

これでStage-II クリアだ。犬小屋ができたので、まわりのかんな屑の掃除でもするか、状態だな。この後は本格的に放射伝達モデルに取っ組まなきゃいけない。どこかから金を工面して、共同研究かあるいはどっかに渡してしまう、というのが望ましいぞ。

ところで、これまで長々と開発してきたのは、計算コードの高速化のためだったな。プロジェクトは途中評価が重要だ、なんて自分で言っておきながら評価が後回しだったぞ。評価は最初からシステム化しておくか、あるいは外部の力が必要だ、ということだな。で、Mathematica でアルゴリズムを開発したケースでは10個のデータを基に1024のFFTサイズで計算した場合に約12秒かかった。今回の3台のPCを使ったMPI-C版では0.03秒だったな。丁度400倍の速度になったぞ。本番の計算ではデータの個数が、単純に言って5000倍くらいになるので最終的に150秒位かかるだろう。CPUの速度とクロック数アップのトレンドを入れて、100台前後あれば1秒位で計算は終わるだろう。楽勝だ。

というわけでプログラム一式ができあがった。

だが、本当のところは、計算じゃなくて、アルゴリズムやら、結果の検証が問題なんだな。ワシの定年までには終わらんぞ。