|
|
 |
|
   
|
||
|
Disk cache量について、benchmarkテストを施行し、4Mbyteが最も高速であるが(P<0.0001)、心配されたオーバーヘッドによる有意な速度差は認めず、4Mbyteから8Mbyteに最適点が有ることが予想されました。 そこで、実際にアプリケーションを使用したベンチマークテストを施行することにしました。差がよく出るように比較的ディスクアクセスの多いアプリケーションを選択して実行することにしました。 選択したアプリケーションは英文翻訳ソフトであるPC-Transer/ej Ver5.0j(1で、基本辞書、医学辞書、自然科学辞書を合わせ約70Mbyteを使用します。2802語の医学文献を自動翻訳するのにかかった時間を計測しました。計測は条件を統一するため、キャッシュ容量以外は変更せず、再起動から決められた方法で行いました。また、翻訳順によって計測値にばらつきが出ないように、数度行った平均を求めました。  単位は秒です。結果はdisk cache容量を8160Kbyteにした場合が最も高速で、4096Kbyteに比べ13%高速でした。以上よりアプリケーション使用環境ではディスクキャッシュ容量を最大に設定することが有効です。搭載メモリが256Mbyte以下では8160Kbyteよりも低い値がデフォルトで設定されます。128Mbyte以上のメモリを搭載することが珍しくない今日、8160Kbyteに設定し直すのは有用かと思われます。 さてディスクキャッシュ容量を大きくした場合、何か不都合はないのでしょうか。最近の報告を調べると関係するアーティクルが少なからず存在します。 まずMacOS 8.5発表当時に報告されたキャッシュと非同期書き込みの不具合について言及する必要があるでしょう。これは初めMacintoshトラブルニュースの中で1998年11月15日に、ファイルメーカーデーターベースを使用するような大量の非同期I/O処理を行うと、マシンがフリーズすると報告されたことに端を発します。回避方法として、ディスクキャッシュを最小に設定するようにFileMaker社が回答していることも同時に伝えました(2。 こののち、1998年11月25日にPowerBook 100's World Newsにおいてさらに詳しく、仮想メモリを使用するときは288Kbyteを越えるディスクキャッシュを越えると不具合が発生し、仮想メモリを使用しないときは1.5Mbyteを越えると不具合が生じることを伝えています(3。 この、ボリュームに多くの非同期書き込みをしたときのメモリエラーに関しては、既にMacOS 8.5.1において改善策がとられいます(4。 また、PowerBook 100's World Newsにおいて1999年3月22日にAppleShare IP 6.1の動作不安定の解消法として、ディスクキャッシュを512Kbyte以下にする方法が提案されています(5。今後の観察が必要なようです。 ここで、キャッシュ容量とアプリケーションのエラーに関して、昨日Appleより「Mac OS 8.5: Unable To Install With Large Disk Cache」が公開されました。これはMac OS 8.5インストール時に「"DFA Server"がメモリ不足で読み込めずインストール出来ない」として、インストールが中断する不具合に対しての対処法として、インストールディスクを起動するときシフトキーを押すことで、ディスクキャッシュを最小に設定するという対処法が紹介さています(6。Macintoshトラブルニュースにおいてこのことに関し追試が行われましたが、シフトキーでの起動においてもPRAMに記憶されたディスクキャッシュ量を最小にオーバーライドできない、最小量は96Kbyteにはならず128KByteであるなど、表記自体に疑問が有るとのコメントがありました。 この不具合はおそらくメモリ不足に起因するものであり、非同期書き込み時の問題再燃と考える必要はないかもしれません。おそらくMac OS 8.5以前のシステムでは問題ない大きめのキャッシュが設定された状態で、メモリ要求の高くなった8.5システムを起動したとき、（ディスクキャッシュはPRAMに記憶されているため引き継ぎます）システム容量が逼迫しインストーラーが作動しないことに由来すると考えられるからです。 暫くディスクキャッシュを最大に設定し不具合がないか調査していきたいと思います。
|
||
|
||
|
Disk cacheをどのくらいに設定していますか？MacOS 8.5はそれまでの7.Xと違い、OS推奨のcache容量を自動的にセットしてくれます。しかし、最高8160Kbyte以上には設定できません。 多ければ多い程良いのでしょうか？例えばハードディスクと同じ量のキャッシュがあればキャッシュミスは存在せず非常に高速にアクセスが出来るでしょう。多ければ多いほど良いという結論に達します。 しかし、現実問題それほどの多量のDisk cacheを用意することは出来ません。特に「最強の〜」のセットのように内蔵ハードディスクが14GByteともなると、最高8MByteのDisk cacheは全体量の0.06%にも満たないものです。また、各アプリケーションの肥大化もすすみ、ますますcashミスが多くなっています。 cacheミスが生じた場合、cache処理のためのオーバーヘッドが大きければ大きいほど、処理速度が低下することが予想されます。そこで、cache量を変化させディスク性能を調べることにしました。 目的：PowerBook G3 333/14においてIBM Travelstar 14GS(DCYA-214000)に最適なDisk cache量を調べる。 方法：Disk cacheを2048Byte、4096Byte、6144Byte、8160Byteにそれぞれ設定して、MacBench 3.0(1を使用し転送速度を測定した。512byte,1Kbyte,32Kbyte,64Kbyte,128Kbyte,1Mbyteのファイル転送においての、Sequential Read、Random Read、Sequential Write、Random Writeについて調べた。調査は条件を近づけるため再起動から決められた手順で測定した。 対象：PowerBook G3 333/14、（CPU 333MHz,L2 cache 166MHz、RAM 256MByte）、にIBM Travelstar 14GS(DCYA-214000)を搭載し、拡張HFSフォーマット後、パーテーションは2つとした。MacOS 8.5.1(J)に機能拡張書類としてROM Accelerator、LibMotoSh、Speed Doubler 8.1.2を追加している。 統計：Disk cache量における順位を決定するために、ノンパラメトリック検定のFriedman testを選択した。また、Disk cache量とRead、及びWrite速度の変動を調べるために、交互作用を念頭にいれrepeated mezsure ANOVA（重複測定、分散分析法）を行った。 結果： 
危険度（P<0.01%）でそれぞれのDisk Cache量において、速度順位に有意な差が存在し、4096KByteに設定したときがもっとも高速である。  それぞれの値を仔細に調べると、cache容量での速度差は有意なものとは言えない。（P=0.5046) Read時と、Write時の速度差にはcache容量の違いで有意な差が有った。(危険度P<0.05%、P=0.0277)  分散分析表をグラフにすると、キャッシ容量を2024KByteにしたとき、他に比べ有意にRead時の性能が低下することが判る。 結論：キャッシュ容量の違いでは、アクセススピードに有意な差は生じないが、ディスクキャッシュ量を小さくするとRead時とWrite時に有意な速度の差が生じる。そのことを念頭に入れ、もし順位をつけるとすると、4096KByteに設定した場合が最も処理速度が速いと言える。 微妙な結果が出てしまいました。もし順番をつけるとすると4MByteにセットするのが一番早いのですが、思ったほどの差がありません。しかし、小さくすると有意にRead時の性能が落ちるので、おそらく4MByte以上にセットするのがよいと思われます。後は4Mbyteと8Mbyteでのフィーリングの違いを、使いながら見ていくしかないようです。ベンチマークテストと実際の使用状態に差がある今回の場合、実験モデルに問題があったと結論づけるしかないでしょう。しかし、良い問題提議になったと思います。数字よりフィーリングを大切にすべきであるという丹羽氏の言葉(2が思い出されます。
|
||
|
||
|
PowerBook G3 Seriesの熱対策はこれまでも何度か取り上げてきました。きっかけは熱暴走のエピソードです(1。このことは逆にキーボードとヒートシンクの接触が、いかに放熱に重要なものであるのか気付かせてくれました(2。 具体的にシリコンシートをどこに貼っているか図に示します。fig.1のオレンジ色の矢印、3カ所に20mm×20mm角、厚み0.2mmのシリコンシールを貼っています。この場合、熱伝導用シリコンシートの粘着力はそれほど強くないものを選択する必要があります。キーボードとヒートシンクの接着性があまりに高いと、キーボードの取り外しが困難になるばかりではなく、キーボード基板の思わぬ故障の原因なります。 純正の放熱は、上部のヒートシンクだけではなく、下部に放熱シートに連結したシリコンシートが三カ所存在します。Heathrow用、RAGE LT Pro(RAGE LT II)用であり、特に赤い矢印で示すグラフィックアクセラレーターのシートは放熱に重要な役割を演じています。 
fig.1 ヒートシンクの熱伝導シリコンシート添付場所について また、図ではわかりにくいですがグラフィックアクセラレイターのすぐ近く、ピンクで示す場所に放熱用の電動ファンが存在します。このファンはDie-junction温度とは無関係に作動します。 ヒートシンクに追加したシリコンシートがどの程度役に立っているかは議論の余地がある部分ではありますが、冬季に行った実験では効果があると考えられます(3
|
||
|
||
|
去年の10月22日に、MacOS8.5がMacOS 8.1に比べ、その体感スピードが悪化したことに気付き、ベンチマークテストを施行しポリゴン描写の速度が低下したことを指摘しました(1。 Norton System Info(2を使用したベンチマークテストを元に当時の雑誌記事などで、「8.5はネィティブ化率が上昇し処理速度が向上した」と表記していました。当時のこの結果は、それらと反するものであり非常に印象的でした。 「最強の〜」を構築する課程で、現在のシステムはMacOS 8.5.1(J)にROM Accelerator 1.2bとSpeed Doubler 8.1.2を組み合わせ(3、さらにLibMotoShを加え(4、アプリケーションレベルで良好な性能を発揮しています。 ここで、再びMacBench 3.0(5を使用して問題のベンチマークを再検したいと思います。  これは、PowerBook G3 300/14、キャッシュクロック150MHz、32bit colorでの値(300/8.1)と、同じハードウェア構成でMacOS 8.5の時の値(300/8.5)、CPU 333MHz 、キャッシュクロック166MHz、32bit colorでMacOS 8.5.1に上記の3つの機能拡張を読み込ませたものを(333/8.5.1+roam+speed+motlib)を比較した値です。明らかにFramePolyは改善していますが、InvertPoly及びPaintPolyはそのまま取り残された値を示しています。  次に体感部分で大きな割合を占める文字描画ルチーンを見てみると、Mediumサイズ、及びLargeサイズでのMacOS 8.5での改悪が見事に8.5.1で元のレベルまで戻っていることが判ります。 ベンチマークがそのままアプリケーションレベルの速度を示すとはもうしませんが、古いバージョンのOSの軽快さが少しでも取り戻されたことは賞賛すべきでしょう。
|
Medical macintosh (c) 1998,1999,2000,2001,2002
Written/Edited by Y.Yamamoto M.D.
ご自由にリンクして下さい。トップページへのリンクも併記して頂けるとありがたいです。