銀河の歴史がまた1ページ(日記)

Last Update (1999/12/14 23:40:29)
1997.09.06から数えて counter 番目のアクセスです。

ミラーサイト [www.ceres.dti.ne.jp] [yk.rim.or.jp]

[ホームページ] [日記] [読んでいる日記] [秋葉原価格] [FreeBSD] [FreeBSD LINK] [検索] [高速検索]

■ 宇宙歴 1999.11.23

http://www.ceres.dti.ne.jp/~george/jdiary991116.html#19991123

はうぅぅ

久しぶりの休日だったりして。 (x_x;)
沢山寝ておしまい。 (__)zzZZ

その他

ファイブスターストーリーズのページfssdb.com内部にあるFSSの謎(ネタバレ有)にて、連載中のF.S.Sで大きな動きがあるとの情報をキャッチ。 久しぶりにNew Type 12月号を買ってみた。 早速真ん中辺りの白黒ページ開く。 フロートテンプルにて、ミラージュ騎士団 v.s. ボスヤス=フォート一党の殴り込み頂上対決が開始されていた。 あっさりミラージュがやられてる………。 (T_T)

New Typeの他のページを読んでいたら、サクラ大戦3は2000年秋に発売予定との情報があった。 今度の舞台はパリで、大神隊長の下の5名全員が新メンバーになる模様。 戦術モードでコマの数が多いと、指示を出すのがタルいので、これは良い判断だとおもふ。 発売されたらドリキャスゲットかな〜。 (^^)

yk.rimのシェルホスト

アクセスカウンタとか検索ルーチンを動かすため、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で指定する場所がわからないぞ? (..)?


■ 宇宙歴 1999.11.24

http://www.ceres.dti.ne.jp/~george/jdiary991116.html#19991124

続New Type

New Typeからの情報によると、「待ってるにょん」で有名なでじこちゃんが、11/29月曜夜のワンダフル内部のアニメコーナーで登場する模様。 録画予約だだだ。

yk.rimのテスト用環境

ふらふらと探していたら、リムネット/2000年問題対応に伴うシステム更新(詳細)を発見。 ここに書いてあるやね。 で、色々試してみたけど、サーバの負荷が高いらしく、何もしていない普通のページでタイムアウトする有り様だったりして。 どーやってテストすればいいんだ………。 (x_x;)


■ 宇宙歴 1999.11.27

http://www.ceres.dti.ne.jp/~george/jdiary991116.html#19991127

秋葉原

ウチの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になっているので購入してみた。 さてさて、自動認識でどこまでいけるかな?

Switching HUB Corega Fast SW II-8P

もちろんやるこたぁ〜ひとつ。 ftpベンチマーク大会だ。 (^^;)

68MBytesと72MBytesのaviファイルを転送して、ftpコマンドのgetで転送速度を測定してみた。 エントリーしたマシンは以下の通り。

表中で *** になっている部分は、推定転送時間が1時間を越えたため、途中で測定をやめたもの。

ftpベンチマーク(単位はMBytes/sec)
送信側
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しか出てない………。 (T_T) casper(Windows98)→athlon(Windows98 SE)で同じファイルの転送を行うと、20秒くらいで終わるからボードが腐っているわけでもなさそうだし。 10BaseなHUBにつないでいた時は1.09MB/secくらいはでていたのにな〜。 ううむ。 deにはflagsも無さそうだし、さて困った。

そういえば、Corega Fast SW II-8Pって、Collisionランプが無い………。


■ 宇宙歴 1999.11.28

http://www.ceres.dti.ne.jp/~george/jdiary991116.html#19991128

rimネットその後

今野さんのところからたどって リムネットからのお知らせを見る。 11/24の件は、サーバ側の問題でタイムアウトしてたのか。 (^^;) んでもって、サーバをFreeBSDにする模様。 一体何が問題だったんだろう? (..)?

Switching HUBその後

結局、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にして、当分の間は回避することに………。 (x_x;) あ〜ん。 ばかばかばかばか〜。 こんなコトなら、ポートごとにオートネゴシエーション機能を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」を検索した所、てんこもりでてくる。 (O_O)

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 も、じつわボロボロ。 (T_T)

そんなわけで今日のところの結論。 現在のところ、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は動作報告を集めてから買いましょう。 (x_x;)

RE:スイッチングHubにCollisionランプが無い件について

スイッチングHubには原理的にコリジョンがないとのツッコミありがとうございます。 なんとなくそんな予感はしていたんですけど。(←負け惜しみ(苦笑)) (^^;)

Switching HUBにはCollisionランプは必要ないんぢゃ………というツッコミは、メールでも頂きました。 (^^;)
ありがとうございます。 m(__)m
Collisionは原理的には発生しないとはいうものの、インテリジェントスイッチの中には、Collision回数をポート毎にカウントしてくれるものもあるようです。 また、症状的には auto negotiation に失敗している可能性がありそうとのことでした。 (Full Duplex か Half Duplex かの Negotiation に失敗していると、似たような症状になるとのことです。)

NICの設定を変える

過去メーリングリストの検索でも、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接続を示すオレンジ色にならないし、よくわかんない状態………。 (x_x;)
HUB側に、full-duplex/half-duplex を示すLEDがあれば、確認に便利だったのになぁ。

yk.rimその後

11/29 00:30くらいに試したら、yk.rimのテストWebサーバの反応が無くなった。 pingにも返事しないしぃ。 FreeBSDにしても落ちちゃったのかな? (..)?


■ 宇宙歴 1999.11.29

http://www.ceres.dti.ne.jp/~george/jdiary991116.html#19991129

RE:Switching HUB

ありがとうございます〜。 ウチでは、最初に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ってば大変っす。


■ 宇宙歴 1999.11.30

http://www.ceres.dti.ne.jp/~george/jdiary991116.html#19991130

PC Userよりメモ


Copyright(c) 1996,97,98,99 George(小浜 純). All rights reserved.
私の作成したページは全部リンクフリーです。
このページに間違いや要望などがありましたら george@yk.rim.or.jp まで御連絡ください。

[ホームページ] [日記] [読んでいる日記] [秋葉原価格] [FreeBSD] [FreeBSD LINK] [検索] [高速検索]

home: <george@yk.rim.or.jp> or <george@ceres.dti.ne.jp>