2004/12/31(金)memtestログ

2004/12/31 19:00 PC(全般)
新しく買ったメモリが素直に動いてくれなかったので、テスト結果等をメモしておく。

環境
CPU:Athlon XP 1700+(多分苺皿)
M/B:A7V333
V/B:Sapphire Radeon 9200SE Atlantis(地雷)

テスト対象メモリは2枚で去年春に購入したPC2700 CL2.5、今月末に購入したPC3200 CL3。画像は左に掲載する。共にチップはinfineon,512MBである。なお、みればわかるが共にJEDEC非準拠。

さて、
PC2700,PC3200のメモリとも1枚差しFSB166(PC2700)動作において
 CL2.5-3-3-6 エラー無し
 CL2-3-3-6 エラー無し
 CL2.5-2-2-5 POSTせず
となった。まずいことにA7V333にはCL3や甘めの設定がない。By SPDとするしかないのだ。またFSB200(PC3200)での動作は保証されていないため、単独メモリのテストにおいてこれ以上できることがない。いや多少無理させれば出来るのだが、切り分けがめんどくさくなるので今回パス。

次に2枚のメモリを差してチェックしたところ、FSB166(PC2700)動作において
 CL2.5-3-3-6 Test#6(Moving Inversions)でエラー多発
 By SPD Test#6(Moving Inversions)でエラー多発
となった。この結果はスロット位置を何通りか変えて試してみても変わらなかった。

そして2枚のメモリを差した状態で、FSB133(PC2100)動作とすると
 CL2.5-3-3-6 エラー無し
 CL2-3-3-6 エラー無し
 By SPD エラー無し
となった。

結局この2枚のメモリとA7V333の組み合わせではPC2100として動作させるほか無いということになった。

原因考察。まずA7V333がBy SPDでもCL3になってない可能性がある。スロット位置を変えてBy SPDにすればCL3になってくれるかと思ったが速い方に追随しているのかもしれない。確証はないが。

さてそもそも、PC2700 CL2.5+PC3200 CL3ならPC2700 CL2.5で動くんじゃないのという話もある。両メモリとも1枚差しなら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(水)AWStats導入記

2004/12/29 4:00 PC(Linux)
そういやAWStats入れてなかったな(過去1回挫折)と思いだして、入れてみることにする。

dselectで入れてみたが、なんかどこに入ったのかよく分からない(あとで見直してみたら/usr/lib/cgi-bin/に入っていた気配)。
アンインストールしてやり直すことにする。

なお、参考サイトは↓、とても充実。
http://cyberam.dip.jp/linux_server/log/awstats60_main.html

手順ログ。
1. perlのバージョンをチェック - 5.8.3 OK
2. httpd.confのログ記録方式をチェック - combined で変更の必要なし。
3. AWStats6.2 stableをダウンしてtar -xvzfで展開。
4. 解凍したディレクトリのwwwroot/cgi-bin中のファイルをawstats.model.confを除いて設置箇所に転送。
5. mkdir /etc/awstatsして、wwwroot/cbi-bin中のawstats.model.confを/etc/awstatsに転送
6. mv /etc/awstats/awstats.model.conf awstats.conf.org
7. cp awstats.conf.org awstats.conf
8. awstats.conf書き換え

51c51
< LogFile="/var/log/httpd/mylog.log"
> LogFile="/var/log/apache/access.log"

147c147
< SiteDomain=""
> SiteDomain="dt8.jp"

197c197
< DirData="."
> DirData="/var/www/cgi-bin/awstats/awstats_db"

206c206
< DirCgi="/cgi-bin"
> DirCgi="/cgi-bin/awstats"

216c216
< DirIcons="/icon"
> DirIcons="/cgi-bin/awstats/icon"

455c455
< SkipHosts=""
> SkipHosts="REGEX[^192\.168\.]"

862c862
< Lang="auto"
> Lang="jp"

9. 解凍したディレクトリのwwwroot/iconディレクトリを設置箇所に転送。
10. 設置箇所のディレクトリに任意名のdbディレクトリ(awstats_dbとした)を作成。
11. cron設定で、cron.houlyディレクトリにawstatsの更新スクリプトを書いて設置。

なお、cron.hourlyが無かったのでmkdir /etc/cron.houlyして、/etc/crontabに

01 * * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cro
n.hourly

を追加。本当はこのままだとログのローテートに引っかかって記録されないログが出てきてしまうが、まあ今回はこれで良しとしておく。

静的なリンクのみでファイルを吐く方法もあると思うのだが調べていない。その場合、awstats.plはwwwエリアから隠せる。こんなんで、セキュリティ大丈夫だろうか……

それにしてもconfigがでかい。このサイズだと私のemacsの腕では編集が大変である。guiっぽい管理ツールの導入をそろそろ考えた方が良いのだろうか。むーん。

2004/12/29(水)nicky + waa 注意点

2004/12/28 26:00 PC(全般)
nicky中にwaa(website access analyzer)を張り込むときの注意点。というよりも、正確に言えばJavaScriptを張り込むときの注意点か。

waa用のjavascriptは普通にフッタに書けばいい。が、nickyの仕様ではフッタ中のエスケープシーケンス(\")が飛ぶらしい。

文字列中の\"が飛ぶとまあ想像に難くないだろう。読み込んだときにスクリプトエラーが出て改行コードがありませんとかいわれる。

ヘッダフッタファイルはnickyディレクトリ中の、

nickyHFdat.cgiが元データ、
nickyHF.cgiが表示用データ、

だがこの2ファイル、私の使用法ではエスケープシーケンスが飛んでしまう以外に差異がない。ということで、nickyHFdat.cgiをnickyHF.cgiに上書きコピーすればこの問題は直る。

なお、フッタ更新時には毎度この作業を行う必要がある。

2004/12/27(月)ZoneAlarm + VMware相性

2004/12/26 27:00 PC(全般)
PCの動作がここのところ重かった。定期的に数秒ごとに重くなる感じ。
結論から言うと、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 PC(全般)
Mozillaプロジェクト系列フリーメーラーThunderbird。
1.0もリリースされて久しい頃に、0.8-0.9に関する不満を書くのもどうかと思うが、1.0でこれが解決されてたら凄くうれしいなということでメモに残しておこうと思う。へたれなので1.0は日本語版が出てから試すことにする。

なおメインで使ってるのは日本語版0.8であるが、無印0.9も試した。以下の点に関しては0.9での改善は見られなかった。

・検索で良く落ちる
 再現性がないので報告も何もあった物ではないが、条件を複数にしたとき、検索をし直したときなどに非常に落ちやすい。日本語文字列を使ったときも落ちやすい気がするが、今ひとつ自信なし。

・不正なメールの日付が狂う
 バグでも何でもない仕様なのだが、受信日時で管理できた方が送信日時で管理するよりもOEに慣れた身としてはありがたい。ThunderBirdでは受信順という管理方法があるが、いまいち見づらいのとインポート時に綺麗に並んでくれいなため個人的には不満。送信日時で並べると2100年に来た友人のメールが先頭に来る。おまえ1人だけ世紀末か!

・消したメールがデータファイルから消えていない
 これは管理システムを把握してないので一概に文句を言って良い物か分からないのだが、或るフォルダにメールを入れたあとに別のフォルダにそのメールを移してもメールボックスファイルの中に移したファイル・消したファイルが残っているようなのである。せっかくの生っぽいデータなのだからきちんと消すようにして頂けると色々出来てありがたいという話。

・その他
 よく分からないタイミングで落ちる。不正っぽいメールはきちんと解析してくれない(こちらが正しい? 就職情報系のメールがいくつかall?になった)。

文句はつけたが、現時点でフリーメーラーとして最高レベルの出来であることは間違いない。これからも頑張って欲しいもの。

2004/12/17(金)Nicky調整してみる

2004/12/17 18:00 PC(全般)
フレーム化して左フレームに一覧とカレンダー。
右フレームはNicky!の本体のヘッダとフッタにdivを書いて、左揃えで600px位で囲ってやる。
左フレームに検索フォーム搭載。

あー、これあとカテゴリ機能さえつけば私の要望全部満たしてるわ。コミュニケーションツールである必要はない。どうせ発信だけで手一杯だし。

2004/12/17(金)perlの処置

2004/12/17 14:00 PC(Linux)
per.5.8を入れた理由を思い出した。どうやらmysql関係のlibが5.8じゃないと動かなかったらしい。
さて、
・5.8系と5.6系はバイナリ非互換とかなんかそんな話。
・debianのstableはほとんどが5.6系依存で固められている。
・が、5.8でないと動かないソフトもある。(mysql関係等)
・個別コンパイルすれば、5.8系でまとめることは可能。

という線らしい。しかしなんかやだなあ。PHPじゃあるまいし……

とりあえず、よくよく考えてみたらmod_perlを入れる意味というかmod_perlちゃんと動く気がしないので止めて、見なかったことにした。今のうちのサイトで動いてるCGIはグローバル変数の初期化・お掃除をちゃんとやってる気がしない。dirtyなCGIをぽこぽこ実験するサイトなのだから、mod_perlで動かないのが出てくると切り分けがややこしいしストレスチックになる。かといって、拡張子変えたりLocation切り分けで棲み分けるのもなんだかばかばかしい。

とりあえず、このままほっておいてパッケージで入るものだけで頑張ろう。どうしてもmakeしなきゃいけないものはやるにしてもね。

2004/12/16(木)apache死亡事件顛末 in perl5.8 <-> perl5.6.1

2004/12/16 17:00 PC(Linux)
apacheを殺してしまった問題。

一番最悪の殺人方法で、apacheのパッケージを削除してしまった。

原因。なぜ入れたのかは覚えていないが、現在インストールされているのがperl-5.8(unstable)。で、perl-5.6系でないと動かないパッケージを入れようとしたところ、dselectの依存解決に任せていたら、↓こんなことになった。

The following packages will be REMOVED:
aalib1 abiword abiword-common abiword-gtk abiword-plugins apache
apache-common apache-dev apache-utils apel ark asiya24-vfont autoconf
automake css-mode defoma docbook docbook-xml dpkg-dev emacs21 fontconfig
gconf gdk-imlib1 gdm gnome-s gnome-bin gnome-common gnome-core
gnome-libs-data gnome-panel gnome-panel-data gnome-session gnome-terminal
gnome-users-guide gs gs-common gsfonts gsfonts-x11 html-helper-mode
imagemagick imlib-base imlib1 jdk1.1 jvim-canna kab kaffe-pthreads karm kate
kcalc kcharselect kchart kcoloredit kcron kde kdebase kdebase-audiolibs
kdebase-libs kdelibs3 kdelibs3-bin kdepasswd kdepim-libs kdf kdict kdm kedit
kfind kformula kfract kghostview khexedit kiconedit kinput2-canna-wnn kit
kivio kjots kmail knewsticker knode knotes koffice koffice-libs konqueror
konsole kontour korganizer korn koshell kpackage kpaint kpm kpresenter
kruler kscreensaver ksirc ksnapshot kspread ksysv kterm ktimer kugar kuser
kview kword lbxproxy libapache-mod-ruby libarts libdbd-mysql-perl
libdbi-perl libfontconfig1 libgconf11 libgdk-pixbuf-gnome2 libgdk-pixbuf2
libgimp1.2 libglade-gnome0 libglade0 libgnome-vfs-common libgnome-vfs0
libgnome32 libgnomeprint-bin libgnomeprint-data libgnomeprint15
libgnomesupport0 libgnomeui32 libgnorba27 libgtk1.2 libgtkxmhtml1
libimage-size-perl libkdenetwork1 libkmid libkonq3 libmagick5
libnet-daemon-perl libplrpc-perl libqt2 libungif4g libwmf0.2-2 libxaw7
libxft1 libxft2 mc-common mew mozilla mozilla-browser mozilla-mailnews
mozilla-psm mysql-client mysql-server nessus openssl perl perl-modules php4
php4-dev php4-mysql proftpd proftpd-common proxymngr psfontmgr rep-gtk rpm
sawfish scrollkeeper secpolicy sgml-base sgml-data skk skkinput
ttf-xtt-wadalab-gothic ttf-xtt-watanabe-mincho twm vflib2 watanabe-vfont
x-ttcidfont-conf x-window-system x-window-system-core xaw3dg xbase-clients
xdm xemacs21 xemacs21-basesupport xemacs21-bin xemacs21-mule
xemacs21-support xfonts-abi xfwp xlib6g xlibs xnest xterm yc-el

どうもperl(perl-5.8)を削除しようとしたらしい。慌てて止めたが、後の祭り。消えた可能性があるのを全て確認し、入れ直した。もしかすると、動いてないdaemonがあるかもしれない他、apache上でのperl-CGIの実行速度が落ちた気がする。

実行速度が落ちたことに関して考え得る原因:
1.apacheのパッケージが狂った
2.perlのパッケージが狂った
3.apacheでmod_perl,speedycgiかなんかが動いていた

1. 2.は分からないのでとりあえずおいておくとして、3に関してはmod_perl.soやspeedyCGIが入っていた形跡がないので、可能性としてはmod_pelのapacheへの静的コンパイル。記憶あやふや。

とりあえず、トップページのカウンターを入れ替えてごまかす。
e-counterだとcgiを5回呼び出すことになるので、夢カウンターに。……これで前の実行速度の感覚に近づくってことはやっぱりmod_perlがくさいのだがどうだろう。

perl 5.6への巻き戻し方法はよくわからない。日本語ソースもないが、英語ソースもどうも?
OK キャンセル 確認 その他