冷徹なる炎

ふと冷静になったとき、無駄なことをしている自分に気付きました。


X31でSATAのSSDが使用可能になった以上、プチフリSSDと付き合い続ける理由は消失しましたが、このままFlashFireのテストに突入します。（ここで挫けると、このブログの存在理由まで消失するかも）

本体内蔵がTS32GSSD25-Mで、ウルトラベイ2000にFTM28GL25Hを搭載したので、DiskPartを用いて物理的な接続順位を確認しました。"Disk 1"となっています。

今回はOpenFlashFireのf0002に再挑戦です。インストール後、再起動せずにレジストリを書き換えます。自前の支援ツールで"DiskNum"を0から1に変更しました。私の場合は0にもプチフリSSDが存在するので危険はありませんが、この設定を間違えると起動不能になるので慎重に行って下さい。

再起動後のベンチマークです。前回同様に意味も無くCrystalDiskMarkの最新版です。

4Kのランダムライトに効果が見て取れますが、体感上の差は感じられません。シーケンシャルライトの低下は、バッファを設けたことによるオーバーヘッドかと思われます。

前回との比較のために、4KB3万個の解凍を行ったところ、6分でした。

時間の短縮と同時にCPUの使用率も上昇していますが、解凍中であっても他のアプリは起動できました。

offmon.exeによる監視情報です。

BufferSizeが8MBから12MBに自動可変しています。最大値は256MBですが、解凍中でも12MB以上になりませんでした。メモリは1GB積んだので、エコな精神は捨てて欲しいところですが。

ちなみに、3万個をごみ箱に捨てると、やっぱりプチフリです。

C300、Intel、Indilinxを保有する今となっては、どれでも搭載可能です。ただ、せっかくX31にJMicronが2基という夢(?)のようなテスト環境を整えたので、しばらくはFlashFireの行く末を見届けたいと思います。もっとも、立て続けに本体が故障したおかげで、このような事態になったわけで...

不治の病、そして義体へ

「攻殻機動隊」のように機械任せで換装できれば、こんな苦労はありません。一時は、ゴーストを失ったかと思いました。


TS32GSSD25-Mのファームアップに伴いUDMA2病を抱えてしまったX22が、さらに骨折する事態に。

液晶のヒンジが金属疲労で破損しました。X20の時代には部品センターよりヒンジを取り寄せましたが、バッテリーの消耗も厳しい状態なので、今回はX31に乗り換えることにしました。以前に、無線LANを交換した機体です。

まず、作業前にIAAおよびOpenFlashFireを削除、XPのリカバリーをしたX31からIBMTOOLSのフォルダをSSDにコピーしました。ただし、X22はWindows 2000のままです。X22のSSD換装の際に、X31用のマウンタを流用していたため、交換作業に問題はありません。

無駄だと思いつつX31で2000を起動したところ、幸運にもデスクトップまで辿り着きました。もちろん、解像度はVGAのままですが。OSインストールの手間が省けたので、ソフトウェア導入支援に任せて各ドライバを自動でセットアップしました。これが良くなかったわけで...

再起動後、ThinkPad機能設定を用いたところ、突如リセット。しかも、レジストリ破損で2000自体が起動不能に。どうやら、2000に適合しないバージョンのドライバまで勝手に導入されたようです。バックアップフォルダからレジストリを書き戻しても、起動中にブルースクリーン。CD起動でシステムファイルの修復を試みましたが、効果無し。

そこで、セカンドHDDアダプターからXPを起動、ファームアップ時のバックアップに使ったHDDをUSBで接続、システムフォルダ（WINNT）を強制的に上書きしました。

その後、2000は無事に起動し、アプリケーションやデータを失わずに済みました。改めて、Lenovoから2000用のドライバをダウンロードし、ソフトウェア導入支援を使ったところ、全てのセットアップが無事に完了しました。


それでは、お約束のベンチマークへ。過去との比較のため、CrystalDiskMarkは旧バージョンです。

ようやく、カタログどおりの性能に戻りました。

X31のスペックのおかげか、FlashFire無しでも体感速度は格段に向上しています。

劣化もしていないのに、Defragglerの空き領域のデフラグを。

当然ですが、ほぼ変化無し。（無駄なことをしたおかげで、むしろ下がったかも。）

OpenFlashFireはその効果が芳しくないので、旧来のFlashFireの0.a0を投入。BufferSizeも64MBに設定しました。

4Kのランダムライトは眉唾です。平均的には10MB/s弱の結果となります。

新ファーム（090331）の効果かもしれませんが、FF無しでもX22の時ほどの支障は感じられません。ただ、2000の起動時間や起動直後の動作には確実に効果があるので、危険を覚悟でこのまま運用します。ちなみに、EASEUSを使って再びパーティションのコピーを作成しました。


今回は、もう一つ持病完治の報告があります。バッテリーのメタボを再発したMacBookですが、銀座のアップルストアで交換してきました。知人の陶芸個展を訪れた際に、立ち寄りました。2度目ということで無償交換となり、無事に現役に復帰しました。TigerやLeopardの可動機として、今しばらくは頑張ってもらうことにしましょう。

ハイリスク・ローリターン

昨日の文末に勝手なことを書いておきながら、舌の根の乾かぬうちにFlashFireに挑戦です。


OpenFlashFireとしてオープンソースになったそうです。初期バージョンには重大なバグが有り、その修正とBufferSizeの自動可変機能を実装して、現在はf0002となっています。

こちらがダウンロードしたファイルの内容です。32bitのXPのみの動作確認だそうですが、Windows 2000のX22でやってしまいましょう。ちなみに、sysとinfがドライバ本体でoffmon.exeは監視ツールです。（ただし、offmon.exeは動作しませんでした。）

そして、レジストリ。BufferSizeは8MBから動作を開始し、最大値の初期設定はMaxBufferSizeの256MBです。

ファイル名やレジストリの変更に伴い、当ブログ謹製の支援ツールおよび削除ツールも修正しました。（※旧来のFlashFireには使用できません。）

OFFREGchg.zip

それぞれのスクリプトファイルが含まれています。（スクリプトで不都合な場合は、コメント欄にご報告下さい。実行形式にコンパイルします。）

ファームアップの一件以来、UDMA2病を発症したままですが、ベンチマークを見るまでもなくプチフリしまくりです。そのことが4Kのランダムライトに如実に表れています。もちろんFF無しの状態と比較すれば、効果は確実にありますが、と同時に期待外れであることも否定できません。

スタンバイも動作し、今のところ不具合は無いものの、どうも0.a0以降の開発が良くない方向へ進んでいる印象があります。オープンソースになったことで、今後の発展に期待しましょう。（残念ながら私の頭ではVBScriptが関の山...）


（7/15追記）　恐いもの見たさでLiveUpdate実行...　仮死状態が1時間ほど続きました。

（8/20追記）　offmon.exeを使って無効にするflushとdeadlineのレジストリの設定値を調べました。Optionの値が

2でflush無効
4でdeadline無効
6で両方無効

となります。それぞれ信頼性向上のための機能で、パフォーマンス低下の原因かもしれないと開発者は述べていました。ただ、私の環境では無効に設定しても効果は...

炎が産み出すもの Teacupβ版

βどころかα版と言うべきものですが...

人生初陶芸における3客の湯呑みの本焼きが完了しました。それぞれ、別の釉薬を掛けて還元焼成（灯油窯）しましたが、選択に失敗した感が否めません。

これは青磁釉。

素地が唐津土ですから、青くならずにこの有様です。

続いてそば釉。

そば猪口にしか見えません。

黒の化粧土に透明釉を掛けました。

全て暗色なので、変化に乏しいものばかりです。

何事も練習が肝心なので、今後も様々な釉薬にチャレンジしてみましょう。


せっかく炎の話なので、FlashFireに関して少々。

先週、SSDをファームアップしたX22で、Windows Updateを敢行しました。もっとも、私の環境では深刻なプチフリを起こしたことはないので、あくまで確認のためです。

当然のようにFlashFireのバッファは100%になりますが、他の動作も継続できます。新ファームの恩恵か、少々軽くなったようです。（気のせいかも）

ついでに、UDMA2病の再確認。

IAAの2.3Betaを使いました。（2.3の正規版はモバイルチップセットが対象外）　80芯ではなく40芯として検出されているので、確定診断されてしまいました。

この記事を書いている最中に、10.6.4のアップデートも実行しました。

私の場合は約300MBでしたが、Combo Updateなどは900MB近くもあり、1GBを超える日も遠くはないでしょう。

SEG CLIPの音多出力や、LS-L500GLにSMB接続できない問題は依然として残りましたが、SEG CLIPに関しては

http://barry-tangram.blogzine.jp/tangram_pieces/seg_clip/index.html

こちらのブログを参考に解決しました。（御尽力に感謝します。）

スクリプトも用意されていましたが、作業の実態を知るために私は手動で行いました。

反転表示させた3つのファイルをコピーするだけなので、フォルダ名を見て階層を辿って下さい。

システムプロファイラを見たら、TRIMサポートの項目が増えていました。画面はC300ですが、crucialのフォーラムではCT128M225でも"いいえ"と表示されるそうです。（こちらにもCT64M225があるのに、確認をサボりました。）

ただし、上記の2機種は当ブログでも速度の自動回復を確認しているので、TRIMの必要性が薄れています。X25-M (G2 160GB)は劣化したままなので、機会があれば確認してみましょう。（現在はLeopardのままです。）

ぜひ、アップル純正のSSDを搭載されている方の報告を伺いたいと思います。

バイオハザード...発症

私はジャン・レノだけでなくリュック・ベッソン関連の俳優が好きなので、この映画も劇場へ足を運びました。ミラ・ジョヴォヴィッチ演じるアリス自身が実験体だったという設定でしたが、当ブログの実験体Xを待つ運命とは。ちなみに、エンディングに登場したSlipknotのベーシストが死亡したと報道されたのは先月のことでした。


今回は、どちらかと言えば私が引き起こした人為的な事故です。

トランセンドのサイトには4/13付でTS32GSSD25-Mのファームウェアが登録されていましたが、Macと違いWindowsのバックアップは面倒なので躊躇していました。私のX22はWindows 2000であり、リカバリー領域もあります。そのため、セカンドHDDアダプターに入れるIDEの80GBと、リカバリー領域の復旧ディスクを準備しました。

まずは、安全のためにFlashFireをアンインストールします。

私は自前の改造版(0.a0)を使っているので、同時に添付したDeleteFF.vbeを使います。

その後、FDDから起動したPartitionMagic 6.0（骨董品）で80GBのHDDに、NTFSおよびリカバリー領域のクローンを作成しました。

アップデートツール添付のPDFには起動可能なUSBメモリにコピーするように書いてありましたが、私はFDDの起動ディスクにコピーしました。ただし、AUTOEXEC.BATのドライブ指定はC:なので、A:に変更する必要があります。

出来上がったディスクから起動すると、自動的にSSDの検出が行われ、データ消去の警告と作業続行の確認待機になります。

バックアップ済みですから、そのまま"Y"を入力しましょう。

FDDなので多少時間はかかりますが、無事にファームが080827(V0826)から090331に更新されました。

再び、PartitionMagicを用いてバックアップを復元します。ただし、パーティションをコピーしただけではリカバリー領域の起動メニュー(F11)が表示されないので、ここで復旧ディスクを使ってメニューも復元します。

JSMonitorを使ってS.M.A.R.T.の確認です。

Erase Countは維持されていますが、なぜかMECが減少してAECに異常に接近しています。

また、Block Countがそれぞれ4減少しています。

FlashFire無しのCrystalDiskMarkです。過去との比較のために、あえて2.2を用いました。

必要も無いのに危険物に手を触れた罰でしょうか、ついに発症しました。UDMA2病が...

逆に、今まで発症していた人はこのファームで改善されるかもしれません。

ちなみに、このままでは2000の起動も遅く、IEを起動するだけでプチフリの状況にも変化はありませんでした。

気を取り直して、FlashFireを導入。BufferSizeも64MBに再設定しました。

やはり、全体的に成績が落ち込んでいます。ただし、バッファから溢れた場合のプチフリ症状は、明らかに軽減されていました。以前のファームで4KB3万個の解凍を実行すると、途中でほぼ止まった状態に陥りますが、今回は瞬間的なプチフリを繰り返しながらも、解凍は継続されていました。

不幸にも（自業自得?）UDMA2病を発症しましたが、本体がポンコツのために、シーケンシャルの落ち込みによる目立った影響は出ていません。これで、NortonのLiveUpdateがスムースになれば、満足のいく結果と言えなくもないのですが、例によって最新の状態だったので結果は数日お待ち下さい。


P.S.　LiveUpdateの週次更新により約4.7MBのダウンロード、そして...　やはり駄目でした。更新終了までの時間は幾分短縮されているようですが、依然として他の動作を巻き込んでしまいます。

開設一周年記念FF特番

この類いのお題目の番組やDVDに限って、内容はただの総集編だったりしますが...

...すみません、私もやってしまったのでお許しを。


せっかくの一周年ですが、とくにネタも無く、このところ停滞気味のFlashFireに関する記事のリンクをまとめておきたいと思います。（crucialのC300も貸してくれないかなあ...）

とにかく、FlashPoint時代からの全ての記事をご覧になる方は、こちらのカテゴリーの最下層からお読み下さい。


各種設定用の支援ツール　（32/64bit共通です）

FlashPoint用　通常はVersion 2.2をお使い下さい。

FlashFire用　こちらはVersion 2.2からの修正です。


削除ツール

FlashPoint用　32/64bit共通でVersion 2.0をお使い下さい。

FlashFireはインストーラ付属なので、プログラムの追加と削除からアンインストールできます。私がインストーラを撤去した改造バージョンには"DeleteFF.vbe"を添付したので、ダブルクリックして使って下さい。（各バージョンで別なので流用禁止）


各パラメータ解説

Flush : コメント欄に質問があったので説明させて頂きました。

ClusterSize : 根拠はありませんが、効果があるので変更しています。

Option : FFの無効化と、Cluster paddingの設定です。

WriteBypass : 0.9f以降で追加、一定量以上の書き込みをバッファしない。

BufferSize : 0.a0で32MBの制限が無くなりました。


FlashFire改造バージョン

0.99 64bit : インストーラの設定ミスとドライバ署名のため、開発者のサイトの物は起動しません。

0.9cおよび0.9d : Windows 2000で使用するため、インストーラを撤去。

0.9f : 私の環境には最も適合していたかもしれません。

0.a0 : 2/4現在最新。バッファを64MBで運用中。


番外編

TurboSSD　64bitでFFと比較しましたが、まだβ版のときなので参考までに。


これで全てではありませんが、切りがないのでこの程度で。ブログ左上の全文検索や右サイドバーのカテゴリーを活用すれば、必要な情報に辿り着けると思います。

「Wham!」の似合う季節に

この時期の定番ソングと言えば、「Last Christmas」です。皆さんご存知のように、この曲は織田裕二もカバーしていますが、「踊る」の新作も楽しみですね。個人的には、Wham!の曲では「Freedom」のほうが好きですが。


突然、FlashFireの0.a0がアップされました。（バージョンを16進数にしなくてもと思うのですが...）　前回の0.9fが8月の末ですから、沈黙の間に夏から冬になってしまったわけです。例によって32bitのXPに制限されているので、Windows 2000で使用するためにインストーラを解体しました。（正直言って、手順を忘れかけていました。）

FlashFire0a0_inf.zip

インストーラを使うと2回のダイアログが出ますが、ともに「はい」を選択した場合の設定にしてあります。実際にはFlushとWriteBypassの設定なので、詳しくはリンク先をご覧下さい。

こちらは、標準設定のベンチマークです。

直前の状態より、若干低下が見られます。

ClusterSizeを2048に変更しました。

いつもと違い、効果がはっきりしません。そこで、4096に戻しました。

今回のアップデートの内容に、バッファを32MB以上に設定できるとあったので、BufferSizeを32から64に変更しました。

64MBのバッファに対し、100MBの範囲のベンチマークですから眉唾なところもありますが、一定の効果はあるようです。4KB3万個の解凍は約12000個でバッファから溢れました。ちなみに今までは3〜4千個でプチフリです。

その後、128に設定したところffcntl.exeが強制終了してしまったので、しばらくは64MBで運用することにしました。スタンバイも正常に作動します。


残る期待はNortonのLiveUpdateですが、これのプチフリさえ解消されれば私の環境での問題はほぼクリアになります。すでに最新の状態だったため、今日は検証できないので結果は数日お待ち下さい。


P.S.　某所からcrucialのSSD (Indilinx 64GB)をお借りしたので、MacでのファームアップやErase Countの変動などを調べてみたいと思います。


（12/24追記）　LiveUpdateにより約3MBのダウンロードと解凍、そして更新が始まると間もなくバッファが100%に...　やはりLiveUpdateは鬼門のようです。

情報は鮮度が命

「せっかくの情報も鮮度が落ちちゃ、役に立たねぇ。」とは、公安9課のバトーが張り込み中に言った台詞です。

今回の記事の反省点でもあります。

私がその情報に気付いたのは、つい先日のことなので2ヶ月遅れです。FlashFireのフォーラムに、開発者が"Cluster padding"の機能について投稿したのが8/1でした。SSDのコントローラに実装されるべきバッファ管理のアルゴリズムを、FlashFireとして外部実装したものだそうです。しかし、開発者の所有するKingstonのSSDでは逆に性能を低下させてしまうようで、0.9c以降は無効になっています。ParametersのOptionが"2"に設定されていたのがそれです。以前の記事では大きな勘違いをしていました。

ところが、彼のSSDはJMicronをベースに東芝がカスタムしたものなので、我々のプチフリSSDとは事情が異なります。そこでX22の0.9fで実験です。


まず支援ツールでOptionを"0"に変更。

これでCluster paddingが有効になります。

変更前より4Kのランダムライトが向上しました。

速度で定評のあるBeta3Patch1を完全に凌駕しています。

こちらはATTO Disk Benchmarkです。

ClusterSizeの変更では効果が反映されませんでしたが、今回も同様です。ただし、実用上は明らかな違いが感じられます。

ちなみに、Mac miniに入れた64bit版では標準値が"0"なので、試しに"2"にしてみましたが、いまいち効果がはっきりしませんでした。


今回は大変鮮度の悪い情報になってしまいましたが、本家のフォーラムでも効果の有無がはっきりしていないので、あえて記事にしました。役に立ったでしょうか。

境界線を求めて

マドンナの曲に「Borderline」があります。ベストアルバムにも含まれる名曲の一つです。曲だけでなく、ご本人も境界線を越えた世界に住んでいらっしゃいますけどね。


FlashFireの0.9fでは64KBを境に書き込みがバイパスされることを書きましたが、この境界線が私の環境にとって適正であるとは限りません。他にも疑問を持たれた方がいらっしゃると思いますので、検証してみましょう。

今回はATTO Disk Benchmarkを用いました。設定は初期値のままです。

まず、FlashFire無しの場合。

ライトの成績が64KBの位置でほぼ上限に達しています。つまり、これ以上の領域でバッファを設けても効果が見込めないことが予想できます。バッファ処理がオーバーヘッドとなり、むしろ成績が悪化するかもしれません。

そして、FlashFireを使った場合。ClusterSizeは2048です。

64KB未満の領域でライトの成績がきれいに上昇しています。ただし、リードは若干下がっているようです。

支援ツールでWriteBypassの値を2048に変更しました。1024KB以上でバイパスされることになります。

グラフを見ても明らかなように、64〜512KBの成績が悪化しています。このことから、64KBを境界線とすることが適正であると判りました。

ちなみに、このブログではClusterSizeを2048に変更することが慣例となっていますが、その効果をATTOで確認してみました。

これは、初期値である4096に戻したときの結果です。

期待に反し、明確な違いは確認できませんでした。

念のため、CrystalDiskMarkで計測をしました。

こちらの結果と比較すれば、明らかに効果が確認できます。

もちろん、実際に効果が体感できるから変更しているわけですが、ベンチマークに関しては適材適所ということでしょうか。


今回はFlashFireのチューニングを2点ご紹介しましたが、他にも例がございましたらコメント欄に投稿して頂ければと思います。

FlashFire解体新書

0.9fがアップされました。ステータス表示と64KB以上の書き込み要求はバッファをバイパスする機能を追加したそうです。

犠牲になるのはWindows 2000のX22ですから、先日のようにインストーラを解体しました。

FlashFire09f_inf.zip

レジストリに"WriteBypass"の項目が増えています。

開発者の説明は64KB以上でしたが、値が128であることの関連はよく分かりません。（8/27追記　512byteのセクター数だそうです）

ステータス表示です。ffcntl.exeに追加された機能ですが、常駐させるとパフォーマンスが若干低下するので、普段は必要無いでしょう。

512Kのランダムライトが少し低下しましたが、それ以外は良好です。

バイパス機能のおかげでしょうか、バッファが溢れてしまうタイミングも多少は改善されています。

今のところ、0.9dと比較してもトラブルは無いので、このまま運用を続けます。幸いなことに、私の環境ではファイルやレジストリの破損が起きたことはありません。