02時過ぎに、大阪方面、東京方面の遅延のベースが変化しているのが観測されている。デフォルトルータまでの時間に変化はないので以前のVDSLのリトレーニングではない。
約2ms位の遅延時間の増加。ISPのバックボーンの経路が切り替わったか、ルータが増えたか。
自作パソコン群と自宅通信網の中からリンクされている各パソコンのHDDの記述を整理。整理する際にHGST Deskstar E7K500のその他コメントを大幅追加。今まで、どうもおかしな比較が行われているのを見聞きして気になっていたので、意見を整理した。
前回、メインクライアントのSupermicro X7DAE BIOS 1.3a Updateでトラブルになっていたので、様子を見ていたBIOS Update を実施。
無事成功。5月の終わり頃には出ていたようだが、実施に踏み切れず今まで放置。時期から見て1.3系のアップデートはCore2系CPUのマイクロコードのバグに絡んだアップデートだろうとふんでいたので是非やりたかった。
マイクロコードのバグに関する日本語の情報でわかりやすいのはHPのサポートページ「特定のインテルプロセッサを搭載するデスクトップ製品のシステムBIOSをアップデートしてください（改版）」。対象にはIntel Xeon5100も含まれている。
当公開WebサーバもCore2なので、アップデートがあるはず。AOpenは、i945GTt-VFAのアップデートをいつ出してくれるのかな？
そろそろ、当公開サーバのバックアップと思い思案。USBスティック、DVD-R、DVD-RW等扱えるが、必ずベリファイが入って安心のDVD-RAMへdumpで実施。どういう訳かあまり実施例が見あたらない。
まず、/usrのスライスから。
ettcweb0# dump -0 -a -L -C 32 -f /dev/acd0 /dev/ad4s1f DUMP: Date of this level 0 dump: Tue Jul 3 21:34:28 2007 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ad4s1f (/usr) to /dev/acd0 DUMP: mapping (Pass I) [regular files] DUMP: Cache 32 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 4267239 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 13.79% done, finished in 0:31 at Tue Jul 3 22:11:38 2007 DUMP: 32.27% done, finished in 0:20 at Tue Jul 3 22:06:22 2007 DUMP: 53.91% done, finished in 0:12 at Tue Jul 3 22:03:12 2007 DUMP: 75.98% done, finished in 0:06 at Tue Jul 3 22:01:42 2007 DUMP: 97.92% done, finished in 0:00 at Tue Jul 3 22:00:54 2007 DUMP: DUMP: 4459505 tape blocks on 1 volume DUMP: finished in 1588 seconds, throughput 2808 KBytes/sec DUMP: Closing /dev/acd0 DUMP: DUMP IS DONE
スーパマルチDVDの日立 GSA-T10NはDVD-RAMの5倍速に対応しているのでバックアップ時間はそれほどかからなかった。しかし、テープのようにその場から書き込めるかどうか分からないので、別スライスをdumpするときは別のメディアに掛け替えねばならない。自動化しにくくて不便。やってみると、なるほど実施例がないわけだと思う。手動で順番にSWAPや/tmpをのぞくスライスを全てバックアップを実施。
メインクライアント(ettc-main2)の仮想メモリ専用に設定している2つのドライブの内、片方が論理的に壊れてマウントされていなかった。
BIOSが変わったのでベンチマークを取っておこうとして発見。遅くなったのには気がついていて、昨日などはデスクトップマネージャなどをOffにしたりしてみていた。イベントビューアによると7月1日朝には壊れた記録がある。あわただしい朝に起動したから何かやってしまった。
この辺はHostRAIDはつくづく弱いと思う。ZeroチャネルRAIDとはいえ、インテリジェントカードによるRAIDでは全く経験しなかった不安定さ！高いだけのことはあったんだなあ。
フォーマットし直して再起動。以降異常なし。
メインクライアントのettc-main2は、Supermicro X7DAEをマザーボードに使っている。このM/BのチップセットはIntel 5000XでメインメモリにFB-DIMMを使っている。
このFB-DIMM関係の設定について情報が少なく試行錯誤。
通常のIntelデスクトップ系チップセットは「デュアルリンク」で2枚のDIMM（DDR2-SDRAM）を並列に読み出すことで速度を速度を向上させている。5000Xの場合さらにインターリーブで読み出すことで、速度を向上する。インターリーブについては、Wikipediaのメモリインターリーブを参照。インターリーブはEDO-DRAMの頃はよく聞いた手法だが、この頃の聞かなくなっていた。
FB-DIMMにTranscend TS256MFB72V6K-Tを使っていて、これは1枚で2バンクになるので1:2のインターリーブで最適と思うとそうではなく、1:4の時が速度が出ているように思う。さらに、次のようなパラメータがあり、試行錯誤の最中。
この設定で、CrystalMark 2004R2 [0.9.123.322]｛ (C) 2001-2007 hiyohiyo｝のMEM項目が以下の通り。
| MEM | 13644 |
|---|---|
| Read | 4514.75 MB/s (4514) |
| Write | 1929.11 MB/s (1929) |
| Read/Write | 1958.78 MB/s (1958) |
| Cache | 52214.20 MB/s (5221) |
インターリーブ以外は、BIOS初期値の通りDisableにしてしまえばベンチマーク上は速いのだけど、どうも安定しないし、FB-DIMMの本来の使い方でないように思う。元々、Intel 5000シリーズは、FB-DIMMを4枚使って、インターリーブを十分効かせて優雅に使わないと、本来の能力を出さないようだ。4枚使って、1:4のインターリーブを行うか、4バンクのFB-DIMMを2枚使うか。Transcend 1Gbyte 633 FB-DIMM4枚使って、8Gbyte/s弱の能力が出ている機械があるので、もう2枚Transcend TS256MFB72V6K-Tを手に入れて詳しく調べてみようと思う。
昨日の続きで、FB-DIMM関係のパラメータを変えて速度の変化を見ようと思っていたが、Windows UpdateでSilicon Image関係のドライバ類アップデートがあったのでそちらを優先。
対象は、型番は違うが同じSilicon ImageのSATAコントローラを使っている録画用PC(ettcsmal)とメインクライアント(ettc-main2)。録画PCは、ドライバ本体と疑似プロセッサのアップデート、メインクライアントは疑似プロセッサのみ。全く違う性格のコントローラーなのに共通の疑似プロセッサ、頻繁に更新があるけどいったい何だろう。
Silicon Imageのアップデートに先立ってWindows Update自身もアップデートが合ったが更新ページ自身のエラーの表示で更新が出来なかった。複数回リトライしても出来なかったのが、IE一旦落として立ち上げ直したらあっさり成功。IE側の問題だったのか？
録画PCのセキュリティ関係のプログラム、日本CAの総合セキュリティソフトの中からAntiVirus系だけ入れていた。ライセンスがきれたので、安価で3台のライセンスが付いてくる、CAアンチウイルス2007ファミリーパックに切り替え。
ユーザ登録をしないと、インストール終了しない。それなのに、登録ページに出てくるパスワードの意味の説明が導入ガイドにない。いったい何？
メインクライアントのettc-main2は、2007/07/05 Thuのとおり、チップセットはIntel 5000XでメインメモリにFB-DIMMを使っている。
このメモリシステムが本来の動きになると思われる、FB-DIMMを2枚足して4枚差しにして速度改善の試験。結局メモリの物理的な配置は取説の記述通りにするのが速くて、下記写真通りに差し込んだ。
結局物理搭載量は8GbyteになったがOSは仕様通り4Gbyte未満しか認識しない(3Gbyte認識）。しかし、噂のようにWinXPが立ち上がらなくなるようなことはなかった。
メモリ系のパラメータは、以下の通りに落ち着いた。
この設定で、CrystalMark 2004R2 [0.9.123.322]｛ (C) 2001-2007 hiyohiyo｝のMEM項目が以下の通り。
| MEM | 20973 |
|---|---|
| Read | 7681.48 MB/s (7681) |
| Write | 4105.13 MB/s (4105) |
| Read/Write | 3973.05 MB/s (3973) |
| Cache | 51922.69 MB/s (5192) |
測定値、大きくばらつく。しかしばらつきを物ともしないぐらい悪い設定のあることも分かった。インターリーブ1:1では以下のとおり。
| MEM | 11935 |
|---|---|
| Read | 3098.84 MB/s (3098) |
| Write | 1683.39 MB/s (1683) |
| Read/Write | 1578.27 MB/s (1578) |
| Cache | 55545.14 MB/s (5554) |
インターリーブ1:2で、他のパラメータをBIOS初期値の通りDisableにしてしまえばベンチマーク上は速い事も確認した。
| MEM | 21435 |
|---|---|
| Read | 7859.26 MB/s (7859) |
| Write | 3685.36 MB/s (3685) |
| Read/Write | 3588.16 MB/s (3588) |
| Cache | 62810.59 MB/s (6281) |
他にも測ったので、ハードウエア関係のTipsにそのうちまとめたいと思う。
NVIDIA Quadro NVS 440 (ELSA)はファンレス、多ヘッドのワークステーション用。GPUが2つ内蔵され、OS上からは2つのカードが刺さっているように見えている。2つの専用ディスプレイコネクタの外でさらに2つのDVIコネクタに分離。
NVIDIA GeForce 7950 GT 512MB (MSI NX7950 GT)は非常高い能力を示すのに動画表示中にほかの画像表示能力が激減するように感じていた。左画面の能力の低さも目立つ。どうも、縦置きと横置きのディスプレイが混ざった状態での特性のように思う。そこで3Dの能力などが減少することを承知で、マルチヘッド向けに、GPUを2つ積んで独立した制御ができそうなものに変更。消費電力もピークで31.08Wと低消費電力化。本体側のメモリを増やして消費電力が増えたが、全体としては消費電力が下がったと思う。
ネットワークの遅延状況の測定に使わせていただいているJPIXのが公開FTPが23:25に停止、24:00の現在も継続中。何があった有ったのだろう？ FD-DIMM関係の内容をまとめていた時に警告メールが来たのでちょっとおどろいた。
結局本日の11時過ぎまで停止していた模様。
今回も無事復旧。再開されてほっとした。
Analogを運用し始めてしばらく経った。解析結果を眺めてみて気がついた所を調整した。
通常レベルのアップデートが公開された。
素直にアップデートに挑戦。ところが前回と全く同じ症状でHTTPアップデートできず。USBスティックでアップデートするのは面倒になってきたので、YAMAHAのtftpユーティリティを使ってアップデートした。
「Website Explorer/0.9.9.7」と名乗るWeb巡回ユーティリティがやってきていた。クローラと違い連続アクセス・画像も根こそぎ手加減無し。ちょっとびっくりした。通信網の帯域には余裕があるから特に影響はないが、窓の杜にもVecterにも掲載されているようなので今後増えるのかなぁ。
鷹の巣さんの所から、稼働チェックのパケットが来なくなっている。
[12/Jul/2007:05:16:14 +0900] "OPTIONS / HTTP/1.1" 200 "JSWC/0.3"
これが本日の最後。何となくパターンが分かってきた気がする。
昨日は、Windowsのセキュリティアップデートが有ってばたばたした感じだったが、本日は、FreeBSDのキュリティアップデートの連絡。素直にアップデート。
cd /usr/src make update make -j5 buildworld make -j5 buildkernel KERNCONF=ETTCWEB0 make installworld make installkernel KERNCONF=ETTCWEB0 reboot
いつも通り無事、本日早朝に鷹の巣さんの所からの稼働チェックのパケットが再開。
[13/Jul/2007:04:41:23 +0900] "OPTIONS / HTTP/1.1" 200 "JSWC/0.3"
「Supermicro X7DAE メモリ設定」を公開してからいつものごとく慌てて大量校正。
ネットワークの遅延状況の測定に使わせていただいている大阪大学の公開FTPが日中に完全停止。CVSのサーバも停止していた。工学部のネットワーク(eng.osaka-u.ac.jp)が止まったように見えた。これも計画メンテナンスだったのか？
基礎工学部のネットワーク(es.osaka-u.ac.jp)は生きているようなのでCVSの相手を、工学部のcvsup4.jp.FreeBSD.org (diana.comm.eng.osaka-u.ac.jp)から基礎工学部のcvsup6.jp.FreeBSD.org (infoserv.ics.es.osaka-u.ac.jp)に変更。
停止を検出しているグラフにも現れてる、遅延の不気味な増加。大阪方面も東京方面も遅延している。たまたま遅延したという感じではなく、多くのパケットが流れて全体に通信網が混み合ったことを想像させる増え方が不気味。
月グラフを見ると今日ばかりの話でなく木曜日からこの傾向が出始めている。
JPIXのトラフィックを見ても以前から続く増加傾向ではあるけれど一時に増えた感じではない。サイバーポリスのインターネット定点観測をみても何かが急増している感じはない。
となると、上位通信網の株式会社 ヴェクタントで何か起こっているのか？
自前でWeb proxyと連続運転のDNS（キャッシュ）、web専用のBBルータを運用しているのにうまく使い切れていなかったので、FireFoxのconnection系の設定を変更。
about:configで表示させてフィルタをconnectionでしぼって表示させて、関連パラメータを初期設定値の2倍に変更した。
利用している接続業者のe-mantionは、通常のアクセスにはIPマスカレード(NAT-P)を通るようになっている。ルータのセッション数を使いすぎると、接続をはねられて逆効果になる可能性が高かった。
しかし、内部Proxを運用していること、自宅内通信網のDNS、NTPが連続運転していること、固定グローバルIPを取ったので、DNSや通常のメール、自宅内用NTP、公開Webの接続などは、IPマスカレード(NAT-P)を通らなくなったこと等を諸々勘案して同時接続数に関連するパラメータを増加させた。現状異常はなく、タブで同時にオープンするときのレスポンスが良くなった。
業務サーバの回復にに関わると、一気に神経がすり減るなぁ。自宅サーバ関係の諸々の進みが一気に減少。
鷹の巣さんの所からの、サーバー稼動検査かと思ったら、全く違う不審なアクセスがあった。
[19/Jul/2007:21:10:02 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "-"
単発でユーザエージェントも何にも無し。なんでしょう？
今日は、メンテナンス系の作業をせずに利用系の作業ばかりしていた。その際、ビデオカード交換の効果を実感。
2007/07/07 SatにNVIDIA GeForce 7950 GT 512MB (MSI NX7950 GT)からNVIDIA Quadro NVS 440 (ELSA)に変更して、ベンチマーク類はがた落ちした。
| NX7950 GT | NVS 440 | |
|---|---|---|
| GDI | 13753 | 10649 |
| D2D | 10447 | 3580 |
| OGL | 30579 | 15278 |
多画面の業務用テキストやグラフを表示するが主目的のビデオカードだから、OGLは低くなっても他がもうちょっと高くあって欲しいと落胆していた。しかし、実際に使いはじめると、今の使い方でのレスポンスの良さは格段に良くなっている。
「GPUが2つ有るので、縦置ディスプレイと、横置ディスプレイに別々のGPUが割り当てられて、それぞれ干渉無く動いてくれるかな？」という当初もくろみは、見事に成功。また、予想外にNVS400 GPUが縦置きに強いと言うことがおおきく効いているよう。縦置ディスプレイ側の反応の良さは、GeForce 7950 GTは段違いになっている。
結果、1600x1200と言う大きめのマルチディスプレイを使って、編集が済んだ動画を再生ソフトで横目で確認しながら横置きディスプレイで動画編集ソフトで次の動画を編集し、レンダリング待ちの間に、htmlのファイルをエディタで作りながら縦置きディスプレイ側でブラウザで確認するという作業が格段にやりやすくなった。
こんな用途には、NVIDIA Quadro NVS 440はベンチマークでは確認できない非常に有難い性能を発揮してくれる。ビデオカードは用途との相性が重要だなぁと実感する。
ただ、消費電力の低減効果はあまりなく、ここはもくろみが外れた。UPSの検出するピーク電力はむしろ増加傾向。ボード自身の仕様上のピーク電力は30W強と激減しているので、今の使い方が NVIDIA Quadro NVS 440の性能をかなり使っているのだと思う。逆にNVIDIA GeForce 7950 GTの負荷がかかるような使い方をしていなかったんだと思う。そう言えばいつもNVIDIA GeForce 7950 GTのGPU温度は低かった。
NVIDIA GeForce 7950 GTは、ゲームと一般の事務用、特に3Dのヘビーゲームでシングル画面の1280x1024ぐらいで一番性能を発揮する用になっているのかなぁと思う。
NVIDIA Quadro NVS 440が8800シリーズと同じ新しいプロセスになって、GDIとD2Dがの性能がGeForce 7950の2倍くらいの性能の製品が出ると嬉しい。
株式会社つなぐネットコミュニケーションズから、無償アップグレードのお知らせが来た。
同じ物ではないだろうが、同じ100M VDSLについての富士通の論文（FUJITSU ACCESS REVIEW Vol.14 No.1）26P 図8 100M VDSL伝送特性からみて実効で上下30MBps程度出てくれることを期待。結果が楽しみ。
当サイトのOSであるFreeBSD 6.2系でBIND9の更新等、大きめの変更があったようなので、リコンパイルしてアップデート。
株式会社つなぐネットコミュニケーションズから、無償アップグレードのVDSLモデムが到着。モデムは、NEC VF200F3。これは2007/07/24 Tueで想定した、下り100MBps上り35MBpsの非対称系列のモデムのよう。
ただこのモデム、去年の2006年9月30日に販売中止機種になっていて少し不安。現行機種は下り100MBps上り100MBpsの上下対象のモデムVF200F6。現行機種に比べるとVF200F3は大幅に調達コストが安いのかな？
公開サーバとしては仕様上はF3、F6どちらにしても十分なので、使ってみてどうかだけだと思う。しかし、販売中止機種になったとたんWeb上から情報を全て消してしまうNECのWeb運用方針はなんとかならないものかと思う。販売中止機種を明示して掲載して以前との比較を出来るようにして欲しい。
前週7月23日に不正アクセスを検知していた。
2007/07/23 22:35:49 ICMP too large 218.230.75.94 202.215.167.123
２−１．通信回線の２−１−２．通信網の境界に配置している、YAMAHA SRT100で初めての不正検知。あまりにSRT100で検出ししないので設定に何か不備があったかと心配していた。みょうに一安心。
先週（2007年 7月22日の週）、ウェブサーバの統計 ettcweb0.aa0.netvolante.jpの週別レポートで初めて前週を割り込んだ。更新が滞ると正直に出るなと思った。
ディスクフルにしてしまった。delegateのキャッシュを管理していなかったのとsquidのlogをちゃんとローテーションしていなかったのが要因。crontabにローテーションを1日1回するように入れてみた。
0 22 * * * squid /usr/local/sbin/squid -k rotate
newsyslogの方が柔軟にローテーションできるのでこちらでやりたいのだけど。
/usr/local/squid/logs/access.log squid:squid 644 5 1000 * J /usr/local/squid/logs/squid.pid
こんな具合で良いのだろうか？ sig_numが要りそうに思うが？もう少し調べてみようと思う。
明日は回線工事なので、自宅サーバーWebRingのリングの維持ランクを「７：トップページ自動リンク状態（リンク状態切替時メール通知有）」から「４：入口ページ自動リンク状態（リンク状態切替時メール通知無）」にしてみて変更の手順を確認した。明日の昼前には、「２：入口ページリンク状態」に変更しようと思う。