第 ew $ & 第 0 ce 0 ce に景彡響を与えているので、この出力結果を鵜呑みにして はいけません。結果の分析にあたっては、次の点に注意 してください ( と MUSBUS の作者も述べています ) 。 1 ) ディスク・プロックとユーザー・プロセスの使用でき る実メモリ 2 ) 物理的なディスク・ハードウェア、スピンドルの数と 種別、デバイスの制御タイプとパス 3 ) 論理的なディスクの配置 とくに、 / p 、 / usr のようなテストに大きな影響を与 えるディレクトリの配置、物理的なデバイスにまたがる ューサー・ファイノレシステム、スワップ・ノヾーティショ かのマシンと比較する場合、そこにはいくっかのヾ落し 穴〃があります。ここでは、これについて説明しておき ンの数と分割。 SIGALRM check : 12 x 5 sec delays takes 66.01 wallclock secs (error ー 10.01 % ) これは、アラームシグナルの精度をチェックするプロ グラム clock の出力です。これが狂っていると、マルチ ューザー・テストでの elapsed time に影響を与える可 能性があります。 以ーーヒの占にハ 玳をつけながら、テスト結果を分析してく ださい。きっと役に立つ情報が得られるはすです。 ロ 落し八にご注思リ MUSBUS のべンチマークテストの結果を用いては I) バーション ます。 UNIX MAGAZINE 1990.11 load は、すべてのユーサーのマシンの使用状況を代表し デフォルトのマルチューザー・テストである work- 2 ) workload には気をつけるようにしてください。 からも変化していくようなので、つねにバージョン番号 しても無意味なので注意が必要です。 MUSBUS はこれ ます。異なるバージョンから得られたテスト結果を比較 V3.3 以降はそれ以前のバージョンとかなり異なってい MUSBUS にはいくつかのバージョンがあり、とくに 、ゝ 4 ) 標準の C コンパイラとオプティマイザ MUSBUS のすべてのテストが C で書かれているの で、 C コンパイラとオプティマイザを改善するとそれが 反映されます。 5 ) スワップとページングのための物理的なプロックサイ ズ テスト・プログラムにはごく小さなものもあるので、 物理的に大きな I / O コストがかかっているかもしれま せん。 6 ) 現在使っている UN Ⅸの特徴 7 ) 実時間測定とフロー制御の正確さ ファイル Results/Iog のなかには、次のようなマルチ ユーサー・テストの開始部分を示す行があります。 ているわけではなく、 C プログラムの開発環境を想定し ています。そこで、 MUSBUS ではさまざまな用途でマ シンを使うユーザーのためにこの workload を書き換 えられるようになっています。、、速く動くマシンを知りた い〃ときは、 workload を自分の仕事にあわせて修正す るか全部を書き換えたほうがいいでしよう。 3 ) リリースの相違 同し UNIX でもリリースが違うと、テスト結果は驚 くほど変化します。同レヾージョンの MUSBUS で同 ーの workload を使ってこのような結果になった場合、 それは UNIX システムのべンダーのチューンアップ ( ダウン ? ? ) によるものです。 4 ) 結果を鵜呑みにしない I) ~ 3 ) でも分かるように、 MUSBUS によるテスト結 果の単純な比較はたいへん危険です。 5 ) メインはマルチューサー・テスト work 以外のテストは補助的なものです。システムの パフォーマンスに興味があるのなら、マルチューザー テストに注目しましよう。 6 ) 少なすぎる疑似ューザー 疑似ューザーが少なすぎると、マルチューザー・テス トの結果はよくありません。重い負荷条件下でのシステ ムのスルーブットとパフォーマンスについての有用な情 報を得るためには、ユーサーの数をさまざまに変化させ てテストする必要があるからです。そうすれば、必要な 31

e $ & 第 0 ee 0 ce MUSBUS 今泉貴史 / 権藤克彦 則回の xbench と xllperf の解説は、いかがだった でしようか ? 「ワークステーションの性能言刊面といって おきながら、あんなつまらない解説ばかりしおって」と いう声が聞こえてきそうですが、実際の面結果を正し く読みとっていただくためにはどうしても必要なお話な のです。 今回も MUSBUS というべンチマークの解説ですが、 もうすこし孑財曼して読んでください。 MUSBUS この欄では xbench や xllperf などの X のべンチマ ークだけではなく、より総合的にマシンの性能を詔面す るために MUSBUS を使用します。これは UNIX シス テムのべンチマーク・テストで、複数のユーサーをシミ ュレートしてテストするマルチューサー・テストが特徴 です。 MUSBUS という名前は "Monash University Suite of Benchmarking UNIX System" の略で、オ ーストラリアの Monash 大学で下記の 2 点を目的とし て開発されました。 ・新しい UNIX システムにおけるポトルネックやパフ ォーマンスの調査 ・競合する UNIX システムを比較できる頑強なテスト 環境の構築 何をテストするのか ? UNIX システムで快適に仕事ができるかどうかの判 断は、実際の稼動状態 ( 多くのユーサーが使っている、な ど ) でのシステムのパフォーマンスに大きく依存します。 ードウェアのスペックである Mips 値などのデータ ロ ロ 26 もある程度の目安にはなりますが、それだけでは↑商さ の度合を測れるものではありません 0UNIX というシス テムは巨大なプログラムの集合体なので、各プログラム の処理能力を合わせた総合的な力に大きく左右されるか らです。 MUSBUS は、 ( いろいろな仕事をおこなう ) ューサー をシミュレートする複数のプロセスを走らせてその実行 時間を計測し、実際の稼動状態に近いシステムの性能を 測定します。 MUSBUS では、このテストを、、マルチュ ーザー・テスト〃と呼んでいます。また、このテスト以 外にも C のコンパイル速度や算術計算の速度など、比較 的単純な速度測定もおこないます。つまり、大きく分け て次の 2 つのテストをおこなうわけです。 ・単純な速度測定 算術計算、再帰計算、システムコール、 C のコンパイ ルとロード、メモリアクセス、ファイルシステムの速 度を調則するテスト ・マルチューザー・テスト 複数の疑似ューザーによる一般的な操作 ( cd 、 ls, cat 、 grep 、 vi 、 cc など ) によるテスト マルチューサー・テスト マルチューサー・テストでは、ユーサーをシミュレー トするプロセスを複数走らせてあらかしめ定められた 一連の仕事〃を実行し、その処理時間を詩 fi 則します。図 1 に記したこのテストの実際の過程を見ながら詳しく解説 していくことにしましよう。 あらかしめ定められた一連の仕事 (workload) とは、 cat 、 ls, grep などのコマンドを集めたもので、デフ ォルトで Workload/script. master というファイルか ロ UNIX MAGAZINE 1990.11

news&notice 0 0 ・ $io 回読み書きする単一のプロセス ( したがってコンテキス ト・スイッチは存在しない ) の速度を則する。 fork の速度の計測 spawn children 100 fork する回数 自分自身のコピーを fork して、子どものプロセスが ( 即座 に )exit するのを待つ。これを単純に $children 回繰り返す。 exec の速度の計測 execl nexecl 100 exec する回数 execl ( ) を使って、 exec を $nexecl 回実行する。 exec さ れるプログラムは、合理的なサイズ (VAX では、 11264 text 十 2048 data 十 24388 bss) に調整されている。 [ 亟咆 : : I : 三 2 : 云を匚 : 区工 2 皿座互亟亜ここ : こここコ "$switchl x 2 ”回のコンテキスト・スイッチ 500 svitchl 同期をとるために、パイプを使って、、 $switch1XX' 回の コンテキストスイッチをおこなう。このテストでは、 2 つの プロセスが 2 つのパイフ。で接続されている。 1 つのプロセス は、 4 バイトを ( 1 すっ減らして ) 書き込んでから読み込む。 これに対して、もう 1 つのプロセスはバイト数を ( 1 すっ増 やして ) 読み込んでから書き込む。読み書きされるバイト数 の値をチェックすると、各スワップごとに同期が正常かどう かが分かる。 C C のコンパイルとロード速度の計測 、、 $cc-ccctest. c" と、、 $cccctest. を実行し、 C のコ ンパイルとロード速度をⅱ則する。 cctest. c は 124 行のコ ードで、 cpp の後だと 108 行になる。 マルチューザーテスト seqmem randmem poke arr ayS 逐次的なメモリアクセス速度の計測 ランダムなメモリアクセス速度の計測 100 , 000 配列へのアクセス回数 8 64 512 配列の大きさ ( x 1 , 024 ) のリスト メモリアクセス速度を言れ則するテスト。整数配列へのリー ドアクセスの速度を 1 秒間隔で言ⅱ則する。ただし、短時間計 測の精度カいために大きなムラが生しやすく、結果を鵜呑 みにしてはならない ( 負や無限の速度が計」されてしまうこ とがある ) 。これは、マイクロプロセッサをベースとしたシス テムにおいて MMU がポトルネックだった時代からの、、古 典的好奇心〃といった程度の意味しかなく、則された時間 自体にはさほどの意味はない。 seqmem は、配列要素を順次 読んでいく逐次的なアクセス・パターンのテスト、 randmem はランダムなアクセス・パターンのテストである。 [ 亟 : 巨之巨互匸二 : 二コ blocks 62 125 250 500 ファイルサイズ (KB) のリスト vhere ファイルが作られるディレクトリ nusers ttys dirs rate 1 4 8 16 24 32 ューー数のリスト /dev/tty Trnp 2 nscripts 4 vorkdir 、 Vorkload 出力が送られる tty デ六イスのリスト 疑似ューザーーが 1 秒間にタイフ。する文字数 workload スクリフ・トなどを置くディレクトリ データファイルなどを置くディレクトリ workload スクリフ・トの数 マノレチュ arit hmet ic system 、 ed ーザー・テスト。 $$iterations/?' 回実行される。 work の単純な・・ 算術テストをすべて実行 システム関連のテストをすべて実行 arithmetic と system のテスト その他のテスト。 x は、 work からファイルシステムのス テータス・レポートと tty のバンド幅チェック、およびクロ ックチェックを除いたテストで、診断目的のためにマルチュ ーサー・テストを使い、最初のハウス・キーピングを必要と するときに便利である。 arithmetic は、単純な算術テスト (arithoh register short int 10g float double (c) をすべて UNIX MAGAZINE 1990.11 ファイルの書込み、読込み、コピー時間を計測する。 く stdio. h 〉で定義した BUFSIZ が、物理的な i/o に対して も十分な大きさであり、すべての i / 0 が read ( ) と write() を直接呼び出せることを前提にしたテストである。このテス トは、、、 $iterations/?' 回実行される。ファイルの書込み時 間は、カーネル内のディスクプロック・キャッシュの大きさ に影響されるので注意が必要である。読み込む前に、 sync( ) を 2 回、 sleep を 5 秒間実行して、キャッシュをフラッシュ する。 は、 arithmetic と system がおこなうテストをすべて実行 contextl spawn execl fstime) をすべて実行する。 speed 実行する。 system は、システム関連のテスト (syscall pipe する。 33

e $ & 0 ee 0 00 図 2 ResuIts/Iog の例 Start Benchmark Run (WSBUS Version 5.2 ) Sat May 12 13 : 41 : 17 JST 1990 ( 10 れ g iterations 6 times) 行できるかどうかのテストです。マシンにもよりますが、 CPU Time: 0.73 seconds [ 0.72u + 0.02S ] (variance 0.007 ) (Actua1 : 0.63 ) E1apsed Time: 0.83 seconds (variance 0.007 ) (Actua1 Arithmet ic Test (type = short ) : 1000 lterations CPU Time : 0.72 seconds [ 0.70u + 0.02S ] (variance 0.002 ) (Actua1: 0.62 ) E1apsed Time: 0.80 seconds (variance 0.000 ) (Actua1 : 0.60 ) Arithmetic Test (type = register) : 1000 lterations CPU Time: 0.10 seconds [ 0.10u + 0.00S ] (variance 0.000 ) EIapsed Time: 0.20 seconds (variance 0.000 ) Arithmetic Test (type = arithoh) : 1000 lterations 3 interact users . 10 ~ 20 分程度かかります 2 。 $ iterations=l $ nusers=l $ export iterations nusers 何ごともなく、、 End Benchmark Run" と表示されて テストが終了したようでしたら、ファイル ResuIts/Iog と Results/log. work を見てみましよう。 Results/log はテスト結果のファイルで、 Reuslts/log. work はエコ ーされたコメント、ステータス情報、疑似ューザーの仕 事からのエラー出力などを収めたファイルです。これら のファイルが正しく出力されているようならテストは成 功です。ただし、 Results/log. work のなかに、変なエラ ーメッセージがないかをチェックしてください。実行が 正常終了していない場合は、対応するプログラムをチェ ックしたり、 workload を修正してみましよう。 本番テスト さきはどのテストは、 MUSBUS が正常に実行するか どうかのチェックでした。つまり、すべてが正しくイン ストールされて実行できることか確認できたわけです。 次は、、本番のテストクの実行です。ます、ルートとして ログインし、どうしても必要なデーモン以外は止めます。 はかのユーサーにもご遠慮いただき、 9 ,600bps 以上で 2 ここでは MUSBUS のマニュアルに従って、 sh を用いた場合を説明してい きます ( プロンプトが $ になっているでしょ ) 。 csh の場合には、•setenv iterations ドなどとしてください。 UNIX MAGAZINE 1990.11 : 0.63 ) 動いていて現在は使用していない端末 ( 以下では /dev/ ttyx) を選び、次のようにテストを開始します 3 。 $ tty=/dev/ttyx $ export tty $ m -f Resu1ts/10g Resu1ts/10g. work $ . /run Results/log と Results/log. work を削除するのは、 新しい結果がこれらのファイルに追加されるからです。 もしこのファイルを必要とするときは、 mv してくださ い。このとき、、 log. 川んツとしておくと、あとで便 利かもしれません。このテストは、終了までにおそらく 数時間を要します。したがって、テストが終了したら、 正常に実行されたかを確認する意味で下記の点をチェッ クしてください。 ・ファイル ResuIts/Iog を検討します。値の著しい不一 致やエラーメッセージがないことを確認し、実行時間 が適正であるかも確認しましよう。 ・ファイル Results / 10q. work は、エコーされたコメン ト、ステータス情報、シェルのエラー出力などを含ん でいますが、エラーメッセージがなければ OK です。 こで、 MUSBUS が出力した Results/log の内容を すこし見てみましよう ( 図 2 参照 ) 。これは、 arithoh と いう算術テストを 1 , 000 回繰り返した結果です。 "elap- sed time" は 0.20 秒で変動なし、 $cpu time" は 0.10 秒でやはり変動なしといったことを示しています。しか 3 複数の tty を指定する場合、 sh ならば tty ="/dev/ttyx/dev/ttyy /dev/ ttyz" 、 csh ならば setenv tty "/dev/ttyx /dev/ttyy /dev/ttyz" など とします。 29

結果を cpu time と elapsed time から計算できます。 ただし、マシンには重い負荷がかかることになるので、 テストには必要以 - ヒに時間がかかるかもしれません。回 速なマシンに対しては、つねに一定数以 -. ヒの疑似ューサ ーが必要になるはすです。 7 ) 多すぎる疑似ューザー 6 ) とは逆に、疑似ューサーが多すぎてもよくありませ ん。環境変数 tty を指定しないデフォルトの値を使う と、すべての疑似ューザーの tty 出力が 1 つの tty に向 けられてしまいます。少ないのがいけないからといって、 マルチューザー・テストでの疑似ユーサーをむやみに増 やしてしまうと、シリアルポートのバンド幅がテストを 遅らせる原因になるかもしれません。ただし、これは ttychk でチェックできます。必要なら、環境変数 tty に いくつかの tty デバイスを追加すれはいいのです。 8 ) 破壊 過去に、マルチューサー・テストによっていくっかの ・ MUSBUS のテスト内容 MUSBUS のテストは、すべてシェル変数によって制御さ れる。同し名前の環境変数を設定すると、シェル変数のデフ ォルト値を変更できる。 とくに指定がなければ、 iterations というシェル変数が繰 返しの回数に用いられる。 iterations のデフォルト値は 6 で ある。以降の表では左側にテスト名、右側にその内容を、ま た、シェル変数の設定が可能なものについてはその下に変数 0 $ & 0 ce 0 c ・ 名、デフォルト値、内容の順に記した。 arithoh register short int long float double 算術計算のオー六ヘッド計算 register を使う計算 short を使う計算 int を使う計算 ng を使う計算 肪 at を使う計算 doub いを使う計算 arithloop 1 , 000 計算のルーフ・数 簡単な算術の計算速度を計測する。さまざまな型を使っ て、呂田 の計算を $ arithlo 叩回おこなう。このテス トの終了後に、 Results / 10g に対してシェルスクリプト /Tool/Adjust を実行する必要がある。これによって、テス ト arith 。 h の計算結果を差し引いた実際の cpu time と elapsedtime が計算できる。ただし、この計算は mktbl あ るいは mkcomp を使うと自動的におこなわれる。 32 UNIX システムか破壊された実績 ( ? ) があります。これ は、テストしているシステムの実現 ( コンフィギュレーシ ョン ) 制限 ( プロセススロットなど ) やシステムのバグ、 MUSBUS のエラーなどが原因とのことです ( 最近はあ まりないようですが ) 。 2 回にわたって、この欄で用いるべンチマークテスト の解説をしてきました。、、どうもピンとこないクという方 もいらっしやるかもしれませんが、気になるマシンのテ スト結果が登場したときにもう 1 度この記事を読み返し てください。チェックの勘所が分かれば、上司や先生に 「 xx 社の〇〇というマシンが欲しい」と強力に主張でき ます。ひょっとすると、あっさり買ってもらえるかもし れません。皆さんにびったりのマシンに出会えるといい ですね。 ( いまいすみ・たかし、ごんどう・かつひこ東京工業大学 ) [ 亟 I : 亜を社可 ー -- 殳的な算術の計算速度を誌則するために、 2 の平方根を dc を使って小点 99 桁まで計算する。 dc の入力は dc. dat を使用する。 [ 工 ! 星亟 ndisk 17 ディスク枚数のリスト 有名な、ノイの塔〃の問題を再帰を使って計算した場合 の計算量は、 2 ディスク枚数の割合で増加する。 ディスク枚数を変化させてその計算速度を計測する場合 には、シェル変数 ndisk にディスク枚数の数字リストを加え syscall システムコールのオー六・、ツドの計測 4 , 000 一連のンステムコールの繰返し数 nca11 5 個のシステムコール ( dup ( 0 ) 、 close(i) 、 getpid() 、 getuid( ) 、 umask (i) ) を $ncall 回繰り返す。これらのシス テムコールは UNIX のカーネル部分にははとんど仕事を含 んでいないので、このテストはおもにシステムコール・メカ ニズムのオーバーヘッドを引則する。 pipe パイフ・の読み書き速度の計測 512 バイト・プロックを 1 つのパイプの初端から末端へ UNIX MAGAZINE 1990.11

図 3 mk 制て作った表の例 Test Date UNIX Version Memory Processor MUSBUS Versionl e s & 0 ce ル 0 ce 20.6 引 0.20 0.60 0.63 0.67 0.68 20.6 引 20.73 Sun3 / 260 れ 0 れ e 5.2 12 May 1990 ー SUN—OS 4.0. 引 図 4 mkcomp で作った表の例 Memory processor MUSBUS Versionl Test Date UNIX Version ー This System ー none m3 / 260 Raw Speed 5.2 12 May 1990 ー SUN—OS 4.0. 引 Abs01ute ReIative T01 VAX 11 / 785 ー 5.0. Beta ー 22 Jun 198 刀 BSD 4.3 8 Mbytes ー FPA Raw Speed F10at Arithmet i c Long Arithmetic lnteger Arithmetic Short Arithmetic Register Arithmetic Loop Overhead Test Description E1apsedl Time CPU ー Time ー ー十 0.76 0.76 0.6 引 0.6 幻 0.16 Re1ative Test Description Loop Overhead Regi ster Arithmetic Short Arithmetic lnteger Arithmetic Long Arithmet ic F10at Arithmetic EIapsedl Time 20.73 0 .68 0 .67 0.63 0.60 0 .20 CPU ー Time ー 0.701 0.701 0.6 引 0.6 幻 0.16 E1apsedl Time 0 .13 2 . 10 1.72 2 .59 1 .87 1 .75 CPU ー Timel 0.1 幻 1.6 幻 1.5 引 2.3 引 1 .4 引 2.26 し、ちょっと見にくいですよしつは、 MUSBUS に はこのファイルから表を作って見やすくする便利なシェ ルスクリプト mktbl 、 mkcomp が用意されています。 れらは、ディレクトリ Tools にあります。 結果を見るには ? mktbl と mkcomp を実際に使ってみましよう。 $ mv Resu1ts/10g Resu1ts/10g. machine $ cp Resu1ts/10g. machine T001S $ cd T001S $ mktbl machine はしめに、 mktbl が CPU 、 FPU などのハードウェ ア・オプション、実メモリ数などについて質問してきま す。これに答えると、〃切 e というファイルができて いるはすです。これは tbl を用いた roff のファイルとな っていますので、画面上で見るには、 $ tbl machine ー nroff ー colcrt ー more —s とします。すると、最初にテストしたマシンに関する情 報を表示して、実際のテスト結果のサマリーを出力しま す ( 図 3 参照 ) 。 2 つの UNIX システムの結果を比較する表が欲しい ときは、 mkcomp を使います。ただし、これで比較でき 30 るシステムは 2 つだけです。 〃 2 〃 C カ / 〃にノ〃 2 〃 C カ / 〃に 2 $ mkcomp 続きます。もっとも重要な処理結果の分析が残っていま これで終了といいたいところですが、残念ながらまだ ことが分かります。 time で 1.75 倍、 cputime で 2.20 倍の速度で処理した ン (Sun) は基準となるマシン (VAX) に比べて elapsed 試みに、、 LoopOverhead" の結果を見ると、このマシ さきほどと同様にして出力を見ます ( 図 4 参照 ) 。 も tbl を用いた nroff のファイルとして作成されるので、 倍の速度で実行したかを示す値が追加されます。こちら 対的な値ーー - 各テストで襯ん切霞が川石 2 の何 え、川 4 に対する襯“怩 2 の使用した時間の相 しては、 4 勧切の elapsed time と cpu time に加 襯“ん切ー”切 e2 が作られているはすです。内容と 2 つのマシン名をハイフンでつないだファイル、 す。 テスト結果の分析 UNIX MAGAZINE 1990.11 然で分かります。しかし、さまざまな要素がテスト結果 ると、どのマシンが速くてどのマシンが遅いかが一目瞭 スクリプト mktbl と mkc 。 mp を使って表を作成す

B A S E X P G 3 信頼性を高る ル ODen フうンディン 第合確ザニビズⅣ SX ソライセンスの販 X / Open の世界的な正式テスト・センタとして認定された 日本ュニソフトては、お客様ご自身て VSX に直接アク UniSoft グループの一員として、日本ュニソフトは国内て、 セスし確認テストを行なえるよう、 VSX のソース・ライセンス 唯一、 VSX(X/Open Verification Suite) を使用した の販売も行ないます。 適合確認サービスを行ないます。このサービスは、お客 ・ライセンスの種類 様の UNIX システムが X / Open ポータビリティ・ガイド 3 カ月使用契約 10 年使用契約サポート契約 ( XPG3 ) に定義されている共通アプリケーション環境 ・契約は、日本ユニソフト仲介により X / Open と締結して (CAE : Common AppIications Environment) に適 いただきます 合しているかどうかをチェックするため、一連のテストプロ ・インストール・サービスおよびトレーニング・コース ( 3 日 グラムを実行するものてす。 問 ) も用意していま魂 NIJC は、国内で 30 におよぶ LJN Ⅸシステムの移植を手掛けてきました。蓄積した ノウ八ウをベースに、今後とも IJN Ⅸシステムを中心とした基本ソフトウェアの移 植・開発、 Ve 「 ification を通して、お客様にトータル・ソリューションを提供してい きたいと考えていま魂当社営業部にお気軽にこ相談ください。 * X / 0 1 は、 X / 0 障 1 Company L t の商標です。 * UN Ⅸオペレーティング・システムは、 UN Ⅸシステムラボラトリーズ社カ第発しライセンスしています。 技術者募集中 日本ユニソコト株式会社 〒 102 東京都千代田区三番町 8 ー 7 第 25 興和ビル谷 03 ( 237 ) 3321 代 FAX. 03 ( 237 ) 3322

HP SoftBench ェクトではプロトタイピングをおこなう必要があったので、 ライプラリの機能を追加したり変更したりしたときには何も かもピルドし直すような手間をかけす、ただちに変更部分を テストしたかった。 この問題は、ツールのリンクを実行時まで遅延させること によって解決した。ダイナミック・ローダが外部シンポルの 解決とコードの再配置をアプリケーションのロード時におこ なうのである。このリンクステップは、すべてメモリ内でお こなわれるのできわめて高速である ( 1 ~ 2 秒 ) 。また、ツー ル自体はリンクしていない状態の標準的な . 0 ファイルとし てディスク上におけばよい。 ツールの起動方法 前述のような決定の結果、すべての HP SoftBench ツー ルはダイナミック・ローダと各製品に共通のライプラリコー ドすべてを含んでいる単一の大きなテ々ンド・ローディング 可能なプログラムを実行することによって起動されることに 信頼性モデルの応用 HPSoftBench チームは、システムテスト段階におけるデ ータ収集工程に統計的信頼性モデルを取り入れることによ って、コードの現在の品質レベルの把握と一定の品質レベル を達成するまでに要する時間の推定を的確におこなうことに した。このモデルは Kohoutek の研究 [ 1 ] にもとづいてお り、さらに Musa 、 Okumoto 、 GoeI らの研究成果 [ 2 ] [ 3 ] を 参考としたものである。同様のモデルは、 HP のはかの事業 部でも使用されてきている [ 4 ] [ 5 ] [ 6 ] 。また、このモデルにつ いての情報は Doug Howell [ 7 ] から得たものである。 基本的な考え方は、対数ボアソン実行時間モデルを時間軸 と検出欠陥数のプロットに適用するというものである。時刻 t ( 単位は時間 ) において検出済みの欠陥数 u(t) は、次の式で 与えられる。 こで、日は基準イレヾラメータであり、えは欠陥検出率で ある。 テスト時間に対する検出欠陥数のグラフへ各週ごとの新た なデータポイントを書き込む際、非線形最小一乗法反復法を 使用して実際のデータにもっとも近い u ( t ) 曲線が得られる ような日とえを見つけ出した。開始当初から、この曲線は実 際のデータの各点にきわめてよく一致していた。 基準化パラメータ日は、 t を無限大に近づけた際の関数 u ( t ) の限界値、すなわちこのモデルによって予測される製品 社の = 日 ( 1 ー e 60 なった。このプログラムは、 HP SoftBench 製品の一部分と なるまでは runprog と呼ばれた。どの HPSoftBench ツー ルも runprog を明示的に実行させることができるが、さら に内部の処理を隠蔽する簡単な仕掛けがある。つまり、 HP- UX の ln コマンドを用いて runprog にさまざまな工イリ アス ( 別名 ) を - 与えるのである。もちろん runprog は 1 個し かないわけだから、各 HP SoftBench ツールは事実上この コマンドのたんなる別名ということになる。 runprog は起動 されたときの名称 ( argv [ 0 ] ) を調べることによってどのツ ールを実行すればよいかを判断し、次にその名称に . 0 という サフィックスを付・与し、ダイナミック・ローダを起動する。 このようにして、 HP SoftBench ツールははかのすべての HP - UX プログラムやシェル・スクリプトの場合と同様に実 行することが可能となったのである。 Sam Sands ソフトウェア開発工ンジニア Softweare Engineering System Division 中の欠陥数である。この日の時間に対する一定性は興未深い キ題であったので、以下でさらにこの点について説明する。 u(t) の 1 次導関数は、ある一時点における欠陥検出率であ る。検出率の逆数は時刻 t における瞬間的な平均欠陥検出間 隔 (MTBD) であり、次の式で表される。 この方程式を用いれは、与えられた MTBD がいつ達成さ れるかを各週ごとに予測することが可能になるのできわめて 便利であった。当プロジェクトでは、日およびえの現在の値 にもとづいて t に関してこの方程式を解くことによりさまざ まな値の MTBD を得た。さらに、各週ごとに言当求してきた テスト時間の平均で除算することによって、 t を時間単位か ら月日単位に変換したのである。 これによって、設定された目標値と等しい MTBD の瞬間 値が達成される日付の予測を週ごとに設定することが可能と なった。また、最初のあいだは 6 ( 予測値 ) の変動が観察され たため、以後は u ( t ) を別のデータに適合させることにした。 すなわち、重み付けのない生の欠陥数 ( テスト時間に対する欠 陥数 ) のプロットにもとづいて日を計算する代わりに、フィ ルタ済み加重欠陥と名づけたものを用いることにした。これ は、重複した報告やたんなる改善要求を言 t 算対象から除外し、 各欠陥をプロジェクト・チームがそれぞれに割り当てた重大 度 ( 0 から 1 までの率 ) にしたがって加重処理したものであ MTBD = 1 / が ( の = ( 1 / /\ ) い” UNIX MAGAZINE 1990.11

01a 、 NCR 、沖電気、 Olivetti 、 Unisys の 協力を受けて開発中。 ◆高信頼度 / 対称型マルチプロセッサ完全 対応 : 1992 年。 Sequent の協力を得て開 •OMRON 発、 Pyramid 、富士通、 lntel 、 AT&T オムロン (Tel 03 ー 5488 ー 3253 ) は、 OSF / Computer Syste11E ICL MotoroIa 、 Motif を日本語化した「日本語 Motif 」を Unisys からもサポートを受けている。 RISC WS LUNA-88K の OS 、、 Mach" ◆ OSI 対応 : 1991 年上半肌 OSI のコミ に組み込み、販売を開始した。 ュニケーション機能とアプリケーションに Mach への Motif の組込みは国内では 対応。 Retrix と共同で開発中。 初めて。日本語入力には Xwnmo と Wnn ◆遠隔オペレーション / 保守管理 : 1991 を使用 0Xmnmo は MIT が進めている X 年上半期。 ウインドウの国際イけ寸応に準拠しており、 日本語 Motif 系旧ムみの Mach OS の価 Wnn を拡張した中国語対応の cWnn と 格は 220 , 000 円。 X / Open 適合テストツール 組み合わせれは中国語の入力・表示も可能。 機械系 / 電子系 CAD システム 日本語 Motif •NUC HP9000 シリーズ用機械系 CAD システ 日本ユニソフト (Tel 03 ー 237 ー 3221 ) は、 ム、、 HPME シリーズ〃を、同社以外の WS X/Open PortabiIity Guide (XPG3) へ や PC に移植、電子系 CAD システムの の適合テストツール VSX クのソースコー 横河・ヒューレット・パッカード (Tel 03 EDA 分野における標準化推進に貢献する ドの国内販売権を取得、販売を開始した。 ー 331 ー 6111 ) は、 CAD 市場における同社の ため、 Mentor Graphics 社、図研、 Cadens X / Open の公式テストセンターとして、 戦略を発表した。 Design Systems など有力 EDA べンダ XPG3 適合確認サービスもおこなう。 すでに 4 , 000 本の販売実績がある ーとの業務提携を強化する。 VSX のライセンス価格は、 3 カ月で 800 , 000 円、 10 年で 320 万円。適合確認サ PC 用 NFS ーピスは、 3 日以内でテスト完了の場合は 800 , 000 円、以降 200 , 000 円 / 1 日。 0 N ET ON E X Ⅱ .4 テクニカル・ ネットワンシステムズ (Tel 03 ー 798 ー ンド・プロセスとしてほかのアプリケーシ ドキュメント日本語版 5561 ) は、 NFS を PC から利用するソフト ョンと一緒に動作できるため、サーバー専 ・創夢 ウェア「 PC-RFA 」の販売を開始した。 用機が不要で既存の UNIX マシンをその 創夢 (Tel 03 ー 770 ー 3234 ) は、現在英語 PC-RFA は、 NFS が稼動するミニコン まま NFS サーバーとして利用できる。 や WS などのハードディスクやプリンタ 対応機種は、日本電気の PC98 シリー で提供されている X11.4 のドキュメント ( 全 7 巻 ) を邦訳、販売を開始した。 を PC で利用できるようにするソフトウ ズ。 構成は、 Vol.0 : 移植ガイド / リリース・ ェア。 UN IX のファイルシステムをもとに 価格は 58 , 000 円 (Ungermann ー Bas 設計されているため、ディレクトリ / ファイ ノート ( A4 / 244P 、 27 , 000 円 ) 、 V011 : 標 製の TCP-PC ソフトウェア付が 78 , 000 準プロトコル ( A4 / 400P 、 43 , 000 円 ) 、 ルごとにアクセス権を設定できる。また、 円 ) 。販売予定は初年度 5 , 000 本。 NFS のサーバープロセスはバックグラウ V012 : コマンド・リファレンス・マニュア ル ( A4 / 260P 、 10 , 000 円 ) 。 「 Xlib ー C 言語 X インターフェイス」 ( V01.3 ) 、「 X ツールキット・イントリンシ ックー C 言語インターフェイス」 (Vol. 4 ) 、をアテナ・ウィジェット・セット—C 言 ・テクトロニクス (Tel 03 ー 779 ー 語インターフェイス」 ( V01.5 ) の各巻は作 7602 ) は、 X 端 KTekXpress ファミリー 成中、「ライプラリ・リファレンス・マニュ 4 機種の販売を開始した。 アル」 ( V01.6 ) は近日発売予定。 IYHP カラー X 端末 —TEKTRONIX ディスプレイと本体が分離したカラー モデル XP29 型 / XP27 型 / XP25 型の 3 機種、モノクロモデル XP23 型の 4 機種。 5 UNIX MAGAZINE 1990.11

ら作られます 1 。実際のテストでは、シェルスクリプト mkscript によって、、 scrip. ″襯厖というファイルが 複数作られます。このファイルの内容は、 Workload/ script. master にあるコマンドの順番を適当に入れ替え たものになっています。 MUSBUS のテストはシェル変数によって制御され ますが、同し名前の環境変数を設定すればデフォルトの 値を変更できます。たとえば、作成するファイルは環境 変数 nscript で設定した個数 ( デフォルトでは 4 ) だけ 作られます。ちなみに、シミュレートするユーサー数は 環境変数 nusers( デフォルトでは 1 4 8 16 24 32 ) に よって設定します。 Workload/script. master の内容は できます。 % % 4 compile cat cat . dat % % 3 cat ls ー 1 % % 2 ls 幻Ⅱ temporary chmod u + w t emporary keyb edscrl. dat ー ed % % 1 edit mkdir /tmp/$$ tmp export PATH PAIH=XXX : $PATH % /bin/sh -ie 次のようになっています。 UNIX MAGAZINE 1990.11 新・ $ & 新 0 ee 0 ce 図ー MUSBS ペンチマークの実行過程 edit . dat 1 はかの sc ⅵ pt ・ master を選択したり、このファイルを自由に作成することも script. master scnpt.2 mkscript script. 3 script.l user0 process userl process user2 process Resultsnog user3 process user4 process Tmp/workload directions user0 mn/sh -ie <script. 1 >/dev/ttyO userl /bin/sh -ie く script.2 >/dev/ttyl cc —c cctest . c 1 > & 2 % % 5 edit , compile and 1i1 ⅸ chmod 444 dummy. c keyb edscr2. dat ー ed dummy. c cc dummy. c 1 > & 2 a. * grunt. c % % 6 grep grep ) [ ] *nwork' grep. dat % % 7 file copying cp *. c edit. dat /tmp/$$ cp /tmp/$$/* tmp rm -rf tmp /tmp/$$ このファイルは、次の規則に従って書かれています。 1 ) 最初の行はコマンド・インタープリタのフルバス名 で、 % W % で始めなければならない。 2 ) % % で始まる最初の行までは、すべてのスクリプトに 共通な初期化部分である。 3 ) % % で始まる行にはさまれたコマンドの列は、 1 つの ジョブステップである。通常、これは複数存在するが、 任意の順序で実行可能な独立した仕事でなけれはなら 4 ) % % で始まる最後の行以下は、すべてのスクリプトに 共通な事後処理部分である。 5 ) 1 つの % で始まる行はコメントである。 この Workload/script. master から作られるファイ 0 27