2010年5月アーカイブ

で。BS-G2016MRのファン音の騒音ぶりにさすがに耐えきれず、一時はヤフオクあたりで放出することも考えた。けどその前に試してみたっていいんじゃないかと思って一念発起、ふた開けてみた。注意深くネジを外す。

※なお本記事について、当方の個体以外においても内容を保証するものではありません。メーカー保証等も受けられなくなりますので、万一この記事を読んで試すなどされた方が居られましても、各自の環境にて生じた差異や損害などには責任を負いかねます。くれぐれもご了承の上ご覧くださいますようお願いします。(_ _)

ちょっと分かりにくいけど、奥側が機器前方。で、手前側中央に黒く四角いのが見えていて、これがBS-G2016MR唯一のファン。外形は一般的な40mmファンの厚み15mm。当たり前だけどこいつの給電を外してやれば無音になった。さて。外してみると型番が判明。Delta ElectronicsのAFB0412MBという代物らしい。データシートがこちらで読める。

http://www.delta.com.tw/product/cp/dcfans/download/pdf/AFB/AFB40x40x15mm.pdf

ここから性能を確認してみると、だ。

• 回転数(Speed) = 6000 R.P.M.
• 最大風量(Maximum Air Flow) = 8.12 CFM
• 最大静圧(Maximum Air Pressure) = 0.202 IN H₂O
• 騒音(Noise) = 24.5 dB-A

回転数がとにかく高い。6000RPMは高い。おそらく筐体から出ている高周波音はここから来ている。このファン単体で取り出してから回してみてもそんなに大した音ではないんだが、いざ取付けて回すと筐体全体と共鳴を起こしてひどい騒音になっている。しかしその一方で風量の8.12CFMというのはなかなかのもの。4cmファンの同クラスの中で探してみたけど、なかなかこれだけの出力を出すファンは見当たらない。おそらく、高回転・高出力と引き換えにこれだけの音量になってしまっているのだろう。

というわけで、静音タイプのファンに換装するとなると必然的に今のファンより出力上劣らざるを得ない。排熱効率が十分か、見守る必要はありそうだ。そこを何度か自分に問い直しつつ、いざ覚悟を決めたら次に進めだ。

内部を改めて眺めると、結構大型のヒートシンクがメインボード上に取付けられていて、主要チップ自体の冷却は大分手当てされている模様。排熱用のファンを筐体の狭い横側ではなくて、上方向に付けてより大きな6cmとか8cmファンにしておけばそもそも良いんじゃね？とも思ったが、まあそこは仕方なし。

というわけで閉店間際のPCDEPOT盛岡店に飛び込んで見つけてきたのがこれ。

http://www.scythe.co.jp/cooler/mini-kaze-ultra.html
株式会社サイズ ｜ 商品詳細 ｜MINI-Kaze ULTRA 20mm厚

決め手は3500RPMとかなりの低回転・静音タイプでありつつ風量4.86CFMはだいぶ稼げそうな点。ケース内の設置空間もかなりギリギリではあったものの20mm厚も入れそうだったのでやってみた。この判断は結果から言うと成功。20mm厚でもメインボードとの間に3mmほど隙間が残り、ファンが干渉するおそれもない。

ここで一度コネクタを繋いで電源を入れてみたが問題が残った。ファンが回らないのである。原因は2枚目の写真。それぞれケースファン電源用の3ピンコネクタである。上は取り外した元々のファン(AFB0412MB)、下は新しく取付けたファン(MINI-Kaze ULTRA 20mm厚/SY124020L)。ケーブルの色の順番に注意してほしい(ちょっと見えにくいが...)。AFB0412MBは上から「黒、青、赤」となっているのに対し、MINI-Kazeでは「(空き)、赤、黒」になっている。これもデータシートを参照すると下記のような記述を確認できる。

* Lead Wires :
  UL 1007 AWG #24 OR Equivalent
  Red Wire Positive(+)
  Black Wire Negative(-)

あれ、青(Blue)はどこ？

まあひとまず、赤と黒の線はそれぞれ同じくプラスとマイナスで共通していると仮定し、これが全くあべこべの配線になっているので直してみる。AF0412MBの順番に習い、「赤、(空き)、黒」の順にする(青は無視。2ピンなんだし割り切れ＞俺)。写真のコネクタには3ピンそれぞれの接点部分に金具部分がヒッカケになっているので、これを細身のドライバや針金などで強く押し込み、ヒッカケがはずれるのをさぐりつつケーブルをゆっくりと引き抜く。一気に強く引こうとすると切れてしまうと思われるので注意。金具を押し込みながら、押し込んだ方向と同じ向きに角度を付けて引くようにすれば割とあっさり抜ける。3枚目の写真に模してみたのでこちらを参照のこと。

さてこれでコネクタ刺してフタして起動。おおっ。音がない。不安になるくらいファン音(とその共鳴音)がない(笑)。でも排気ダクトに手を当ててみるとちゃんと空気は出ているぞ。OKだ。すばらしい。

というわけでうちのBS-G2016MRヤフオク行きを何とか逃れました(何)。やったー。

で、早速届いたんですわBS-G2016MR。

http://buffalo.jp/products/catalog/network/bs-g2016mr/
レイヤー2 インテリジェントGigaスイッチ 16ポート | BS-G2016MR

さすが法人向けあって重厚っていうかすげえですな。ファン音が。(爆) うちの5台あるPC全部束にしてもまだこの一台のファン音のほうが大きいです。想定はしててもいざ火を入れて実感すると違うよねーってやつです。

まあ965BEのときと比べればまだまだだし、爆音ってほどじゃないにしても、でも結構ある。逆に言うと、Core i7/i5のマシンすらここまで音立ててないので、随分静音PCとしてうまく作れてたんだなと自分を褒めたくらい。^^;

まあどうせ仕事部屋は独立なんで気にしないでもいいし、設置して数時間して慣れてきつつはあるので、もう少し様子見ながらで行きますわ。

結局スイッチの件は無事発注しなおしができましたよということで、気を取り直して次のネタ。

せっかく何台もサーバを揃えたのでやってみたいじゃないですかとgangliaを入れてみた。

http://ganglia.sourceforge.net/
Ganglia Monitoring System

インストール時につっかえたのは「date.timezone」の設定を明示的に行っておかないとphpがだだをこねてwarningを出しまくると言う点。ちなみにうちのphpは現時点最新の5.3.2。php.iniを作成してそこで指定しておくことにした。

あと、GDモジュールが必要。と言っても円グラフを少し入れたりするのに使ってる程度だけど、うちではphpのconfigureしてたときに--with-gdオプションを付けてなかったこともあってインストールされていなかった模様。GDはdebパッケージなので(libgd2-xpm)、開発用パッケージ(libgd2-xpm-dev)も忘れずにインストール。その後--with-gd付きで再度ビルドしなおして事なきを得た。

ganglia自体もsqueezeには入ってるらしいganglia-webfrontendパッケージはまだlennyには降りて来ていないっぽく、またdeb自体もバージョン2.5.xとやや古めで設定ファイルの書式なども違っていたので、3.1.7をこちらもソースからビルドしてインストール。こちらもそんなに引っかかること無くインストールできました。　

さて自宅環境のメインのハブが8ポートじゃいよいよ辛くなってきたのでそろそろ16ポートにしてさらにVLANとか組めたら嬉しいなうへへとかよだれ垂らして思っていろいろ眺めてたんですが、最初目を付けていたI/OデータのETG2-SHV16Nがどこ見に逝っても無いんですね。在庫が。

http://kakaku.com/item/00660410105/
価格.com - IODATA ETG2-SHV16N 価格比較

来月中旬入荷予定とかふざけてんのかと。

しょうがないのでバッファローの同等品を探してみたらちょっと値段帯上がるんですわな。まあでもしょうがねーかとポチったんですよ。そしたら奥さん。

http://buffalo.jp/products/catalog/item/b/bs-2016mr/
「Business Switch」シリーズ レイヤー2インテリジェントスイッチ 16ポート|BS-2016MR

間違えて100Mスイッチになっちゃったんですのよおほほほほほ

o... rz

本当に注文しようとしてたのはこっち↓

http://buffalo.jp/products/catalog/network/bs-g2016mr/
レイヤー2 インテリジェントGigaスイッチ 16ポート | BS-G2016MR

（´・ω・｀）

（´・ω:;.:...

（´:;....::;.:. :::;.. .....

さー明日朝一で販売店にお詫びの電凸逝くよー...‥.. λ...

例のLinuxルータ(nelly)、NICが2つ付いてる訳なんですけど、っていうかpppoeかましてしかもマルチセッションしてるからインタフェイスの数がまあ5-6個くらいはある形になってるんです。で、ppp0でOCN、ppp1でwakwakっていうマルチセッションをやってて、wakwakの方が固定IPアドレス付けてまして、っていう構成なんですがね。

そこに外からVPNを掛けたいとしましょうや。VPNの受け口にはまあOCNは非固定アドレスなんでDynamic DNSでもやってない限り使いにくい。なんでwakwakの方でVPNの受信をさせようかとか思うとですね、L2TP+IPSECでやってるとxl2tpdがよろしくないんです。IPsecのネゴシエートが終わってL2TPに処理が移るとですね、xl2tpdさん何を血迷ったか、ppp1経由で受け取ったはずのL2TPクライアントからのリクエストに対して、default routeになってるppp0経由でレスポンス返そうとするんですわ。したらあんさん、L2TPクライアントからすればリクエスト送ったはずのサーバアドレス(=ppp1)と違うアドレス(=ppp0)からレスポンスが返ってきたって知るかーってなもんですよ。いやー、参りましたわー。orz

というわけでこれ、直しました。受信IPアドレスを使って打ち返すように、sendmsg()でmsg_controlにIP_PKTINFOを仕込んで設定するようにしました。xl2tpd v1.2.4に対するパッチとして適宜適用して下さい。本来なら同じmsg_controlを使うIP_IPSEC_REFINFOと併用した際の挙動とかも確かめなきゃなんですけど、うちでは使ってないのでやってません;-)。パッチの適用についてはat your own riskでよろしくでございます。詳細は追って。

ファイル: xl2tpd-1.2.4.patch

diff -uNr ./xl2tpd-1.2.4.orig/call.c ./xl2tpd-1.2.4/call.c
--- ./xl2tpd-1.2.4.orig/call.c  2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/call.c       2010-05-14 03:34:40.461125516 +0900
@@ -618,7 +618,7 @@
 }
 
 struct call *get_call (int tunnel, int call, unsigned int addr, int port,
-                      IPsecSAref_t refme, IPsecSAref_t refhim)
+                      unsigned int localaddr, IPsecSAref_t refme, IPsecSAref_t refhim)
 {
     /*
      * Figure out which call struct should handle this. 
@@ -695,9 +695,11 @@
         };
         st->peer.sin_family = AF_INET;
         st->peer.sin_port = port;
+       st->local.sin_family = AF_INET;
        st->refme  = refme;
        st->refhim = refhim;
         bcopy (&addr, &st->peer.sin_addr, sizeof (addr));
+        bcopy (&localaddr, &st->local.sin_addr, sizeof (localaddr));
         st->next = tunnels.head;
         tunnels.head = st;
         tunnels.count++;
diff -uNr ./xl2tpd-1.2.4.orig/call.h ./xl2tpd-1.2.4/call.h
--- ./xl2tpd-1.2.4.orig/call.h  2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/call.h       2010-05-14 03:34:52.625126441 +0900
@@ -98,7 +98,7 @@
 extern void push_handler (int);
 extern void toss (struct buffer *);
 extern struct call *get_call (int tunnel, int call, unsigned int addr,
-                             int port,
+                             int port, unsigned int localaddr,
                              IPsecSAref_t refme, IPsecSAref_t refhim);
 extern struct call *get_tunnel (int, unsigned int, int);
 extern void destroy_call (struct call *);
diff -uNr ./xl2tpd-1.2.4.orig/l2tp.h ./xl2tpd-1.2.4/l2tp.h
--- ./xl2tpd-1.2.4.orig/l2tp.h  2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/l2tp.h       2010-05-14 03:38:04.172126651 +0900
@@ -146,6 +146,7 @@
     unsigned short port;        /* Port on remote end */
 #else
     struct sockaddr_in peer;    /* Peer's Address */
+    struct sockaddr_in local;   /* Local's Address */
 #endif
     int debug;                  /* Are we debugging or not? */
     int nego;                   /* Show Negotiation? */
diff -uNr ./xl2tpd-1.2.4.orig/network.c ./xl2tpd-1.2.4/network.c
--- ./xl2tpd-1.2.4.orig/network.c       2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/network.c    2010-05-14 04:03:15.057126011 +0900
@@ -77,6 +77,11 @@
 
            gconfig.ipsecsaref=0;
     }
+    arg=1;
+    if (setsockopt(server_socket, IPPROTO_IP, IP_PKTINFO, &arg, sizeof(arg)) != 0) {
+           l2tp_log(LOG_CRIT, "setsockopt recvref[%d]: %s\n", IP_PKTINFO, strerror(errno));
+    }
+
 #else
        l2tp_log(LOG_INFO, "No attempt being made to use IPsec SAref's since we're not on a Linux machine.\n");
 
@@ -257,8 +262,8 @@
 
 void udp_xmit (struct buffer *buf, struct tunnel *t)
 {
-    struct cmsghdr *cmsg;
-    char cbuf[CMSG_SPACE(sizeof (unsigned int))];
+    struct cmsghdr *cmsg = NULL;
+    char cbuf[CMSG_SPACE(sizeof (unsigned int)) + CMSG_SPACE(sizeof(struct in_pktinfo))];
     unsigned int *refp;
     struct msghdr msgh;
     int err;
@@ -288,6 +293,28 @@
 
        msgh.msg_controllen = cmsg->cmsg_len;
     }
+
+    if (t->local.sin_addr.s_addr) {
+        if(gconfig.debug_network) {
+                l2tp_log(LOG_DEBUG,"sending with setting source address saref=%s\n", inet_ntoa(t->local.sin_addr));
+        }
+
+        struct in_pktinfo* ipi;
+        msgh.msg_controllen = sizeof(cbuf);
+
+        cmsg = (cmsg ? CMSG_NXTHDR(&msgh, cmsg) : CMSG_FIRSTHDR(&msgh));
+        cmsg->cmsg_level = IPPROTO_IP;
+        cmsg->cmsg_type  = IP_PKTINFO;
+        cmsg->cmsg_len   = CMSG_LEN(sizeof(struct in_pktinfo));
+
+        ipi = (struct in_pktinfo*)CMSG_DATA(cmsg);
+        ipi->ipi_ifindex = 0;
+        ipi->ipi_addr.s_addr = 0;
+        bcopy(&t->local.sin_addr, &ipi->ipi_spec_dst, sizeof(ipi->ipi_spec_dst));
+
+        msgh.msg_controllen = CMSG_SPACE(sizeof(struct in_pktinfo));
+    }
+
     
     iov.iov_base = buf->start;
     iov.iov_len  = buf->len;
@@ -388,6 +415,8 @@
     struct iovec iov;
     char cbuf[256];
     unsigned int refme, refhim;
+    struct cmsghdr *cmsg;
+    struct in_pktinfo* inpkt = NULL;
 
     /* This one buffer can be recycled for everything except control packets */
     buf = new_buf (MAX_RECV_SIZE);
@@ -478,7 +507,6 @@
 
            /* extract IPsec info out */
            if(gconfig.ipsecsaref) {
-                   struct cmsghdr *cmsg;
                    /* Process auxiliary received data in msgh */
                    for (cmsg = CMSG_FIRSTHDR(&msgh);
                         cmsg != NULL;
@@ -494,6 +522,12 @@
                    }
            }
 
+            for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL; cmsg = CMSG_NXTHDR(&msgh,cmsg)) {
+                if (cmsg->cmsg_level == IPPROTO_IP && cmsg->cmsg_type == IP_PKTINFO) {
+                    inpkt = (struct in_pktinfo*)CMSG_DATA(cmsg); 
+                }
+            }
+
            /*
             * some logic could be added here to verify that we only
             * get L2TP packets inside of IPsec, or to provide different
@@ -517,7 +551,7 @@
            }
            if (!
                (c = get_call (tunnel, call, from.sin_addr.s_addr,
-                              from.sin_port, refme, refhim)))
+                              from.sin_port, (inpkt ? inpkt->ipi_spec_dst.s_addr : 0), refme, refhim)))
            {
                if ((c =
                     get_tunnel (tunnel, from.sin_addr.s_addr,
diff -uNr ./xl2tpd-1.2.4.orig/xl2tpd.c ./xl2tpd-1.2.4/xl2tpd.c
--- ./xl2tpd-1.2.4.orig/xl2tpd.c        2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/xl2tpd.c     2010-05-14 03:37:08.664125809 +0900
@@ -599,7 +599,7 @@
      * to do IPsec properly here, we need to set a socket policy,
      * and/or communicate with pluto.
      */
-    tmp = get_call (0, 0, addr, port, IPSEC_SAREF_NULL, IPSEC_SAREF_NULL);
+    tmp = get_call (0, 0, addr, port, 0, IPSEC_SAREF_NULL, IPSEC_SAREF_NULL);
     if (!tmp)
     {
         l2tp_log (LOG_WARNING, "%s: Unable to create tunnel to %s.\n", __FUNCTION__,

さて、ここまでUnix Benchをただ走らすだけ走らせてみたけど、内容にもちゃんと踏み込まないと逝けませんよねということでソースの中身を検証してみます。

まず何より気になっていたのがAMD系からIntel系に切り替えて歴然と違いが出たSystem Call Overhead。Unix Benchのテストはtarballを解凍した中にある"Run"スクリプトから全てが始まりますが、こいつは配下にpgmsディレクトリを持っていて、そこに配置された各テストプログラムを起動するだけです。

Runスクリプトの中ではそれらテストプログラムとその説明や起動時のオプション(何回・何秒ループさせるとか、テストの種類を指定する)の情報をハッシュで保持しています。

# Individual parameters for all benchmarks.
my $testParams = {

    ##########################
    ## System Benchmarks    ##
    ##########################

    "dhry2reg" => {
        "logmsg" => "Dhrystone 2 using register variables",
        "cat"    => 'system',
        "options" => "10",
        "repeat" => 'long',
    },
    "whetstone-double" => {
        "logmsg" => "Double-Precision Whetstone",
        "cat"    => 'system',
        "repeat" => 'long',
    },
    "syscall" => {
        "logmsg" => "System Call Overhead",
        "cat"    => 'system',
        "repeat" => 'long',
        "options" => "10",
    },
    "context1" => {
        "logmsg" => "Pipe-based Context Switching",
        "cat"    => 'system',
        "repeat" => 'long',
        "options" => "10",
    },
...
};

"System Call Overhead"、つまりsyscallの項目に格納されていることになります。そしてこの場合、"syscall"のキーが起動するテストプログラム名に対応付けされていて、それは(unixbenchディレクトリ)/pgms/syscallとなります。またこれのソースが(unixbenchディレクトリ)/src/syscall.cとなります。

また起動時の引数はさらに下位ハッシュの"options"に格納されていますがこちらは"10"となっています。つまりここから"System Call Overhead"のテストを起動するときは、コマンドラインで仮定すれば"./pgms/syscall 10"として起動することになります。

        switch (test[0]) {
        case 'm':
           while (1) {
                close(dup(0));
                getpid();
                getuid();
                umask(022);
                iter++;
           }
           /* NOTREACHED */
        case 'c':
           while (1) {
                close(dup(0));
                iter++;
           }
           /* NOTREACHED */
        case 'g':
           while (1) {
                getpid();
                iter++;
           }
           /* NOTREACHED */
           ...
        }
        ...

syscallテストプログラムでは第2引数でテストの種類を指定することができ、それが上のコードサンプルのswitch(test[0])の行に対応しています。無指定の場合は"mix"が指定されたのと同じとなっていて、上記サンプルで言えば続くcase 'm':行以下のwhileループがそれに相当することになります。ループが1回回るたびにiter変数がインクリメントされるので、最終的にこのiterの値がいくつになったかがテスト結果となります。whileは見た目上永久ループになっていますが、SIGALRMによって抜け出すようになっています。テスト起動時の第1引数がテストの継続時間となっていて、これがalarm()に使われている訳です。

つまり、上記のコードサンプルからすると、close()/dup()/getpid()/getuid()/umask()の5つのシステムコール関数のいずれかがAMD/Intel両アーキテクチャ間での性能差を引き出していたことになるわけです。うーん。惜しむらくはここを気にする前にAthlon/Phenomとも手放してしまったことですが...。こちらを見る限り、これはAthlon/Phenom共々出ている傾向のようなんですよね。

とどめに。しんがりはclaire。Clarkdaleなんですけど、やはりmary&emmaのnative 4coreに比べて4coreでの性能が一部伸びませんな。それでも悪くない感じです。

これで一応当初のリニューアル構想を完了したので、いよいよこの環境でいろいろあそんでみたいとおもいます。こんだけ並べて何すんだって感じですが。はわわ。

いわゆる「試合には出ない1-2人」の選び方って、「万が一」もしもの時にはちゃんと動ける人間を持ってくるもんだしトルシエとかのときもそのつもりだったはずと思う。まさかほんとに試合に(少なくとも現時点で)出られない人間を持ってくるとは思わなかった、っていうコントみたいな話だと思ってる。

http://www.sponichi.co.jp/top/special/paperstop/sponichitop/KFullNormal20100511112.html
スポニチ１面で見る１週間 ― スポーツニッポン新聞社

数日前あたりから「ムードメーカー枠」がどうこう言われるようになり、何かおやと思わせる感じがしていた。最初こそオシムの急な降板からの引き継ぎだったとはいえ、いわゆる「岡田ジャパン」(という言い回しは監督が誰であってもあまり好きじゃないが)というチームを作って来たはずで、今頃チームの士気をどうこうするような「ムードメーカー」をさも後付けするような話は、報道上そういう話にされてしまったかもしれないという点も差し引きつつ、それでもなおぞっとする話じゃないなと思って聞いていた。

http://www.sponichi.co.jp/soccer/news/2010/05/07/01.html
日本代表に"ムードメーカー枠"導入（サッカー） ― スポニチ Sponichi Annex ニュース

「ムードメーカー」と聞いて私が思い出すのは80年代後半のNPB読売巨人軍の屋台骨を支えたと言っては過言かも知れないが少なくともベンチはしっかり支えたはずの上田和明である。彼はグラウンド上でこそあまり目立った働きの無いままユニホームを脱いだが、ベンチでやたらと騒いで暴れる(何)映像は幾度となくお茶の間に届けられたために当時を知る野球ファンならまず間違いなく知っている部類の選手である。アンチ巨人に言わせれば誰もが皆「上田？ああ、あの応援団長ね」といった具合で答えたであろう、そのくらいひときわ輝く存在感を醸していた。ベンチで。

http://ja.wikipedia.org/wiki/上田和明
上田和明 - Wikipedia

それでも守備や打席につくことは何度もあったし、戦える状態であったことは疑いない。彼より優れた野手が多数居ただけのことであって、それでも「万が一」にも自分が必要だということであればいつでもグラウンドに駆け出して行く。その気構えがあってこその「ムードメーカー」だったはずである。

この「ムードメーカー」報道にちょっとおやと思ったのは、そうした「万が一」を最初から度外視したような報道が挟まっていることである。トルシエが「いつでも、（試合に出るための）準備をしておけ」と中山秋田を招集したのとは様子が違うということになる。おかしいではないか。最初から試合に出さないつもりで呼ぶならそれは本人に対して侮辱だし、呼ばれなかったその他の選手達にしても失礼であり不幸である。もちろんそうならないよう最大限敬意を払ってのことだとは思うし、いつものこれは報道のあやで、まさか岡田監督自身は本当に試合に使えないのでもよしとしてなどとはゆめにも思ってはいないだろうが、が、それでもなお、である。

http://llabtooflatot.blog102.fc2.com/blog-entry-1754.html
サッカーコラム J3 Plus+　 トルシエがゴン中山を召集した理由

そして昨日の代表メンバー23人の発表。岩政連れてくつってもどうせ使わないんだろとか、ガチャピン大丈夫かなコンディション間に合うのかなとか、っつかあー結構ケガ人多くね？とか、まさか矢野が、とか、色々あるにはあったけど一番の驚きは半年間ケガで戦列を離れていたGK川口能活の選出。川口は好きだし選ばれておめでとうとは思うけど、正味これはない。

http://www.sponichi.co.jp/soccer/news/2010/05/10/13.html
４度目のＷ杯は絶望的...川口、右内転筋故障（サッカー） ― スポニチ Sponichi Annex ニュース

発表当日の裏でこんな状態になってるのに、だ。これでいいのか？ナビスコの試合には出るらしいというから大丈夫だろうと言うには言うが、あまりに楽観的すぎやしないか。

http://www.jsgoal.jp/news/jsgoal/00101176.html
J's GOAL | J'sGOALニュース | 【W杯メンバー発表！】会見での岡田武史監督（SAMURAI BLUE 日本代表）コメント（全文掲載しました）

アルビレックス新潟は昨年末の移籍市場ではそれまでの正GK北野を奪われ、補強として獲得した高木はキャンプ中に負傷離脱、已む無く第二GK黒河で臨んだ今季J1開幕も第2節でこちらも怪我でアウト。この冬だけで3人もGKを失うはめになったのだ。これでもし東口が当たりくじじゃなかったら今頃はと思うと身の毛もよだつ話である。GKを失うリスク、と言うよりも、「万が一」失ったときに払わされる代償はまず間違いなくとてつもない。1人失うだけでもかなりの分を背負わされることになるのだ。短期決戦、1年フルで戦うのとは訳が違うとはいえ、それでも川島か楢崎が練習地のスイスか南ア入り後のホテルのバスルームでオーデコロンの瓶落っことしてトラップしようとしてしくじって足怪我して動けなくなって、なんてことだって無くはない。フィールドプレーヤー20人のうち一人が怪我をするというのとは訳が違う。GKのリスクは1/20でも1/23でもない。1/3なのだ。

http://www.valencia.jpn.org/html/legend/canizares.html
サンチャゴ・カニサレス | Valencianista－バレンシアCF応援サイト－

もしこれでさらに川口のことだから、仮にそんなことになったら出られますとか強弁してしまいそうな気もするし、それでいつも通りに確変起こしてデンマーク相手に完封とかやってしまいそうな気さえする。が、よしんばそれでもし決勝トーナメント進出とかなったとしても、私は決して喜べないと思う。そんな「万が一」は、御免被りたい。

一度焚き付けられるとまあ色々と進む訳で、合わせて連休中ラック構成の見直しもやってました。ルミナスラックが大好きな私はPCラックもこれで組んでます。

http://www.netvalley.co.jp/fs/honten/0000000193/ph9018-5
ルミナスプラスラック５段90Ｗ　PH9018-5 Netvalley家具インテリア館 ルミナスプラス

この一番下の段にPCを並べて、真ん中くらいの段にディスプレイやキーボードを置いたりなんかしてやってたんですが、上の段で作業してると細かな振動がラック全体をゆらして下のPCの方にもとどくのが大変心理的によろしくない。

そこで、下の2段を抜いて一回り小さいラックを組み立て、上下で分離してしまえと。

http://www.netvalley.co.jp/fs/honten/0000000193/ph7614-4
ルミナスプラスラック４段７６Ｗ　PH7614-4 Netvalley家具インテリア館 ルミナスプラス

写真例にあるように、これを全体で一つのラックとして組むと140cm超の高さになるわけだけど、半分ずつにして70cmくらいずつのミドルラックも作れる。こいつを最初のラックの下半分に入れるとちょうどいい大きさなんですよ。

その２枚を外したところ。あー。外す前も撮っとけば良かったかなと思ったときには後の祭り。...ま、それはそれとして、PCも外したので一緒にケーブル類もいろいろと張り直し。何しろ、長さの余計な分を一番下の棚板の下に押し込んだりしていたのでぐちゃぐちゃしいの何のって...。下に見えるケーブルのかたまりはその名残。

ケーブルはどうしたって縮めることはできないので、一旦遠回りさせ、ワイヤラックを生かして適宜良い所で折り返させます。ワイヤラックはこれがやりやすいのが良いですの。

外した２枚の跡地にコの字フレームを付けて76cmラックを70cm高3段(1段は天板)にして装着。ラックの下のほうでごちゃっとしていた電源コードはコンセントはそのままに76cmラック板を使って引っ掛けながら上に迂回させてまとめる。

これでPC台部分と上半分のラックを切り離せるので、上でがちゃがちゃやっても安心というわけです。

あまり深い考えは持たずに選んだもんなんですけど、Phenom II x4 965BEを入れてみたのが運の尽きと言いますかね。リテールクーラーがやかましいやら狭いケースだと付けられるクーラーが限られるわおまけに排熱がよろしくないわで、やたら手間が掛かってまいりました。これはさすがにかなわんと。mary(+emma)は常駐で電源ONにさせるつもりはないとはいえ、多分に負荷をかけて試験したりとかを想定してるのでこの温度の上がり方はこわい。

というわけで散々悩んだものですが、965BEはうちでは使い切れないと判断、使用浅いうちに手放してしまうことにしました。で、問題はemmaにのせたAthlon II x4 620。maryとemma(さらに言えばnellyとshirleyも)は2台を組にして同系の構成にするというのが構築のポリシーにしてました。なのでまあ順当にいえば965BEからクラスダウンして同じAMD系の中から選べばいいんですけど、うちではなぜだか血迷ってIntel系に全取っ替えしました。

えっ。

いやーもうどうせ組み替えるんだからAMDにこだわる必要すらねーだろーっていうかこれ今後CPUの入れ替えとかなったら望み薄いじゃんってことだよねーx6とかいみねーじゃんだよねーあははーとかいう無茶苦茶なテンションが降りてきまして。ええ。

いやもうあほかとo... rz

まあでも注文しちゃったもんはしょうがないので、ずざっと組み替えてGWをずっと過ごしてましたよ。ついでにemmaのメモリもDDR3 8GBでmaryとおそろいですよ。ええ。ええ。