MACのシーケンス番号ごとの送信回数を導出。11回送信で10回再送という意味。再送制限回数を超過したことによって、ほぼ1秒間の間、送信失敗が続く。
そのときのRTOの値。200ms以上120秒以下と規定されている（はず）。大体220msくらい。
1秒以上の無通信区間があるはずなのにRTOで1秒以上の値が出てきていない。不思議。指数バックオフだから？
TCPのシーケンス図。30秒で60MB程度。途中でかなり転送してない。
RTO値を下限50ms上限100msに制限。ウィンドウサイズは60kB程度（43セグメント）で制限。
無通信区間はほとんど見えない。なんか2度目の攻撃がきてる。10秒あたりでしか妨害していないはずだが？
RTOは制限どおりに推移。
2度目の攻撃がなければ60MB以上出ていたはず。
無線LANで妨害実験をしてみた。
一般的に11gの世界では、1,6,11が周波数的に衝突しないといわれている。うちの研究室の無線LANアクセスポイントのチャンネルは5。よって1と6と干渉することになる。
そこで、1,6,11チャンネルを使ってiperfを行い解析をかけながら、途中10秒から5チャンネルを使って1秒間のみ妨害してみた。
結果
通信チャネル1、妨害チャネル5の場合）
通信チャネルではフレームが送信されるが、受信側で正しく受信できない。送信側は再送を行う。10回再送を行うが届かず。よってバースト誤りとなる。
通信チャネル6、妨害チャネル5の場合）
通信チャネルではフレームの送信を抑制。802.11はCSMA/CAアルゴリズムを採用しており、無線チャネルが使用中（idel）であると判断すると送信を抑制してバックオフを行う。スループットの低下は見られる。いわゆる「電子レンジの前で無線LAN使ってみた」。
通信チャネル11、妨害チャネル5の場合）
TCPスループットに影響は見られない。無線LAN再送回数が妨害時に微小に増大しており、妨害されたことは分かるが、作業上の影響は見られない。
WiFiの通信の安定性に疑問を持っている。
PCIスロット無線LANの無指向性外部アンテナによる室内の見通し可能な距離5mのアドホックモードによる通信において、無線LANの怪しさを感じた。
その怪しさとは、
である。
これは1秒ごとのスループット測定（netperf）を行いながらアンテナを移動させた体験が元になっている。
以上の結果を踏まえて、無線LANに外部アンテナが必要か否かという議論において、必要であるとしか言わざるを得ない。アンテナの位置しだいで室内見通し可能な通信範囲でさえ最大スループットが変動するからである。
しかしながら、ユーザは無線LANにおける最大スループットを気にするかどうか、思案すると気にしない方が多いのではないかと思われる。ノートPCのように可搬的なデバイスの場合はもっともそうだと思う。
反面、イーサネットコンバータのように移動性がなく、かつ、なんらかの事情で途中経路を無線LANにする必要があった場合だと、影響は謙虚だと思う。移動性がないデバイスの場合、スループットのパフォーマンスが影響する利用方法、例えばファイルサーバやネットゲームなどの用途が多いと思われるからだ。その場合、イーサネットコンバータを移動すればアンテナ問題は解決する。
ネットワークスループットが影響するデバイスの利用用途の場合、アンテナを移動することのできる（受信側）無線LANデバイスを購入した方がよい。単なるHTML目当てのWebアクセスの場合はそこまで考慮する必要はなく、ノートPC内臓のアンテナでも十分かと思われる。
問題は可搬性なアンテナをユーザが準備したとして、どうやって好ましい位置を特定するかである。電波状況は時間によって変化するので、常時ネットワークパフォーマンスを測定することが正確な値を取得できると思われるが、通常の用途に支障が出る。RSSIならパフォーマンスを失わずにうまくいくかもしれない。
Japan.internet.com Webビジネス – CSR の WiFi テクノロジー、Intempo のインターネットラジオに採用
こんな世界があるなんてしらなんだ…
CSRって会社のWebサイトを見ると、いい感じに壊れていて、これはよい会社。
asahi.com：新幹線に無線ＬＡＮ 総務省、周波数割り当てへ – ビジネス
高速さとトンネルが妨げになって安定した通信ができなかったんだけど、400MHz帯を無線LAN用に割り当てることで解決だって。09年春に導入予定だとか。
最近、「mpeg pts」で検索にひっかかりやすいので置いておく。
もう使い方を忘れていて、かつ、何をやっているのかも忘れて、かつ、バギーかもしれないプログラムを置いておく。たぶん、MPEG-2 TSからESにストリップしてMPEG-2ヘッダの解析をGOP_START_CODEとPICTURE_START_CODEまで（もしかしたらSLICE_START_CODEまで）やってくれるプログラムだったと思う。その途中でPTSを取得できたはずのプログラム。
昔、VLCで出力したTSを、このヘッダ解析プログラムに入れて損失を測定しようと思っていたけれど、結局、シーケンスが4bit（16までしかない）とかなんとかで解析をやめてしまった記憶がある。
中身が意味プーで置いてるだけで害があるかもしれないけど！
アプリケーションを変えると発症しなくなった。
スループットが良くなると発症しなくなった。
以上の結果から、アプリケーションがストリームのつなぎかえをやっている時に0.5s以下のロスが発生していると考えられる。
以上。
TCPにおいて送信バッファが溢れ、無線LANの帯域の余裕があるのにもかかわらず、TCPが送信してくれない状況に陥り、送信レートが落ちる現象が発生している。
TCPが送信しなくなる直前、送信バッファが溢れ、その兆候としてデータセグメントにPSHフラグが立てられたものが送信される。その後、どうやら受信側からACKが届かず、送信バッファがクリアされない。
受信側のTCPDUMPのログを見ると、TCPではデータセグメントを受信するとちゃんとACKを出している。データセグメント2回の受信ごとに1回出している。しかしながら送信側のログを見てみると、受信側で送信されたはずのACKが届いていない。連続で2回以上データセグメントが届いているように見える
とすれば、受信側TCPがACKを出すことには成功したが、その後無線LANあたりで消失したと予想される。無線LANで消失した理由を考えるとバッファ溢れが考えられるが、バッファ溢れが発生する要因はなく、実際に無線LANのログでもバッファ溢れが発生した様子はない。再送制限回数を超えた様子もない
いったい何なんだ？
実験のためのスクリプトを書く途中でroot権限が欲しいときがある。
その場合、script中にsudoを含めると何度も聞いてくるので面倒だったので、
# sudo ./script
と実行していた。
ただ、これをやると逆にユーザ権限で扱いたいファイルが扱えなくなってしまって困った。
そこで、/etc/sudoersにて、
noch (ALL) NOPASSWD: ALL
とパスワードを求めない設定に書き換えた。
内向きのネットワークのみで稼働させる実験システムなので、特に問題はないだろうと思っている。
ccid3のccid3hctx_x（Current sending rate in 64 * bytes per second）を表示させた例。点が多すぎて何がなんだかよく分からない。平滑化すれば分かりやすくなるだろうか。
