2004/12/31(金)memtestログ
2004/12/31 19:00
環境
CPU:Athlon XP 1700+(多分苺皿)
M/B:A7V333
V/B:Sapphire Radeon 9200SE Atlantis(地雷)
テスト対象メモリは２枚で去年春に購入したPC2700 CL2.5、今月末に購入したPC3200 CL3。画像は左に掲載する。共にチップはinfineon,512MBである。なお、みればわかるが共にJEDEC非準拠。
さて、
PC2700,PC3200のメモリとも１枚差しFSB166(PC2700)動作において
CL2.5-3-3-6 エラー無し
CL2-3-3-6 エラー無し
CL2.5-2-2-5 POSTせず
となった。まずいことにA7V333にはCL3や甘めの設定がない。By SPDとするしかないのだ。またFSB200(PC3200)での動作は保証されていないため、単独メモリのテストにおいてこれ以上できることがない。いや多少無理させれば出来るのだが、切り分けがめんどくさくなるので今回パス。
次に２枚のメモリを差してチェックしたところ、FSB166(PC2700)動作において
CL2.5-3-3-6 Test#6(Moving Inversions)でエラー多発
By SPD Test#6(Moving Inversions)でエラー多発
となった。この結果はスロット位置を何通りか変えて試してみても変わらなかった。
そして２枚のメモリを差した状態で、FSB133(PC2100)動作とすると
CL2.5-3-3-6 エラー無し
CL2-3-3-6 エラー無し
By SPD エラー無し
となった。
結局この２枚のメモリとA7V333の組み合わせではPC2100として動作させるほか無いということになった。
原因考察。まずA7V333がBy SPDでもCL3になってない可能性がある。スロット位置を変えてBy SPDにすればCL3になってくれるかと思ったが速い方に追随しているのかもしれない。確証はないが。
さてそもそも、PC2700 CL2.5+PC3200 CL3ならPC2700 CL2.5で動くんじゃないのという話もある。両メモリとも１枚差しならCL2で動いたことを考えると、若干のマージンはあるだろう。infineonチップは素性の確かさに定評があり、設定を緩めにすれば相当高クロックまで伸びることが知られている。従って基盤が問題なのではないかという疑いが強い。そも電子回路は「動くなら」コンデンサ・抵抗が少なければ少ないほど特性が良くなるはずである。しかしタイミング合わせが厳しいDDR SDRAMにおいてはコンデンサが重要な役割を果たす。その所為で高品質なメモリ＝コンデンサチップが多いという図式が出来てしまったほどだ。てことはコンデンサがスカなPC2700のほうが怪しい…… か。ここらへん、高くてもそこそこいいメモリを買った方が良い、異種メモリとの組み合わせが厳しいというDDRの定説を実証することになってしまった。
さてどうするかであるがPC2100 <-> PC2700の速度差は実質上体感にほとんど影響を与えない。またA7V333ではPC3200に挑戦する気はない。となると、別に今の通常使用としてはこのままで問題ないとする。後は単に自己満足として原因の切り分けを行いたいという願望と、今後CPU+M/B更新においてこの組み合わせでは使い物にならないだろうという問題だ。いつ変えるかは結局値段次第になってしまうので、何とも言えない。DDR2がまだまだ来ないと言えるなら、同じメモリに揃えた方が良いのには違いないのだが。買って売るなら差額2kほどだが、まあもちろんテスト時間や移動時間があっはっはになる。迷うな。
なおCPUは1.5V->1.25V,1.47GHz->1.0GHzの切り下げ駆動をしているがこれに関してエラーとの相関関係は認められなかった。
2004/12/29(水)nicky + waa 注意点
2004/12/28 26:00
waa用のjavascriptは普通にフッタに書けばいい。が、nickyの仕様ではフッタ中のエスケープシーケンス(\")が飛ぶらしい。
文字列中の\"が飛ぶとまあ想像に難くないだろう。読み込んだときにスクリプトエラーが出て改行コードがありませんとかいわれる。
ヘッダフッタファイルはnickyディレクトリ中の、
nickyHFdat.cgiが元データ、
nickyHF.cgiが表示用データ、
だがこの２ファイル、私の使用法ではエスケープシーケンスが飛んでしまう以外に差異がない。ということで、nickyHFdat.cgiをnickyHF.cgiに上書きコピーすればこの問題は直る。
なお、フッタ更新時には毎度この作業を行う必要がある。
2004/12/27(月)ZoneAlarm + VMware相性
2004/12/26 27:00
結論から言うと、ZoneAlarmとVMware内の何らかのプロセスが衝突していたらしい。
taskmgrでプロセスをCPU使用率をwatchしたところ、ZoneAlarmの実体であるところのvsmon.exeが数秒ごとにCPU100%を占有している。
←こんな感じ。
VMware関係プロセスのvmnat.exe、vmnetDHCP.exe、vmware-authd.exeあたりをつぶすと、これが収まった。
現時点でVMwareを使用する予定はなくなっていたので、vmwareごとアンインストール。
解決。
なお、ついでにZoneAlarmを5.5系にupdate。
フリーであるが故の面倒さではあるが、自動アップデートにしてくんねえかな。ダメだろうな。
2004/12/20(月)微妙に不安定Thunderbird
2004/12/19 27:00
1.0もリリースされて久しい頃に、0.8-0.9に関する不満を書くのもどうかと思うが、1.0でこれが解決されてたら凄くうれしいなということでメモに残しておこうと思う。へたれなので1.0は日本語版が出てから試すことにする。
なおメインで使ってるのは日本語版0.8であるが、無印0.9も試した。以下の点に関しては0.9での改善は見られなかった。
・検索で良く落ちる
再現性がないので報告も何もあった物ではないが、条件を複数にしたとき、検索をし直したときなどに非常に落ちやすい。日本語文字列を使ったときも落ちやすい気がするが、今ひとつ自信なし。
・不正なメールの日付が狂う
バグでも何でもない仕様なのだが、受信日時で管理できた方が送信日時で管理するよりもOEに慣れた身としてはありがたい。ThunderBirdでは受信順という管理方法があるが、いまいち見づらいのとインポート時に綺麗に並んでくれいなため個人的には不満。送信日時で並べると2100年に来た友人のメールが先頭に来る。おまえ１人だけ世紀末か！
・消したメールがデータファイルから消えていない
これは管理システムを把握してないので一概に文句を言って良い物か分からないのだが、或るフォルダにメールを入れたあとに別のフォルダにそのメールを移してもメールボックスファイルの中に移したファイル・消したファイルが残っているようなのである。せっかくの生っぽいデータなのだからきちんと消すようにして頂けると色々出来てありがたいという話。
・その他
よく分からないタイミングで落ちる。不正っぽいメールはきちんと解析してくれない（こちらが正しい？ 就職情報系のメールがいくつかall?になった）。
文句はつけたが、現時点でフリーメーラーとして最高レベルの出来であることは間違いない。これからも頑張って欲しいもの。
2004/12/17(金)Nicky調整してみる
2004/12/17 18:00
右フレームはNicky!の本体のヘッダとフッタにdivを書いて、左揃えで600px位で囲ってやる。
左フレームに検索フォーム搭載。
あー、これあとカテゴリ機能さえつけば私の要望全部満たしてるわ。コミュニケーションツールである必要はない。どうせ発信だけで手一杯だし。
2004/12/15(水)華式リファ欄のリンクがずれています
2004/12/15 16:00
ちょっとホント対策考えないと。ダメだ華式。
作者さんいい人だしサポートも真面目なんだけどな。……バグは多い。
2004/12/14(火)Virtual PC 2004 Trialを使ってみた
2004/12/14 5:00
ちなみに、目的はというと昔やってたゲームのデータを確認したくなったがWinXPじゃ動かんー という話。
さて感想。
1.実機より遅い
ホスト側に普通にOSをインストールする方が早い。当たり前だという声もあるかもしれないが、エミュレートすることによって低速デバイスが加速する部分もあるはずで一概に確実に遅くなるとは言えない（はず）。だがまあこいつはだいたい遅い。マウスポインタ、ディスクアクセス、その他もろもろホストの能力の1/3～1/4位の感覚になる。
2.サウンド滅茶苦茶
音に関しては相当酷い。ブツ切れるし、このMIDIの酷さは久方ぶり。PC-98 + ソフトウェアMIDIより多分悪い。
3.バックグラウンドにすると遅くなる
Virtual PC固有だと思われる。バックグラウンドにすると途端にフォーマットなどが進まなくなる。今ひとつ使い勝手が悪い。
結論、使えるか使えないかというと”将来性に期待”というところか。マルチOSは決して勧められる物ではないが、ガチャポンあたりで余りHDD１つ使えるのなら実機にインストールした方が万倍良い。下手すると、Annex86+Win95あたりに負けるかも。Grandaleだかなんだか、ハードからのバーチャル化の方が早いかもしれない。
ただしこのソフトがやたら遅いのは、相当低レベルまでいちいちエミュレートしてるからだという話なので、動くOSの多さという点では強いのだろう。Unix系もおそらく動く。有り余るCPUパワーの下で、OSの互換性を保って作業というシチュエーションでは強力か。
2004/12/14(火)華式（Kshiki）Updateのやり方
2004/12/13 25:00
KShikiの場合は、スタイルシートで全部色を変えたり出来ないので一苦労である。
1.全バックアップ
とりもなおさず、現在動いてる奴を全ファイルバックアップ。
2.転送
最新版を/data,/GraphixAをのぞいて全て転送。転送は普通に行えばいいが、sjisの所為かsamba経由だと上手くいかないことが多い。WinSCPで。パーミッションは継承されるので、多分問題ない。
3.書き換え
具体的に書き換える必要があるファイルを以下に挙げる。ここでの「書き換える必要がある」とは、私が自分のサイトで使うために色変えなどで書き換えているファイルを含んでいる。
KshikiconfigD.cgi - デザインファイル。記事のボーダーカラーなど。将来的にはこれとスタイルシートで全部いじれる？
KshikiconfigP.cgi - パスワード関係ファイル。タイトル等。
KshikiFormMain.html - 外形生成ファイル。タイトルのバックカラー、ログインフォームの場所など。
KshikiFormParts.html - 検索フォーム、カレンダー等のバックカラー。
上記４ファイル。どうも散逸してるのが気になる。今回は差分を残しているので、どこを書き換えているか次回ExamDiffで直ぐ分かるはず。
以上３ステップで終了。
なお、画像のアップロードに失敗する問題はa50にしたところ直った。が、なんか記事追加時に消去ボタンしかでなかったりする。どうにもKshikiはバグが多い。おまけに遅い。
2004/12/06(月)数式->画像
2004/12/05 26:00
Texで１から書くのはいかにもめんどくさい……
ということで、Microsoft数式エディターをPowerPointで使い、「図として保存」コマンドでjpg or gif or pngで書き出すのが楽だろう。
なお、この「図として保存」コマンドは背景色が設定されていないと黒ベタ画像を吐く。
つまり、
- 挿入->オブジェクト->Microsoft 数式3.0
- 開いた数式エディタWindowで編集->終了
- オブジェクトの書式設定->色と線->塗りつぶし->色：白
- オブジェクト選択->右クリック->図として保存
という手順になる。保存時のサイズ調整・パレット選択等は出来ないが、PowerPoint上での拡縮は比較的まともに動くのでサイズが合わなかったら目分量でサイズ変えて再出力。
JustSystemやOpenOfficeの数式エディタもさわってみたけれど、手早くということならMSのをWord or PowerPointで使うのが一番使い易かった。
花子あたりでMSの数式エディタが扱えれば良かったのだが、Word,PowerPoint以外だと数式エディタの挙動が変わり、この状態になるとどうも怪しい。BackSpaceが効かなくなることもあるし、編集終了すると画像に固定されるようで、拡縮がうまくできなくなる。
まあそんな感じで。数式が複数出現する文書とかなら、まあやっぱりTexなんだろうな。余程のよれが無い限りTexはあと１年ちょっとで永久卒業。数式コマンドを全部覚えてーなんて考えは持たないようにしたい。WinShell,EasyTexは使えるのかいな…… 次回チェックだな。
知り合いからMimeTex.cgi（Texの数式を画像にしてくれるcgi）を使ってはどうかと勧められた。自サーバにおいて、数式を張りたいところに数式コマンドとリンクを書く。
うーん、それがいいやり方の１つだというのは納得できるがイマイチしっくり来ないのはなぜだろう？ 外部画像がいやなのか。amazonだったらOKなのに？ 著作権問題があるから納得できる？
それと１つ書きたいときというのがたいてい自分であれこれ考えながら数式を書いているときだというのがある。wysiwygじゃないと使えないのだ。あとはCってのはどうなんだろうな。このサーバ潰れたら外部リンクだよな。
2004/10/18(月)WOL断念
2004/10/17 26:00
ここで一応区切りをつけて断念することとする。
さて、進行状況を書いてみよう。
・リモートからの電源断・再起動・休止・スタンバイはどのマシン->どのマシンでも可能
・電源オン・スタンバイ復帰は個体差が大きい
・VersaPro VA80J/VH(Nintz)においては、電源ON・休止状態からの復帰が可能
・自作PC（ikumi）においてはスタンバイからの復帰のみ出来たり出来なかったり。あとは不可
・VAIO(型番忘失）においては復帰・オン全て不可
特にikumi(M/B A7V333)に関しては
LCI-TXI(intel 82558)
GBE-PCI(VIA VT6122)
それぞれについて調査したが、状況は変わらなかった。
さてWOL成功の可否は以下の要素による。
・M/B
・電源
・NIC
・OSおよび電源管理方式
相性問題もあるのだがPCI Rev2.2以降、2.1以前どちらであるかで状況が変わる。Rev 2.2以降のM/B+NICならば、WOLケーブルが必要なく、それ以前のRevであるとWOLケーブルがないとWOL出来ないと思ってよい。少なくともLCI-TXIはここに引っかかっている可能性が高い(WOLコネクタ有り、マニュアルにはRev2.0以降と記載）。
また電源がATX2.01対応（5VSBがある程度の電流を確保していること。諸説あるが0.75A Over?）であること。
さて、ikumi上での大きな問題として、
デバイスマネージャ－LANアダプタのプロパティ
「このデバイスで、コンピュータのスタンバイ状態を解除できるようにする」以下の２チェックを入れると、スタンバイ・休止で再起動してしまう。これは、あらゆるパケットでNICがwakeしている可能性と、何らかの相性問題が悪さしている可能性がある。これのチェックさえ通れば、休止からの復帰は出来そうだ。
LCI-TXI,GBE-PCI 共に発生していることから、M/Bが悪いのかもしれない。M/B・電源・NICでクロステストをするのが原因の切り分けへの最短ルートだろう。まあそんな時間はないので、exit。うへえ。
※その他現象。BIOSでPower ControlのPCIから起動をONにすると電源が切れずに再起動する。ここらへんもM/Bがあやしいと思う理由。
<参考>ネットに落ちているWOL情報は古かったり、微妙なものが多い
http://www001.upp.so-net.ne.jp/hwada/
http://plaza.across.or.jp/~kusunoki/wol_1.htm