久しぶりの休日だったりして。
沢山寝ておしまい。
ファイブスターストーリーズのページfssdb.com内部にあるFSSの謎(ネタバレ有)にて、連載中のF.S.Sで大きな動きがあるとの情報をキャッチ。
久しぶりにNew Type 12月号を買ってみた。
早速真ん中辺りの白黒ページ開く。
フロートテンプルにて、ミラージュ騎士団 v.s. ボスヤス=フォート一党の殴り込み頂上対決が開始されていた。
あっさりミラージュがやられてる………。
New Typeの他のページを読んでいたら、サクラ大戦3は2000年秋に発売予定との情報があった。
今度の舞台はパリで、大神隊長の下の5名全員が新メンバーになる模様。
戦術モードでコマの数が多いと、指示を出すのがタルいので、これは良い判断だとおもふ。
発売されたらドリキャスゲットかな〜。
アクセスカウンタとか検索ルーチンを動かすため、shellホスト(テスト用)にアクセス。 オープニングメッセージでちとびびる。
Copyright (c) 1996, 1997, 1998, 1999 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. NetBSD 1.4.1 (RIMNET1) #3: Sat Nov 13 03:28:25 JST 1999 Welcome to NetBSD!
おおお〜。
前にお知らせでも言ってたけど、本当にNetBSD使ってる〜。
perlとかnkfとかgrepも入っている模様。
rubyは入ってなかった。
早速自作アクセスカウンタをコンパイルしてみたが、外部からのテスト方法はどーするんだろう?
shellホストのport 80は閉じているみたいだけど。
IMG SRCで指定する場所がわからないぞ?
New Typeからの情報によると、「待ってるにょん」で有名なでじこちゃんが、11/29月曜夜のワンダフル内部のアニメコーナーで登場する模様。 録画予約だだだ。
ふらふらと探していたら、リムネット/2000年問題対応に伴うシステム更新(詳細)を発見。
ここに書いてあるやね。
で、色々試してみたけど、サーバの負荷が高いらしく、何もしていない普通のページでタイムアウトする有り様だったりして。
どーやってテストすればいいんだ………。
ウチの640 MOドライブの調子が悪いので、新しいMOドライブをゲットするため秋葉原を散策。 タバコをMOドライブの前で吸っていると、ドライブが早く壊れるような気がする。 (自業自得とも言う………。)
途中でまねきさんに遭遇。 こたつ仕様のNLXマシンを組み立てるため、パーツを採集中とのことだった。 USBキーボードだとろくなキーボードがないね〜などと話をして、それぞれ買い物に出発。
Fujitsu SMB-1200W | 64,800 | ZOA |
SCSI Cable | 1,480 | ZOA |
Corega 8 port 100/10M Switching HUB | 9,380 | T-ZONE ミナミ |
ついつい買ってしまったGiga-MO。
こんなん回りで誰も持ってないぞ。
Switching HUB Corega Fast SW II-8P は単なる衝動買い。 おうちLAN内部では、ノートマシンだけ10Baseで、デスクトップマシンは全部100/10Baseになっているので購入してみた。 さてさて、自動認識でどこまでいけるかな?
もちろんやるこたぁ〜ひとつ。
ftpベンチマーク大会だ。
68MBytesと72MBytesのaviファイルを転送して、ftpコマンドのgetで転送速度を測定してみた。 エントリーしたマシンは以下の通り。
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:00:f4:5a:92:26 media: autoselect (100baseTX <full-duplex>) status: active supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.5 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:e0:18:a8:22:bf media: autoselect (100baseTX <full-duplex>) status: active supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.11 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:00:1c:b5:70:a1 media: autoselect (100baseTX <full-duplex>) status: active supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
sn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:00:86:10:33:e0
表中で *** になっている部分は、推定転送時間が1時間を越えたため、途中で測定をやめたもの。
送信側 | |||||
magi | casper | athlon | asuka | ||
受信側 | magi | --- | 3.54 | 3.40 | 0.88 |
casper | 2.46 | --- | 2.55 | 0.86 | |
athlon | *** | *** | --- | 0.88 | |
asuka | 0.84 | 0.88 | 0.88 | --- |
速いところでは 3.5MBytes/secの転送速度がでていてちょっと嬉しい。
70MBytesのファイルも20秒で転送完了だっ。
(後日談:本当は 8MBytes/secくらい出ても良さそうなものなんだけど。)
ノートマシンに刺さっている10Base-Tのカードは、まずまずの調子。
ところが、athlonでのgetが大変まずい状況になった……。
転送終了まで1時間かかるという予測がでるくらいだから、19KBytes/secしか出てない………。
casper(Windows98)→athlon(Windows98 SE)で同じファイルの転送を行うと、20秒くらいで終わるからボードが腐っているわけでもなさそうだし。
10BaseなHUBにつないでいた時は1.09MB/secくらいはでていたのにな〜。
ううむ。
deにはflagsも無さそうだし、さて困った。
そういえば、Corega Fast SW II-8Pって、Collisionランプが無い………。
今野さんのところからたどって
リムネットからのお知らせを見る。
11/24の件は、サーバ側の問題でタイムアウトしてたのか。
んでもって、サーバをFreeBSDにする模様。
一体何が問題だったんだろう?
結局、athlonでの受信がにんともかんともならんので
+---------------------------------+ | Switching HUB 100M/10M | | 1 2 3 4 5 6 7 8 x | +---------------------------------+ | | | | asuka | | casper magi | +-----------+ | | +---------------------------------+ | HUB 10M | | 1 2 3 4 5 6 7 8 x | +---------------------------------+ | athlon
ってな具合いにカスケード。
athlonのネットワークカードを強制的に10Base-T/UTPにして、当分の間は回避することに………。
あ〜ん。
ばかばかばかばか〜。
こんなコトなら、ポートごとにオートネゴシエーション機能をOFFにして、強制的に通信モードを設定できるcorega Fast SW-8Dを買えば良かった〜。
athlonのケースを開けるのが面倒なので、dmesg | grep de0 してみた。
de0: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 11 on pci0.8.0 de0: 21143 [10-100Mb/s] pass 4.1 (invalid EESPROM checksum) de0: address 00:00:1c:b5:70:a1
このカードは21143を使っているらしい。
なんだか、invalid EESPROM checksumとかでてるし………。
統合版検索ページにて「DEC 21143」を検索した所、てんこもりでてくる。
FreeBSD-net-jp [2107]にて、freebsd-currentにテスト用ドライバの告知があったよーんという話があったのでリンクしてみる。
freebsd-net-jp [2106]では、DEC chip 21140/21143 の pass 4.1 はダメダメという話もある。 ああぁ、athlonの21143はモロに pass 4.1 ぢゃん。 (ちなみに、magiの 21140Aは pass 2.2)
FreeBSD-net-jp [2104]では、ftpベンチマークをとった人がいて、やぱし DEC 21143 pass 4.1でスカタンな結果に終わっていた。
FreeBSD-users-jp [44520]では、DEC chip のデータシートへのリンクなどがある。
データシートを拾ってみたものの、レジスタ情報などは書いてなくて困った。
DEC-21143のレジスタ情報などは、Intel Networking Components - Manuals/User's Guidesにある21143 Hardware Reference Manualをゲットすると書いてある。
また、FreeBSD-users-jp [44314]にはDEC chipのドライバへのリンクがあった。
FreeBSD-users-jp [40044]内部には、dmesg中のde0 Invalid EESPROM checksumというエラーを出さなくするパッチがある。 どうやらCRCの計算方法が途中で変更になったようだ。 メール中の差分を取り出したもの。(FreeBSD 3.3Rの/usr/src/sys/pci/if_de.cより)
ちと netstat -nI de0 / netstat -nI fxp0 をやってみる。
george@athlon ~ $ netstat -nI de0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll de0 1500 <Link> 00.00.1c.b5.70.a1 4998 0 3151 2855 0 de0 1500 10/24 10.0.0.11 4998 0 3151 2855 0 george@magi ~ $ netstat -nI de0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll de0 1500 <Link> 00.00.f4.5a.92.26 8934 0 12815 12568 0 de0 1500 10/24 10.0.0.1 8934 0 12815 12568 0 george@casper ~ $ netstat -nI fxp0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 <Link> 00.e0.18.a8.22.bf 8221 0 9289 0 0 fxp0 1500 10/24 10.0.0.5 8221 0 9289 0 0
動いているように見えた magi の de0 も、じつわボロボロ。
そんなわけで今日のところの結論。
現在のところ、1999年3月ごろから流通し出したと思われる DEC Intel Ether chip 21143の最新版と思われる pass 4.1 は、FreeBSDのftpで壊滅的な性能低下が起こる場合があるので避けたほうが無難。
(21143 pass 4.1でもちゃんと動いているという人もいるのでよーわからん。)
21143 pass 2.2でも、Switching HUBの種類によっては結構ボロボロなことがある。
本日の教訓:イーサネットカードは黙ってIntelを買いましょう。Switching HUBは動作報告を集めてから買いましょう。
スイッチングHubには原理的にコリジョンがないとのツッコミありがとうございます。
なんとなくそんな予感はしていたんですけど。(←負け惜しみ(苦笑))
Switching HUBにはCollisionランプは必要ないんぢゃ………というツッコミは、メールでも頂きました。
ありがとうございます。
Collisionは原理的には発生しないとはいうものの、インテリジェントスイッチの中には、Collision回数をポート毎にカウントしてくれるものもあるようです。
また、症状的には auto negotiation に失敗している可能性がありそうとのことでした。
(Full Duplex か Half Duplex かの Negotiation に失敗していると、似たような症状になるとのことです。)
過去メーリングリストの検索でも、auto negotiationに失敗しているんでわ?という話が出ていたので、ifconfigを使って media type と mediaopt を変更してみるテスト。
ifconfig de0 down ifconfig de0 inet 10.0.0.11 netmask 255.255.255.0 media 10BaseT/UTP -mediaopt full-duplex ifconfig de0 up
とかやっても、SW Hub側のLED表示は10M接続を示すオレンジ色にならないし、よくわかんない状態………。
HUB側に、full-duplex/half-duplex を示すLEDがあれば、確認に便利だったのになぁ。
11/29 00:30くらいに試したら、yk.rimのテストWebサーバの反応が無くなった。
pingにも返事しないしぃ。
FreeBSDにしても落ちちゃったのかな?
ありがとうございます〜。 ウチでは、最初にHUB側にて100M接続を示すLEDが点灯します。 HUBによっても違うんでしょうね。 で、sleep 技を早速やってみました。
ifconfig de0 inet 10.0.0.11 netmask 255.255.255.0 media 10BaseT/UTP mediaopt full-duplex mtu 1500 sleep 1 ifconfig de0 down sleep 1 ifconfig de0 up sleep 1 ifconfig -a
上記のコマンド列を実行しても、HUB側の100M/10Mを示すLEDは変化しませんでした。 うちのHUBには効かない模様です。 なんだかauto negotiationってば大変っす。