24時間、電話もインターネットつながらない大障害。
ここまで確認したので MDF 側の障害というのは明白なのに、つなぐネットサポートも、今日の工事業者の連絡の掛かりの人も「機器を入れ換えただけだから」とどうしても宅内配線を実地で点検せずに気が済まないらしい。聞き入れ変えただけで電話線から何も聞こえなるかい！と思う。
宅内点検になると、訪問日を決めて来てもらって確認となり、何日かかるか分かったものではない。
結局、現場の工事の人と連絡がついたら、すぐ MDF を確認してくれて不具合を見付修正してくれました。後は私が会社からリモートで回復を確認して完了。
どうもサポートに状態を認識してもらうのに時間がかかるの困ってしまう。
多分、うちは、珍しい em-16(VDSL) だったのを工事の人が気がつかずに普通のem-1(HomePNA) からの切り替えと同じ処理をして、全く通信が出来なくたのではないだろうか。
上のグラフの通り、高速なモデムに切り替わった後、デフォルトGW間の遅延が増加。2007/06/09 Satに遅延が訳の分からない減り方をする前よりは速いが、7月中の遅延のほぼ倍になった。高速VDSLモデムの変調方式の特性か？
高速回線に切り替わったので、Speed測定。
22時前に測定すると、goo スピードテストで 20Mbps〜32Mbps。Yahoo! BB ADSL Speed Checkerで下り30Mbps弱、上り20Mbps強。下りも上りも。もう少し出てくれると思っていた。明日朝方測ってみようと思う。
サポートセンターとのやり取りつなぎ替え作業中に異常なパケット転送を観測
ループさせたかなあ。
ettc-mai2のRAID関係基本ソフトUpdate。
WAN側回線速度が上がったので公開サーバをチューニング。自宅内プロキシサーバで実績のある値に変更。
/etc/sysctl.conf kern.ipc.somaxconn=1024 kern.ipc.maxsockbuf=1048576 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=262144
自宅内からでは回線遅延が無くFTPで600Mbyte程度やりりしても違いが分からず。FFFTP（ettcweb0⇒ettc-main2）601,229,312byteで195秒。測定中25MBps弱に張り付いてしまう。ルータのCPU負荷も100%に張り付くので、ルータの処理速度の計測になってしまっている。
さらなる、低消費電力化を狙って、2007/06/04 Monに引き続いてcpufreqとpowerdの設定に再度挑戦。今回もまず手動でローディングしてみる。
kldload cpufreq powerd
止まらずに動作する。動作周波数を確認。
%sysctl -a dev.cpu.0.freq dev.cpu.0.freq: 125
前回と同じく125MHzと極端な値になっている。周波数を下げる方には今まで通り動作しているようだ。上げる方はどうか。カーネルをコンパイルして負荷をかけてみる。
dev.cpu.0.freq: 1458
数秒でクロックが上がり始めた。ccが走り始める頃には上限に達した。
dev.cpu.0.freq: 2333
コンパイルを止めると数秒で中間周波数におちる。
dev.cpu.0.freq: 1000
30秒経たないうちにアイドル時の周波数に落ち着いた。
dev.cpu.0.freq: 125
動作的に不審な点は無し。ローダなどに設定してからリブート。
/boot/loader.confに追加。
cpufreq_load="YES"
/etc/rc.confに追加。
powerd_enable="YES"
起動後に確認するとdev.cpu.0.freq: 125。dmesgを見て関係しそうなメッセージを確認。
acpi_perf0: <ACPI CPU Frequency Control> on cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0 cpu1: <ACPI CPU> on acpi0 est1: <Enhanced SpeedStep Frequency Control> on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130e2606000e26 device_attach: est1 attach returned 6 p4tcc1: <CPU Frequency Thermal Control> on cpu1
これは、CPU0はACPIで周波数コントロールされて、CPU1はEST(Enhanced Speedstep)で周波数コントロールされていると言うことだろうか。「CPUはエンハンスドスピードステップをサポートしている。しかし認識されていない（CPU supports Enhanced Speedstep, but is not recognized）」との表示が気にはなる。温度も下がっている様だし、カーネルコンパイルの時間は、-j5 オプションで5分36秒から5分47秒に変化。納得できる小さな変化な為、今回はこの設定で行こうと思う。
多分、温度が下がったので、消費電力が変わるはず。一旦今までの積算電力を消費電力表に反映しておく。
今日は定期の MS Windows Update の日。久しぶりに数が多い。
夕方から雷。いくつか瞬停があったが、18時前の瞬停が一番おおきかった。
この時、照明が一瞬暗くなったが、自宅内の物は、自宅内プロキシサーバだけがリブート。そのほかの物は録画機の類も含めて全く影響なし。ただ、どうもマンション内のMDF内にあるルータがリブートしたよう。デフォルトゲートウエイへのpingが100% packet lossの記録。
mrtg-ping-probe: ERROR: Could not find ping summary for 202.215.167.122 mrtg-ping-probe: INFO: The output of the ping command /sbin/ping -s 56 -c 10 202.215.167.122 was: PING 202.215.167.122 (202.215.167.122): 56 data bytes --- 202.215.167.122 ping statistics --- 10 packets transmitted, 0 packets received, 100% packet loss
室内側のVDSLモデムがリブートしたのかもしれない。通常経路様ルータ YAMAHA SRT100はイーサネットのリンク状態を監視しているが、間にスイッチングハブ（BUFFALO LSW2-GT-8NSRR）がかんでいるので、ダウンが検出できない。
2007/08/14 Tueのcpufreq+powerdによる公開Webサーバの省電力、消費電力表の通り2W程度の低消費電力になりそう。
全体の消費電力を下げるため、過去からの経緯で連続運転していたWebアクセスルータを自宅内プロキシサーバが動作している時のみに動作するように変更。こちらの方が公開Webサーバの省電力より効きそう。
NVIDIA Quadro NVS 440 のドライバソフト類のアップデート。
日本語版は大きな刻みでバージョンアップした。
メインクライアントPCは、HDDのキャッシュの書き込み時間を完全に確保するために、シャットダウンコマンドで電源を切らない設定した上で、UPSで電源を元から切っています。この為、OSの終了画面が電源が切れるまで生じされる形になっている。
ところが、昨日のグラフィックカードのNVIDIA Quadro NVS 440 のForceWare 84.26 ⇒ 162.50アップデートの後、OSの終了画面が出ずにディスプレイが表示状態と省電力状態を繰り返すようになった。バックライトが傷んでしまいそうなので、手動でディスプレイの電源を切っている。とても不便。ドライバをVer.84.26に戻そうかどうしようか思案中。
2007/6/24にYahoo! slurpのクロールを確認してから2ヶ月。やっと登録された。「自宅サーバの運用」で8位、「自宅サーバの運用 FreeBSD」で1位。少し試してみる限りに於いては、3週間程度前の内容ながらGoogleと異なり初めから前ページがインデックス化されているように思う。
どうも、2ヶ月前からのクロールに関係なく、2007/07/28に、はてなブックマークからリンクを張っていただけたのがきっかけのように思う。これであれば一般に言われている4週間程度という期間と話が合う。
アクセスがしやすくなるのに見合うように内容をよくしたい。
低迷していた、週あたりの最大ページリクエスト数が久しぶりに更新。また、データ転送量も今週は一日あたり22MByteに増加。
曜日ごとのリクエスト数に大きな偏りはないようなのに、ゴールデンウイークや、盆前後の夏休みの時期に減少する傾向があるように思う。アクセス時間は9時から17時に増える傾向がはっきりしている。どうも社会人が昼間に仕事先からのぞいているという閲覧形態になっているのだろうか。
どうも当公開Webサーバの電力消費が増加しているように思う。
低消費電力化を図った結果、電力消費が負荷に反応するようなので、アクセスの増加による負荷増加かとも思う。
雷の発生しやすい天候が続いていることでもあり、停電でデータを無駄にしないためにも、推移を確かめるためにも、消費電力表を更新しておく。
ネットワークの遅延状況の測定に使わせていただいている大阪大学の公開FTPの日中に4時間弱の停止を検出。
応答遅延がばらついた後の停止。時間帯的に見ても暑さの盛り。熱によるダウンだろうか。ボランティアベースで負荷の高いサーバ提供の苦労がしのばれる。