tsurukawa.org の CPU 換装 (後編)

ようやく重い腰を上げて CPU の換装に取り組む。 あとでどの程度性能が上がったのかを確かめるために、 まずは換装前の状態でベンチマークを行なっておく。 気になっていたのは動的なウェブコンテンツへのアクセスだったので、 ホストしている pukiwiki のページへのアクセスを Apache Benchmark で調べる。 適当に同時接続数 10、リクエスト数 100 で試してみると、 1 リクエストあたり 2.3〜2.5 秒かかっているようだ。 また Linux カーネルを K6-2 用に再構築して用意もしておく。

サーバの電源を落とし、蓋を開ける。かなり汚い。 これだけ埃がたまっていると危険かも。まずは掃除をする。 それから MMX Pentium を外し、K6-2 を取り付ける。 丁寧にグリスを塗った CPU ファンも装着。 うーん。いい感じ。

入手した K6-2 は、コア電圧 2.2V、I/O 電圧 3.3V の仕様。 I/O 電圧についてはそのままで問題ないが、コア電圧については、 非公式なジャンパ設定で対応する。 JP20 の 2.5V 用 (1 番ピンと 2 番ピン)、および 2.7V 用 (3 番ピンと 4 番ピン) のジャンパーを接続する。 さらに CPU をバスクロックの 6 倍で動作させるためのジャンパ設定。 入手した K6-2 は Model 8 というヤツで、 2 倍の設定で実際には 6 倍で動作してくれる。 JP11 の 2 番ピンと 3 番ピン、JP12 の 1 番ピンと 2 番ピンを接続する。

よし、電源 ON。BIOS は K6-2 なんぞに当然対応していないので、 K6 300MHz とか表示される。 対応 BIOS もあるようだが、どうせ Linux を使うのだから関係ない。 さてさて、おー、ちゃんと動いている。cat /proc/cpuinfo してみると、CPU を正しく認識し、399.861MHz で動作しているようだ。 さらに K6-2 用に再構築したカーネルをインストールして、リブート。 ソース (arch/i386/kernel/cpu/amd.c) でも確認していたが、 Linux はライトアロケートにも ちゃんと対応しているようだ。 こうして作業は約 40 分ほどで完了。

ログインして適当に Emacs なんかを動かしてみるが、 気持ち速くなったかなぁという感じ。 また動的なウェブコンテンツにアクセスしても、 うーん、少し速くなったかなぁという程度。 再度 Apache Benchmark でベンチマークを行なってみると、 1 リクエストあたり 1.6 〜 1.7 秒くらいで処理している。 性能向上は約 1.5 倍か。 CPU は使いきっているようなので、K6-2 でも CPU がボトルネックなままかな。 K6-2 は MMX Pentium と比較すれば 一つ世代の新しい CPU なので、クロックアップ以上の性能向上を ちょっと期待してしまっていたのだけど、 バスクロックやらなんやらのせいもあって この程度なのかもしれない。 ただ、MMX Pentium の場合 100 リクエスト中 28 の リクエストが失敗していたのに対して、 K6-2 の場合は失敗したリクエストは一つもない。 動的なウェブコンテンツにアクセスが集中するとき (年に数度しかないけど、まぁドキドキする) には、 それなりに性能を発揮してくれるのだろうと納得しておく。

しかし、これが悲劇の始りだった……。

2005/04/27 (Wed) 02:23 | タグ: computer k6 | 固定リンク

tsurukawa.org の CPU 換装 (前編)

tsurukawa.org のホストサーバは旧世代のマシンで運用されている。 1997 年の春に購入した ASUS P/I-P55T2P4 という年期の入ったマザーボードに、 今まで MMX Pentium 233MHz、128MB のメモリ、160 GB のハードディスク (ULtra ATA/133 カード経由) という、まぁ目一杯の構成だった。 電気がもったいないので他には一切パーツはつけてない。 これでもメールサーバやらウェブサーバ、 ファイルサーバとして十分に機能を果たしてきてくれた。 しかし、テレビ録画をしたいなどという贅沢はあきらめつつも、 動的なウェブコンテンツへのアクセスが多かったりすると、 さすがにもうちょっと何とかならないかとも思っていた。

一昨年の暮れだろうか、 裏技を使えば P/I-P55T2P4 に K6-2 が載り、バスクロックの 6 倍、 つまり定格なら約 400MHz で動作することを知った。 何となく気の向いた昨年の 3 月には、1,980 円で K6-2 500MHz を入手した。 しかし、問題は CPU ファンだった。 何とか使えるかなと思っていた 山洋の Socket 7 用 CPU ファンを持っていたはずなのに、 狭い部屋のどこを探しても見つからない。 なぜか箱だけは見つかったが、 箱には 109P5405H8026 という型番の CPU ファンの写真。 調べてみると、さすがに K6-2 には不十分。 しょうがない。新たに購入しようとあきらめる。 とはいえ、当時既に Socket 7 用 CPU ファンは過去の遺物。 Socket 370 用の CPU ファンは店頭でも見かけたが、 P/I-P55T2P4 にはほんの少しだけサイズが大きすぎる。 なおかつ P/I-P55T2P4 では CPU ソケット脇のレギュレータを冷やすように フィンの横から空気が流れるような CPU ファンでなければならない。 山洋の K6-2 向け CPU ファンなどはこの点でだめ。 結局まじめに TDP やら熱抵抗値を調べながら、 適切なものを探しに探して、ようやく通販で山洋の 109P5412H2026 という CPU ファンを3,540 円という本末転倒な価格で購入した。

しかし、情けないことに せっかく購入した CPU ファンにはソケットに装着するためのクリップと、 電源ケーブルが付属していなかった。 嗚呼……、まぁいいか、いつか山洋にでも問い合わせてみようと思いつつも、 結局そのままほったらかしにする。 それから約一年後、今年の三月末、 引越しのために荷物を整理していると、 押し入れの中に置いていた衣類ケースの脇から、 行方不明だった CPU ファンを発掘した。 もちろんクリップと電源ケーブルも付いている。 ちと驚いたことにこの CPU ファンは、わざわざ調べて購入した CPU ファンと まったく同じ型番のものだった。そう、このクリップと電源ケーブルが使える…… というか、新しい CPU ファンは不要だった。 CPU ファンのあの箱の写真は何だったんだ。 そして、シリコングリースもたまたま昨日発見。 無用な遠回りをしたが、K6-2 を試す機会がようやく訪れた……はず。

2005/04/24 (Sun) 23:18 | タグ: computer k6 | 固定リンク

iPod 購入から一年

iPod 第三世代 20GB モデルを購入して一年以上経ったので、 何をどれくらい聞いたのか調べてみた。 iTunes を利用しているなら "iTunes Music Library.xml" を調べればいいのだけど、 Windows を常用しない私は gtkpod を使っているので、直接 iTunesDB を Mac::iTunes でパースしてから計算、集計した。

iPod 内の総収録楽曲数とその総収録時間をまずは計算してみた。これは iTunes なり gtkpod でももちろん分かるが、 計算が合っているのか確認の意味から。総収録楽 曲数は 4,163、総収録時間は 278 時間 19 分 19 秒と出た。時間に関しては gtkpod の表示とは多少異なるがこちらの方が正確なんだろう。

次に実際何時間再生したのかを計算してみた。各曲ごとに演奏時間とプレイカ ウントをかけたものを合計する。実総再生時間は 332 時間 11 分 51 秒。一日平 均一時間弱は聴いていることになる。バッテリが少しヘタってきているがあと一年 くらいは大丈夫かな。また未再生曲があと 1,028 曲もあるので、同じ曲を結構何 度も聴いているということになる。

つづいてどんな音楽をどれくらい聴いたのか調べようと思ったが、私の iPod でのジャンル分けはかなり恣意的で偏りがあった (Hardcore は Door Mat だけ! とか) ので、発 表年代別にそれも曲毎に集計してみる。その際発表年の記録のないもの、 Speech に分類されているニュースなどは除いた。

収録曲数からすると 1970 年代野郎だということだけど、聴取率でいえば 2000 年代のを比較的よく聴いているようだ。こうしてみると、iPod の利益を被りがた いアナログ盤を除くという条件はあるが、iPod (あるいは iTunes) は手持ちの楽 曲データベースとしても面白い。 iTunesDB に再生日時の履歴は残らないが、 定期的にバックアップを取るならばいつ何を聴いたのかという記録にもなる。

なお、最近のiPod ファミリーでも iPod shuffle ではプレイカウントは記録できるらしいが、再生日時は記録できな いようだ。内蔵時計がないためか。これはちょっと残念。 最近 n 日聴いていない曲といったスマートプレイリストの利用ができない。 実際 iPod に相当数の楽曲を入れると特定の曲を探すのは面倒で、 スマートプレイリスト + シャッフルで聴くこ とがほとんどだった。(これはインターフェイスの問題もあるが、なにより私の記 憶力の問題だ。) こういう使い方が主ならば、iPod Shuffle でも十分っぽいのに……。 今思えば iPod mini が案外バランスがよいのかもとも思う。 しかし次にポータブルプレイヤーを買 うなら、オンラインストレージから直接再生できるものが欲しいかも。 いずれ iPod は Palm と同じ限界に直面するだろうし。

2005/03/03 (Thu) 18:35 | タグ: computer ipod | 固定リンク

Copy URL+ と Emacs

Firefox の拡張 Copy URL+ は便利そうだけど、 コピーした内容を Emacs に貼り付けることができないでいた。 クリップボードがらみなんだろうと思ってはいたけど、ふと 「GTK2(?) は X とは別に(??) クリップボード領域を持っているらしい?」から "Re: emacs doesn't use the X clipboard" という記事を見つける。なるほど。 ひとまず C-M-y でクリップボードから yank できるようにしてみる。

(global-set-key "\e\C-y" 'clipboard-yank)

2005/02/23 (Wed) 00:39 | タグ: computer firefox | 固定リンク

各種 blog サービスにおけるフィード配信

気付いた範囲で適当に調べてみた。

最初の三つは無難。RSS 1.0 で description に適切な要約のみ。 とても清々しい。 次の四つは description に記事を全文投げ入れているけど、これは横着。 RSS 1.0 はともあれ、RSS 2.0 を使うならそんなこと気にしないのかな。 さらにこれらの RSS 2.0 ものにはいずれにもタグ付きテキストが投げ込まれている。 最後の四つはフィードでの全文配信はどうも…… と腰が引けたりしないなら妥当なものだろう。 かつ Atom を配信するものもある。フィード配信に限って言えばこの四つか。 TypePad と Nifty (これも TypePad ベース) は有料だっけ。 livedoor は著作権がらみの心配が残る。 tDiay はレンタルできるところあるのかな。

なお、フィードの (特に全文) 配信については、 それによって元ページへのアクセス数が 減るのではないのかと普通は思うし、実際のところも大抵はそうだろうと思う。 ただ、あくまで元ページへのアクセスに拘ったとしても、 フィードの (リッチな) 配信によって 結果として元ページへのアクセス数が増えるのではとの見方 ( 「RSSフィードはウェブ広告にとって善か悪か」) もある。 ウェブでの広告収入はずいぶん一般的なものになってきたが、 これに限って言えば広告込みで配信するという方向もある。 もちろん、多くの人に文章を読んでもらうことにこそ目的があるのなら アクセス数云々はあまり重要ではないというどころか、 RSS フィードが一人歩きしだすような状況こそ 目指した方がいいのかもしないけど。 これについてはちょっと古い記事だがはてな 代表の指摘は興味深い。

2005/02/16 (Wed) 00:15 | タグ: computer | 固定リンク

planet あれこれ

うれしいところ

一ページで関連 blog を一覧できるのがうれしいのはもちろんだけど、 集めた RSS フィードを束ねて配信してくれるのはもっとうれしい。Firefox の ライブブックマークにも対応させておいた。 配信される RSS の title には原著者名も挿入される。

また、RSS リーダへの RSS の登録は結構面倒だったりするが、planet 経由な ら簡単。planet の RSS フィードそのものを登録してもいいし OPML の利用もできる。 さらに、FOAF が流行れば RSS の自動登録や 人間関係の濃さに応じたカテゴライズなんかもできるようになるのかも。 誰がどう利用しているか分からないが、 livedoor Blog なんかは FOAF の配信をしている。 planetplanet は FOAF も OPML も配信してくれる。

皆が紹介した本や映画の一覧を用意するとか、 投稿の統計なんてのはありきたりだが、 情報も有意に束ねられればおもしろいものを再生産できそう。

日時をめぐる問題

なかなか便利な planetplanet だが、表示される日時が UTC なのは 日本ローカルな planet だとやはり気持ち悪い。 国際的な planet ではこれがいいのだろうが、 現行の planetplanet の仕様だ。 作者によればそのうちローカルタイムでの出力もできるようにするらしい。 投稿時刻によっては記事の投稿日付が JST とはずれることもあるが、 今のところはやむをえない。

基本的に planetplanet は planet の更新時に記事の更新を見つけると、 planet の更新時刻をその記事の更新時刻とみなす。 どんな日付を持つ記事でも新しい記事はページ上部に表示する仕様だ。 しかしキャッシュがない場合、 はてなのように記事が正確な投稿時刻情報をもたないもの (*t* を見出しとして使えば別?) は、 UTC で統一するという現仕様と組合わさって planet 上では 記事の日付が、投稿された日よりさらに一日ずれる。

記事の要約あるいは全文

planetplanet では RSS の description (要約) あるいは content:encoded (記事全文) を記事内容として表示するが、 blog サービスの多くは記事全文を description に投げ入れたり、 content:encoded を提供したりまではしていないようだ。 RSS の元々のありかたからすれば言うまでもないだろうが、 たいていのところ記事全文を読むには元ページを見る必要がある。 もちろん各記事へのコメントやトラックバックまで planetplanet は面倒見ていないので、 こちらについても元ページを見なければならない。

ちなみにというか大事なことだが、 RSS の description や特に content の二次利用は 著作権が問題となることもあるだろう。 最近の判例 からすると title だけならまず問題なさそうだけど、 これについてはまた調べてみよう。

2005/02/05 (Sat) 00:10 | タグ: computer | 固定リンク

planet ahayashi+

ほんの少しねこくまゼミ室で話題にしてみましたが、 ねこくまゼミの方々ならびに関連のあ りそうな方々の RSS フィードをまとめた Planet を試験的かつ勝手に用意してみました。 Planet というのは見りゃ分かりますが、関連する人々の blog をまとめて表示す るものです。

私のを勝手に入れないでぇ、という方は言ってください。直ぐエントリーを消しま す。著作権的に問題あるとまずいのでとりあえず定期更新はしませんが、問題なさ げなら定期的に更新するようにします。

また私のを入れてとか、この人のも入れてというのがあったら（本人の了解があれ ば）教えてください。 RSS フィードの URL と、その方の名前が分かれば追加でき ます。また 65x85 程度の画像があればそれを表示することもできます。

なお、ねこくまゼミでない人も数人入っています。だから ahayashi+。 なので、Planet の名前や URL は変更しちゃうかもしれません。

コメントなどがあれば ねこくまゼミ Wiki: Planet にお願いします。

2005/02/01 (Tue) 19:26 | タグ: computer | 固定リンク