Product	Total
Cold Heat Soldering Tool - Soldering Tool	$19.99
Cold Heat Soldering Tool - Conical Tip	$9.99
Namco TV Classics - Ms. Pac Man	$24.99
Jolt Gum - Spearmint Office Box	$16.99
Sub Total:	$71.96
Sales Tax:	$0.00
Shipping & Handling:	$27.30
TOTAL:	$99.26

　まずは、Cold Heat Soldering Toolのファーストインプレッション。

　ケースは安っぽいが、中の本体は想像より品位のある外装。大きさはほぼ予想通り。スイッチがスライド式なのは意外だった。というのも、押して1秒でハンダ付けできるとのことなので、ボタン押しながら使うものと思っていたのだ。電池は単3が4本。本体下部の2本のネジを外し、カバーを外してセットする。ネジはカバー側から抜けず、ネジ受け部は金属だ。比較的頻繁に電池を入れ替えなければならないだろうから、この辺がシッカリしているのはポイントが高い。ちなみに、上の右の写真の矢印の元がカバーのネジ、矢印の先が金属のネジ受けだ(下のニセカメラは重し代わりで深い意味はない)。電池室にはリボンが付いていて楽に取り出せるようになっているが、これはなくてもよかったかも。

　ペン先に当たる部分に、添付のbevelタイプのコテ先をセットしてみた。スッと差し込むだけだが、キッチリとハマる。上下ひっくり返して差し込むこともできた。スイッチをONにすると、コテ先下部の白色LEDが点灯。コテ先の付近を照らすようになっている。実はこれもかなり便利でポイントが高い。このハンダゴテは電池駆動だからLEDを点灯するにも都合がよいだろうが、すばらしいアイデアだ。

　早速、ハンダを当ててみる……が、溶けない。1秒ってのは過剰広告か!? と思いきや、コテ先のスリットの中に差し入れた瞬間、溶けた!! なるほど!! 瞬時に使える秘密はコレか。どうやら、スリットの左右に電気が流されており、それを短絡させる形にすると発熱しハンダを溶かすらしい。たまに火花がちょっと赤く光ったりもする。なるほどと感心しつつ、スイッチを切って数秒後、恐る恐るコテ先を触ってみると、ほんのり暖かい程度。こりゃスゴイ。しかもこのハンダゴテ、ハンダ置き台も、コテ先を拭うスポンジも必要ないときた。コテ先にハンダが付かないのだ。まだ、本格的に使ったわけではないが、ハンダ吸い取り線もちゃんと使えたし、ハンダゴテ革命ですぞ、これは!! 近いうちに実戦投入してみて、続きのレポートをしたいと思う。

　次に、Namco TV Classics - Ms. Pac Manのファーストインプレッション。

　ブリスタパッケージを剥ぐと、前の製品と同じくシッカリした感じの筐体である。今回は電池室は裏面でなく、背面。ネジを1本外して単3電池を4本セット。前の製品はいまだに電池が切れていないことだし、ネジ止めでも問題ないだろう。

　テレビにつないでスイッチオン。前の製品と同じく2,3秒でゲームセレクト画面が出た。細かいゲームのインプレッションは後日に譲るとして、今回はリセットボタンに工夫がある。前の製品はリセットボタンを押すとハード的にリセットがかかる感じだったが、今回の製品はメニューが現れてメニューに戻るかどうかが選択できるようになっているのだ。見方を変えるとポーズができるということでもある。個人的にはポーズは必要悪だと思うのだが、前の製品では思わずリセットを押してしまうことが度々あったので、これは素晴らしい改善であることに違いない。

　それから、ちょっと気にしていたポールポジションのハンドル操作である。最初にプレイした時、ジョイスティックを倒したが車が全く曲がらない。さては、ジョイスティックを回転させるのかと思い、ザンギエフな感じにスクリューパイルドライバーをかけたがやっぱり車は曲がらない。実は、ループレバー状にジョイスティックをヒネるのが正解であった(ループレバーと違い、無段階に曲がり、センターにリターンもする)。ちゃんとアナログ挙動しているようだし、こりゃ素晴らしいアイデアである。一通りどのゲームもいわゆる「節目」までプレイしてみたが、基本的にどのゲームも再現度は高そうだった。今後、各々のゲームごとに細かいレポートをしていくので期待しててほしい。

　最後に、Jolt Gum - Spearmint Office Boxのファーストインプレッション……つーか味見。

　箱がカッコよかったので、Office Boxの方を買ったのだが、職場の机の上には置いておけないほどデカかった。これなら通常包装のものを買えばよかったかな。割安だったし。

　味は、ミント系だが甘ったるい感じ。甘ったるい味が抜けると、ちょっとピリッとしたニッキ系の味が微妙に残る。マズくはないが、さして刺激的でも、変わった味でもなかった。まぁ、飽きなさそうな味だし。カフェインを摂るためのガムでもあるから、いいんだけど。なんでも、1箱に100パック、各々2粒入っていて、2粒でコーヒー1杯分のカフェインが摂れるそうだ。1日の仕事中デカいステンのマグでコーヒーや日本茶をガブガブと3杯は呑むおいらなので、誤差範囲か？ま、食べすぎはよくなさそうなので、1日1パックにしておくことにしよう。

　というわけで、今日はThinkGeekの宣伝に終始してしまったが、ホントによい買い物だった。ThinkGeekには日本では売ってない魅力的なグッズが盛りだくさんなので、英語に自信がない人も挑戦みてはいかがだろうか。特にハンダゴテに関してはそのうちマニュアルの和訳をここに載せる予定である。ではまた。

本日のツッコミ(全1件) [ツッコミを入れる]

■ ｆｋ [　突然すいません！２００４年の書き込みに今頃コメントですが、実は昨日ＣＯＬＤＨＥＡＴ(９９７円）をコストコで入手し..]

2006-08-16(Wed) プロジェクトマネージャを目指す

　さて先日、秋葉で下見してきた情報処理試験の教本がAmazonから届いた。

　なんと次回は、神をも恐れずに「プロジェクトマネージャ」に挑戦してしまうのであった。いやなに、昨年「アプリケーションエンジニア」に落ちたのにリベンジはしないのか、という話もあるが、ちょっと報奨金の関係でアプリよりはプロマネなのである。オイラの場合、アプリが受かっても7.5万だが、プロマネが受かると20万ももらえるのだ。地獄の沙汰も金次第、ひゃっ、ひゃっ、ひゃっ……と、安駄婆も言っているしな。

　 ……んが、ハッと気が付くとビール呑んでいて、本は開かれるコトなくおやすみなのであった。いやなに、受かる時というのは、勉強せんでも受かるモンなのだッ!!　では……。

[ツッコミを入れる]

2008-08-16(Sat) DVDを外付ける

　とりあえず、光学式スリムドライブケース、SLIM-U02Bを買う。

[ツッコミを入れる]

2011-08-16(Tue) 結石の製作体験

　ガキの小便は高速だ。連れションすると速さに驚く。量が少ないのもあるのだろうが、パッと出て、すぐ終わる。自分もこんな頃があったような気がする。オッサンになると、そうはいかない。出るまでに時間がかかるし、終わるまでにも時間がかかる。

　ガキは勝負にこだわる。どっちが速く終わるか勝負、なんてケシカけると、盛り上がりまくる……んが、この週末、ハナから負ける勝負とはいえ、ちょっと負けすぎた気がする。これは……残尿感というやつか。出した直後なのに、またトイレ。ここ数日、急にだ。いままで、こんなことはなかったのに。

　ある朝、下腹部がわずかにチカチカする。おかしいなぁ、と思いつつ、職場へ。んが、昼になる前、左の足の付け根あたりが痛み出す。おかしいなぁ、と思いつつ、トイレの大へ。しかし、最中、痛みが強烈になってきた。これはイカン、かなり痛い。このままの調子で痛みが増すと、尻すら拭けなくなりそうだぞ。ややや。

　しかし、徐々に痛みは引いてきた。結石だと、耐え難いと聞くが、それほどではなかった感じ。とすると、盲腸かもしれん。面倒くさいなぁ。自席に戻り、まだ痛い腹を押さえて、しばらくうなる。

　と、痛みがかなり引いてきた。結局、なんだったのだろう。トイレの小に行く。あ。茶色の粒っぽいものが転がっている。やはり、結石だったようだ。

　ちょっと調べたところ、5ミリ角を超える場合は、通常の経路では排出困難とある。オイラのは2ミリ角未満だ。痛みがそれほどでもなかったのは、小ささのおかげだろうな。「体験版」って感じだ。

　オイラのオヤジは、幾度となく結石を製作している。遺伝的な要素があるかもしれん。とりあえず、今回の「結石の製作体験」は、なかなかに面白い体験だった。決して、今後、どんどん製作していきたくはないが。

　にしても、恐ろしく痛い割には、ポトンと落ちれば、即、完治、という病気ってのも、面白い病気であることよ。

[ツッコミを入れる]

2014-08-16(Sat) E4突破

　もぉおぉ～、熊野っちカスダメ出すのやめてよ〜……って、那智もじゃん、何やってんの？

　 18, 19回目が上記の体たらくで、ついに燃料が1万を切ってしまった。先日、モノホンの雪風の錨に触れ、スーパーラックにあやかっているはずなのに……。

　 21回目の出撃でようやく撃破。E6の可能性がまた薄れたな。いや、雪風効果は、E6で発現するのだと信じよう。

　しかし、艦これはランダム性の割合が絶妙だな。それによる演出がドラマチックすぎる。

[ツッコミを入れる]

2021-08-16(Mon) anacronの挙動の細かすぎるところを伝えたい

　ひょんなことからanacronの挙動を洗うことになった。

　これまで「かなり奇妙な挙動をするらしい」というだけの認識だったが、いざ知ってみれば、やっぱりかなり奇妙だった。詳細は「細かすぎて伝わらないanacronの挙動」という文書にあって、ものすごく参考になったのだが、やっぱり細かすぎて伝わりにくい……ので、ちょっと図化してみた。

　まず、前提はこの「/etc/anacrontab」内の設定。着目点は「RANDOM_DELAY」の「45」と「START_HOURS_RANGE」の「3-22」と「delay in minutes」の「25」だ。

# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days   delay in minutes   job-identifier   command
7	25	cron.weekly		nice run-parts /etc/cron.weekly

　それにより、以下のような挙動が導かれる。

    2:00                          2:30                          3:00                          3:30                          4:00
    |---------+---------+---------+---------+---------+---------|---------+---------+---------+---------+---------+---------+---------+----
     2:01 anacron 起動
      0 + 25 = 25 ----------> 2:26 (開始せず, RANGE 外)
      :
     33 + 25 = 58 -------------------------------------------> 2:59 (開始せず, RANGE 外)
     34 + 25 = 59 --------------------------------------------> 3:00 (開始)
      :
     45 + 25 = 70--------------------------------------------------------> 3:11 (開始)
     ^^   ^^                                                     3:01 anacron 起動
      |    +-- delay in minutes                                   0 + 25 = 25 ----------> 3:26 (開始)
      +-- RANDOM_DELAY                                            :
                                                                 45 + 25 = 70 -------------------------------------------------------> 4:11 (開始)
    |---------+---------+---------+---------+---------+---------|---------+---------+---------+---------+---------+---------+---------+----
    2:00                          2:30                          3:00                          3:30                          4:00
    開始する可能性のある範囲....................................oooooooooooo..............oooooooooooooooooooooooooooooooooooooooooooooo...

　上述の「細かすぎて伝わらないanacronの挙動」では、

3:00〜3:11 （2:01の回の anacron で起動された場合）、または
3:32〜4:11 （3:01の回の anacron で起動された場合）

　となっていたが、それは、

3:00〜3:11 （2:01の回の anacron で起動された場合）、または
3:26〜4:11 （3:01の回の anacron で起動された場合）

　の誤りだ。「6分に調整するロジックがソースのどこにも見つからない」といいつつ、それを入れてしまっているようだ。

　実際のログから抽出したログをエビデンスとして貼っておく。

xxx nn 02:01:01 xxxxxxx anacron[nnnnn]: Will run job `cron.weekly' in 59 min.
xxx nn 03:00:01 xxxxxxx anacron[nnnnn]: Job `cron.weekly' started
 
xxx nn 02:01:01 xxxxxxx anacron[nnnnn]: Will run job `cron.weekly' in 70 min.
xxx nn 03:11:01 xxxxxxx anacron[nnnnn]: Job `cron.weekly' started
 
xxx nn 03:01:01 xxxxxxx anacron[nnnnn]: Will run job `cron.weekly' in 25 min.
xxx nn 03:26:01 xxxxxxx anacron[nnnnn]: Job `cron.weekly' started
 
xxx nn 03:01:01 xxxxxxx anacron[nnnnn]: Will run job `cron.weekly' in 70 min.
xxx nn 04:11:01 xxxxxxx anacron[nnnnn]: Job `cron.weekly' started

　 ……が、挙動はそうとしても「delay in minutes」は「10」くらいにしておいて「RANDOM_DELAY」と「delay in minutes」の和は55を超えない程度にしておくべきではないか。なんでこんな混乱を招くような設定がデフォなんだよ……。

[ツッコミを入れる]

2024-08-16(Fri) 測れ帯域・USBイーサたちの競演

　普通のノートPCにUSBイーサを追加し、ブリッジの役割をさせることで、スイッチングハブなしに有線接続の機器を増やすという思いつきの続きだ。

　実際にブリッジまで組んでみたものの、なぜか仕事PCにIPアドレスが付かないために通信ができない。ブリッジを挟んだってサブネット(172.28.0.0/16)は同じなんだから、既存のLinuxルータのDHCPからIPを振られることを期待してたんだが、なんでや？ ……と、思ったが、ブリッジはブロードキャストを通さないのであった。DHCPはクライアントがブロードキャストで「オレのIPくれ〜」と叫ぶのが始まりであるから、それがLinuxルータまで届かなければ、そら付かん。

　そういう時のために、DHCPパケットをリレーするデーモンがなかったけな、と思って探したらあった。「dhcp-relay」だ。

# dnf install dhcp-relay
# cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/
# vi /etc/systemd/system/dhcrelay.service 
# diff /usr/lib/systemd/system/dhcrelay.service /etc/systemd/system/dhcrelay.service 
< ExecStart=/usr/sbin/dhcrelay -d --no-pid
> ExecStart=/usr/sbin/dhcrelay -d --no-pid 172.28.0.1
# systemctl daemon-reload
# systemctl start dhcrelay
# systemctl status dhcrelay
# systemctl enable dhcrelay

　これで、無事にIPアドレスが付いた……のだが、まだ通信ができない!? え、なんで!?

　どうやって情報を見つけたのか忘れたが、Linuxのブリッジにはなぜか「iptablesを通す(→結果、捨てられる)」という仕組みがあるらしい。セキュリティレベル強化の一環なのだろうが、機能の積み重ね(レイヤ)的におかしなことになっていないか、それは？基本レイヤ3を扱い、ルータのレイヤに居る「ip」tablesなのだよね。まぁ、理屈は置いといて、その動作は以下で解除できるらしい。

# cat /proc/sys/net/bridge/bridge-nf-call-iptables 
1
# echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables 
# cat /proc/sys/net/bridge/bridge-nf-call-iptables 
0

　再起動後も有効になるようにsysctlに書いておく。ついでなので、一族郎党皆殺し。

# sysctl -p /etc/sysctl.d/50-bridge-nf-call.conf 
# vi /etc/sysctl.d/50-bridge-nf-call.conf
# cat /etc/sysctl.d/50-bridge-nf-call.conf
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0

　無事、通信ができるようになった……と、ここで気づいたのだが、さっきの「dhcp-relay」って必要だったのか？ホントに「ブリッジはブロードキャストを通さない」んだっけ？と思って、改めて調べたら、ブロードキャストを通さないのはルータだ。ブリッジはブロードキャストを通す。「MACを学習して必要のないパケットをフィルタする」というブリッジ/スイッチの特性と混同していたようだ。

　「dhcp-relay」はサブネットが異なる(ルータの先の)場所にDHCPサーバが置けるようにすることで、DHCPサーバを集約するためのものだ。「dhcp-relay」を落とした後も、仕事PCへのIPアドレスの付与に影響はなかった。「dhcp-relay」で改善したのも確かっぽいが、真の原因はブリッジがiptablesを通していたこと。ま、試行錯誤する中ではよくあることよ。

　通信ができるようになったところで、お楽しみのスピードテスト。まずは、普通に主力PCで試してみる。普通つうても、こいつの上流にもLinuxルータはいるんだけれどね。

　結果は「下り808.6Mbps, 上り865.8Mbps」。理論値の8割以上も出ているんだから十分だろう。その時のdstatの結果が以下。

# dstat 1 
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
  4   3  89   0   0|   0   140k|   0     0 |   0     0 |8856    13k
  3   2  93   0   0|   0   381k|  10k   12k|   0     0 |4999  6892 
  4   2  91   0   0|   0   384k|  33k 8780 |   0     0 |6221  8058 
 28  11  57   0   0|   0     0 | 206M 1409k|   0     0 |  59k   24k
 27  11  58   0   0|   0     0 | 211M 1278k|   0     0 |  60k   24k
 20  10  66   0   0|   0     0 | 118M   47M|   0     0 |  42k   21k
 23  10  61   0   0|   0  4093B| 406k  239M|   0     0 |  22k   20k
 25  11  59   0   0|   0     0 | 432k  240M|   0     0 |  22k   20k
 23  10  60   0   0|   0    40k| 405k  235M|   0     0 |  22k   20k
 24  10  59   0   0|   0     0 | 412k  238M|   0     0 |  22k   20k
 23  11  59   0   0|   0   152k| 377k  238M|   0     0 |  22k   21k
 20  10  63   0   0|   0     0 | 397k  217M|   0     0 |  21k   19k
 22  11  61   0   0|   0    40k| 469k  217M|   0     0 |  21k   19k
 20  10  64   0   0|   0     0 | 403k  232M|   0     0 |  21k   20k
 27  13  54   0   0|   0     0 | 470k  236M|   0     0 |  22k   21k
 17   8  70   0   0|   0    56k| 268k  136M|   0     0 |  16k   16k
  6   3  89   0   0|   0    56k|  18k 9246 |   0     0 |7390  9949 
  4   2  92   0   0|   0   104k| 110    70 |   0     0 |5797  8192 
  3   2  93   0   0|   0     0 | 236   654 |   0     0 |4232  5827

　 recvが200M前後、sendが220M前後。前に書いた時はenp2s0とppp0との二重計上だったが、今回はenp3s0f0とbridge0とで二重計上されている。2で割ると、200Mなら100Mで800Mbps、220Mなら110Mで880Mbpsなのでだいたい合っている。usrが20%、sysが10%というCPU使用率も着目点だ。スピードテストはhttps/tcp通信っぽいが、十分に余裕があるといえよう。

　次は、本題の仕事PC。さて、ブリッジを通してもちゃんと速度が出るのか。

　結果は「下り835.0Mbps, 上り859.1Mbps」。ほぼ同等に出ているといえよう。その時のdstatの結果が以下。

# dstat 1 
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 11   4  78   4   0|   0   100k| 386B   66B|   0     0 |2345  5408 
 13   5  77   2   0|   0     0 | 326B   66B|   0     0 |2716  7648 
 10   4  82   3   0|   0     0 | 386B   66B|   0     0 |2219  5155 
 30  13  55   1   0|   0     0 |  37M   96k|   0     0 |  19k 9051 
 28  24  45   2   0|   0     0 | 106M  183k|   0     0 |  46k   12k
 27  23  48   1   0|   0     0 | 106M  184k|   0     0 |  46k   12k
 25  18  54   2   0|   0     0 |  65M   12M|   0     0 |  37k   12k
 25  13  61   1   0|   0     0 | 289k  110M|   0     0 |  71k   11k
 24  11  62   2   0| 128k  140k| 316k  110M|   0     0 |  70k   10k
 26  10  62   1   0|   0     0 | 309k  111M|   0     0 |  70k   10k
 24  11  63   1   0|   0     0 | 312k  109M|   0     0 |  69k   10k
 24  11  62   1   0|   0     0 | 322k  110M|   0     0 |  70k   10k
 25  12  61   1   0|   0     0 | 327k  110M|   0     0 |  69k   10k
 25  13  62   2   0|   0     0 | 351k  110M|   0     0 |  69k   11k
 23  11  62   2   0|   0    60k| 309k  109M|   0     0 |  69k   10k
 24  11  62   2   0|   0     0 | 294k  110M|   0     0 |  70k   11k
 23   9  64   2   0|   0    16k| 294k  110M|   0     0 |  70k   10k
 23   5  68   1   0|   0     0 |  60k   21M|   0     0 |  17k 7024
 13   4  79   2   0|   0     0 | 326B   66B|   0     0 |2535  5668
 18   6  73   2   0|   0     0 | 803B 2957B|   0     0 |3026  5645
 10   4  83   3   0|   0     0 | 326B   66B|   0     0 |2197  4736

　こっちに二重計上はない。recvが105M前後で840Mbps、sendが110M前後で880Mbpsなのでだいたい合っている。主力PCのそれよりもusrとsysはわずかに高いが、N100のCPU性能がわずかに低いということだ。とはいえ、こちらも十分に余裕があるといえよう。

　ちなみに、以下は仕事PCの計測中の主力PCのdstatの結果。ブリッジとしての仕事っぷりがわかる。

　中継をしているのでrecvとsendの両方に値が出ている。中継はカーネルの処理なのでsysが上がるかと思ったが、usrが上がるようだ。とはいえ、中継するだけの場合は、httpsの処理も、tcpの処理もないので、たいして上がることはない。

# dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw
  1   1  97   0   0|   0     0 | 214   728 |   0     0 |1991  2843
  1   1  97   0   0|   0    72k| 108   660 |   0     0 |2249  3181
  1   1  97   0   0|   0     0 |  23k   21k|   0     0 |2524  3436
 12   1  83   0   0|   0     0 | 105M  106M|   0     0 |  61k 5648
 10   1  80   0   0|   0   459k| 112M  112M|   0     0 |  56k 5686
 13   1  82   0   0|   0     0 | 111M  112M|   0     0 |  65k 5884
 12   3  80   1   0|   0  2216k|  83M   83M|   0     0 |  25k 9690
  7   1  82   0   0|   0   204k| 115M  117M|   0     0 |  28k 5127
  7   1  83   0   0|   0     0 | 116M  117M|   0     0 |  28k 5053
  6   1  83   0   0|   0     0 | 115M  116M|   0     0 |  28k 5260
 10   2  78   0   0|   0    12k| 115M  117M|   0     0 |  31k 9722
  7   1  83   0   0|   0     0 | 116M  117M|   0     0 |  28k 4925
  7   0  83   0   0|   0     0 | 116M  117M|   0     0 |  29k 5037
  6   1  83   0   0|   0    92k| 114M  116M|   0     0 |  28k 5648
  6   0  84   0   0|   0     0 | 116M  117M|   0     0 |  27k 4842
  5   1  84   0   0|   0     0 | 115M  117M|   0     0 |  27k 4545
  3   0  90   0   0|   0    16k|  68M   70M|   0     0 |  17k 4062
  1   1  97   0   0|   0     0 |  10k 6306 |   0     0 |2274  3165
  1   1  98   0   0|   0     0 | 108   660 |   0     0 |2094  3088
  1   1  97   0   0|   0     0 |3539  4139 |   0     0 |2362  3421

　さらにオモシロ実験。先に「手元には100MbpsのUSBイーサしかない」と書いたが、実はもうひとつ「LUA-KTX」という100MbpsだがUSB1.1という珍妙なUSBイーサも手元にある。差込口の形状がちょっとカッコイイ。この際だ。全部いっぺんに挿して、全部ブリッジにしちゃって、スピードテストをしてみよう。LANの口が4つて、そりゃもうルータやがな。

　まずは「USB-LAN100R」という100Mbpsのイーサ。結果は「下り91.6Mbps, 上り92.8Mbps」。LANの速度である100Mbpsが理論値になるから、その9割チョイというのは妥当だ。

　その時のdstatの結果が以下。

$ dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 23   7  67   2   0|   0   189k| 150B  132B|   0     0 |3680  7029 
 18   4  74   2   0|   0    24k|8262B   12k|   0     0 |3122  6281 
 32  10  54   1   0|   0     0 |8876k  140k|   0     0 |  20k   14k
 24  10  61   2   0|   0   568k|  12M  122k|   0     0 |  25k   13k
 24  11  61   2   0|   0   160k|  12M   97k|   0     0 |  24k 9948 
 22  11  63   2   0|   0   112k|  12M  116k|   0     0 |  24k   10k
 23  11  63   2   0|   0    80k|  12M  128k|   0     0 |  24k   12k
 25  11  61   1   0| 128k    0 |  12M  163k|   0     0 |  25k   15k
 22  11  63   2   0|   0     0 |  12M  155k|   0     0 |  25k   15k
 20  10  65   2   0|   0     0 |  12M  105k|   0     0 |  24k   11k
 21  10  62   2   0|   0   112k|  12M  154k|   0     0 |  24k   14k
 21  10  67   2   0|   0     0 |  12M   83k|   0     0 |  23k 9188 
 22  10  64   2   0|  64k    0 |5602k 1651k|   0     0 |  15k   13k
 20  10  67   2   0|   0     0 |  70k   12M|   0     0 |  15k 9059 
 19   7  70   2   0|   0     0 |  72k   12M|   0     0 |  14k 8815 
 20   8  68   2   0|   0   100k|  71k   12M|   0     0 |  14k 8906 
 19   8  69   2   0|   0   192k|  73k   12M|   0     0 |  14k 8677 
 19   7  71   2   0|   0     0 |  72k   12M|   0     0 |  14k 8621 
 19   8  69   1   0|   0     0 |  70k   12M|   0     0 |  14k 8666 
 20   7  70   2   0|   0     0 |  76k   12M|   0     0 |  14k 8834 
 19   6  71   2   0|   0     0 |  68k   12M|   0     0 |  14k 8618 
 19   6  71   2   0|   0     0 |  67k   12M|   0     0 |  14k 8803 
 20   7  69   3   0|   0    32k|  71k   12M|   0     0 |  14k 8345 
 18   6  73   2   0|   0     0 |  65k   12M|   0     0 |  14k 7699 
 18   6  73   2   0|   0     0 |  68k   12M|   0     0 |  14k 7552 
 18   6  72   2   0|   0     0 |  68k   12M|   0     0 |  14k 7671 
 18   6  73   2   0|   0     0 |  67k   12M|   0     0 |  14k 7530 
 20   7  70   2   0|   0    40k|  55k 9391k|   0     0 |  12k 7368 
 21   5  71   2   0| 128k    0 | 804B    0 |   0     0 |3045  5925 
 13   4  80   1   0|   0    60k| 180B    0 |   0     0 |2279  5453

　最後に「LUA-KTX」という100MbpsのイーサだがUSB1.1というもの。結果は「下り6.76Mbps, 上り7.62Mbps」。100Mbpsどころか10Mbpsにすら達していない。これはUSB1.1の上限が12Mbpsであることによるもの。

　 12Mbpsなら10Mbps以上は出てもいいと思うかもしれないが、それはUSB通信が半二重モードであるため、受取り確認(ACK)などの逆方向の通信で消費されているためだと推測する。それでも、半分(6Mbps)以上は出ているんだから、そんなもんなんだろう。とはいえ、端末作業やブラウザで探しモノする分には十分な速度だ。ADSLを思い出せば、だいぶ速い方だよね？

$ dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 28   6  63   2   0|   0     0 |   0     0 |   0     0 |3186  6450 
 16   5  75   2   0|   0     0 |   0     0 |   0     0 |2783  6073 
  9   4  84   2   0|   0     0 |   0     0 |   0     0 |2053  4456 
 29   7  60   2   0|   0    76k| 174k   22k|   0     0 |4406  7780 
 24   6  66   1   0|   0     0 | 877k   41k|   0     0 |6371  8781 
 17   7  72   2   0|   0     0 | 872k   41k|   0     0 |6156  8867 
 16   7  73   2   0|   0     0 | 875k   38k|   0     0 |6014  9115 
 18   6  73   2   0|   0     0 | 870k   45k|   0     0 |6202  8721 
 17   7  70   3   0|   0   268k| 876k   37k|   0     0 |6081  9099 
 18   5  73   2   0|   0     0 | 878k   37k|   0     0 |6027  9076 
 17   6  73   2   0|   0     0 | 873k   43k|   0     0 |6086  8812 
 18   6  74   1   0|   0     0 | 872k   45k|   0     0 |6114  8808 
 17   6  73   1   0|   0     0 | 872k   43k|   0     0 |6088  8923 
 16   6  71   3   0|   0   160k| 799k   36k|   0     0 |5790  8879 
 17   7  72   2   0|   0  4097B| 857k   37k|   0     0 |5928  9079 
 18   6  72   2   0|   0     0 | 872k   43k|   0     0 |6237  9042 
 19   6  71   2   0|   0     0 | 234k  725k|   0     0 |5257  9144 
 18   6  72   2   0|   0     0 |  19k  991k|   0     0 |4632  8649 
 17   6  73   2   0|   0     0 |  20k  979k|   0     0 |4618  8607 
 17   6  73   2   0|   0     0 |  21k  986k|   0     0 |4539  8628 
 18   6  71   3   0|   0    12k|  21k  980k|   0     0 |4580  8440 
 16   6  74   2   0|   0     0 |  19k  984k|   0     0 |4605  8663 
 18   5  74   2   0|   0     0 |  23k  985k|   0     0 |4555  8589 
 17   6  74   2   0|   0     0 |  21k  977k|   0     0 |4552  8539 
 17   6  74   2   0|   0     0 |  19k  984k|   0     0 |4505  8515 
 17   7  73   2   0|   0     0 |  22k  986k|   0     0 |4639  8497 
 16   6  74   2   0|   0     0 |  24k  983k|   0     0 |4266  7642 
 17   5  74   2   0|   0     0 |  17k  986k|   0     0 |4183  7428 
 17   6  75   2   0|   0     0 |  16k  986k|   0     0 |4106  7359 
 15   5  74   2   0|   0     0 |  16k  994k|   0     0 |4296  7696 
 17   5  75   2   0|   0     0 |  16k  984k|   0     0 |4070  7295 
 22   6  69   2   0|   0     0 |6947B  309k|   0     0 |3674  6804 
 12   3  80   2   0|   0     0 |   0     0 |   0     0 |2376  4758 
 13   5  79   2   0|   0     0 |  60B   42B|   0     0 |2448  5640 
 16   5  76   2   0|   0     0 |3499B 6017B|   0     0 |2898  5357

　つうわけで、たった千円チョイの投資で、希望の通信環境と、多くの知見と、楽しい謎解きの時間を手に入れることができた。そういう時間って、実は狙って手に入れることが難しい。課題を見つけることが難しいし、対象が難しすぎれば解けないし、一度解いたら終わってしまうから。これまでに何度か書いているが、学生時代にセガマーク3用のトラックボールをジャンク扱いで購入し、試行錯誤(当時、電子工作の知識なし)でX68kにつなげたことがあったが、まさにああいう楽しさなんだよなぁ。

[ツッコミを入れる]