電車で見かける迷惑行為ですか…

ブログネタ：

電車で見かける迷惑行為は？ に参加中！

まぁ、音漏れとかいくつかありますが、
二大トピックはこれでしょう。

1) 怪獣女装お釜
  えぇ、もうお前はどうしてそれだけエラが張っていて、スカートの前ガンガンに立ててるくせに女装をするっ?!!!!! という怪獣。あれがそばに来るかと思うだけでちょっと気が遠くなりますな。


2) 痴女
  いるんですよ。人の股間触ってくる女が。
  これは感動しましたね。「本当に、存在するんだーーー」って。

いや、オチはありませんよ？

『オススメ、期待のゲームを教えてください』というピックアップテーマに反応して見る

ブログネタ：

オススメ、期待のゲームを教えてください に参加中！

FF12でしょう。
もうこの一言に尽きます。

FF12の主人公は複数いますが、なかでもロシア人っぽいオネーチャンが出てくるんですよね。で、これにかなりそっくりな人が会社にいるってのがその最大の理由。

…

まずもって「リアルな人間に似ている主人公が出てくる」段階でCGどこまで進化したーー!??!! という気がしますが。

それが3D-FF固有の、あの 無茶で物理法則無視な攻撃 をするわけです。

思わず、そのそっくりな人が会社ででたらめな客の相手をさせられた直後に、応接室とかをボロボロに粉砕しているシーンを想像して…

…

ストーリーとかは、期待はしていますが想像はしていません。妄想を膨らませたバージョンよりはしょぼくなる事、確定ですから。きっとサイドゲームや通信を使った追加オプション等あって、コンプリートさせようとするとえらい事になるんでしょうなぁ。そんな暇あるかなぁ(遠い眼…)。

ま、楽しみです。

魔法騎士レイアースを誰も出してないな…

ブログネタ：

これだけは絶対見て欲しいオススメのアニメ に参加中！

というわけで、2本。

1つ目はタイトルどおり、「魔法騎士(マジックナイト)レイアース」。
CLAMP が同名の漫画を「なかよし」に連載、最後のオチが難しすぎて幼稚園児たちをパニックに陥れたことで有名な作品です。小学3年生以上の女の子にお勧めですね。

2つ目は「銀河英雄伝説」。
徳間書店懇親の力作で、田中芳樹による同タイトル小説の(世にも珍しい)

完全ノーカット・無変節

なアニメ化です。大抵の原作ものはどこかでおかしな設定を割り込ませて、途中でぶった切られるのに、これには一切ありません。このアニメから、原作小説に入り、そのまま図書館の虫と化した人間を大量に作り上げました。今のラノベ人口を増大させる遠因を作った一作とも言われています。
こちらは中学生以上の男女にお勧め。

誰も出していないようでしたので書いて見ました。いかがでしょう?!

ネットワークが不調なときに調べる順番

先日、技術的にはひと段落ついた仕事がある。あるお客様環境でネットワーク不調のために TCP再送が頻発し、たまにTCPsessionとしても切れてしまう、と言う問題。
本来、ストレージ屋である弊社は「ネットワーク不調」とわかった段階で手を引くのが正しいあり方なのだが…それはともかく。
非常に紆余曲折があって解決までに時間がかかっていたので、私がデバる必要があったのだが、本質的にやるべきこと・やれる事は簡単。それをここに書いておこう。

1. まず、契約書などを調べる。
   ネットワークが全て自分の中で閉じているならばともかく、そうではない場合が殆どだろう。であれば、その部分に関して契約書などを調べる。大抵の場合、通信許容上限などが書いてある。と言う事は、それ以上の通信量をかけるとその分はパケットが落ちてしまう。そういう値を調べる。
   また、MTUの値をEthernetのデフォルトである 1500 よりも小さくしなくてはいけない、などという場合もある。IPv6だと ICMP でエラーを返す事が義務付けられているが、IPv4 の場合パケットを落とした後放置プレイしても構わなかったりする。なので、その辺も確認する。
2. 設定を調べる。
   調べるポイントはエラーを起こしているエンドノードマシンから順番に、通信線で繋がっている「ペア」の設定を順番に追いかけていく。
   例えば、ノートPCとハブの間。ノートPCが100Mbpsのランプの光り方をしているのに、ハブが10Mbpsだと主張していないか、など。これは大抵、オートネゴシエーションを両側でonにしていない(あるいは両側で off にしていない)場合などに起こる。要するにそれらの整合性を全部追いかけていく。片方の端から、もう一方の端へ。あるいは両端から徐々に内側に向かって。
   また、契約書などに書いてある値との整合性も調べる。MTUとか。
   
3. 統計情報を調べる (1)
   今回もそうだったが、1,2 の段階では問題は見つからなかった。とするならば、統計情報を取って、どの時間帯にどういう症状が「末端同士」で見られ、そのときに中間の「スイッチ類」では見られるのか、を追いかけるしかない。
   流量・パケット drop 量などを全部追いかけること。
   注意点が一つ。TCP再送などは、パケット全体の 0.1% - 1.0% 程度起こるだけで大幅な性能ダウンを見せる。1時間に1度計測するとしても3600秒の 1% は 36秒、0.1% は 3.6秒だ。一見パケットがあるときガクッと失われているように見えても、それは時間差による誤差かもしれない。この辺をきちんと調べるためにも、スイッチ・端末等は全て NTP で時刻を合わせておく必要がある。また、計測のたびに時刻を表示させて記録を取っておく事、記録の取得は全て自動化すること(そうする事で計測誤差が小さくなる)などがあげられる
4. 統計情報を調べる (2)
   どうしようもなくなったら、いよいよスイッチ間の流量差分を調べる、などが必要になる。
   この場合重要なポイントが2つある。
   1つは「全部調べる」。つまり「このポートとこのポートの間だけが問題なはずだ」的にそこの情報しか調べない、と言うのは駄目だ、と言う事。情報を取得しておいて、後で状態を調べる際に捨てていくのは簡単だが、取得していない情報を後になって「取得しておけばよかった」と後悔しても情報は増えない。
   もう一つも「全部調べる」だが「全ての種類のパケットを調べる」。これは、L3SWなどの場合Ethernet Frame 数でカウントしているカウンターもあれば、IPパケットの数を調べているカウンターもあるので、それらを全部引っ張り出しておく、と言う事。
   「こちら側はIPパケットを数えています」「あちら側は Ethernet Frame を数えています」では数を対応させる事はできない。その一方で、「必要だったのは Ethernet Frame 数ではなく、IP packet 数でした」と後になって判っても…。

この順序を必ず守る事で必ず答に行き着ける。逆にこの順序を守らないと、どこかが故障しているのか、設定不良なだけなのか、見つけるのは至難の業になってしまう。