Monthly Archives: 1月 2008

ラジコンも2.4GHz

ラジコンプロポも2.4GHz帯活用、利用拡大で総務省の委員会が報告書案によると、「報告書案によれば、欧米では普及が進んでおり、米国では販売される製品の50〜70%が2.4GHz帯だという。変調方式は特に規定されておらず、周波数ホッピング(FH)や直接拡散(DS)など、データ通信でおなじみの方式が用いられているようだ。」とのこと。

2.4GHz帯を使っているとのことで無線LANとの混信が心配。ラジコン飛行機が操縦不能で追突が有り得る。ラジコンの場合、キャリアセンスは空いてるチャネルを探すためにやるらしい。空いてるチャネルがなくなったらどうなるんだろか。

保険と映像伝送の誤り訂正

NHKクローズアップ現代にて国民健康保険について考えながら、保険とは何だろうかと疑問になった。

思いついたのは「健康な人が小さい損をして、不健康な人が得をする制度」であるということ。これはすなわち、映像伝送においてパケット消失が発生した場合にどうするか、につながるのではないか。

wikipediaを見ると保険とは、確率論・統計学で確立されている大数の法則が成り立つから運営できるのだとしている。だとすれば、その環境におけるパケット消失確率を十分に集めることによって確率的に予測可能になり、誤り訂正できるのではなかろうか。

よくよく考えていると、FEC(前方向誤り訂正)がそれにあたる。逆に再送(ARQ)は事後に認知して回復を行おうとするので、予測できない誤りにも対応できる。

では現実の保険制度に対応するARQのような制度は何かと考えてみた。思いつかなかった。しいて言えば自助努力か?

無線LAN妨害〜1と5チャンネル

MACのシーケンス番号ごとの送信回数を導出。11回送信で10回再送という意味。再送制限回数を超過したことによって、ほぼ1秒間の間、送信失敗が続く。
tshark-tcp-080121-1903-iperf-channel_1-sndmac.png

そのときのRTOの値。200ms以上120秒以下と規定されている(はず)。大体220msくらい。
tcpprobe-080121-1903-iperf-channel_1txttcprto.png
1秒以上の無通信区間があるはずなのにRTOで1秒以上の値が出てきていない。不思議。指数バックオフだから?

TCPのシーケンス図。30秒で60MB程度。途中でかなり転送してない。
tshark-tcp-080121-1903-iperf-channel_1-sndtcp.png

ウィンドウサイズとRTOを制限

RTO値を下限50ms上限100msに制限。ウィンドウサイズは60kB程度(43セグメント)で制限。

無通信区間はほとんど見えない。なんか2度目の攻撃がきてる。10秒あたりでしか妨害していないはずだが?
tshark-tcp-080121-1906-iperf-channel_1-sndmac.png

RTOは制限どおりに推移。
tcpprobe-080121-1906-iperf-channel_1txttcprto.png

2度目の攻撃がなければ60MB以上出ていたはず。
tshark-tcp-080121-1906-iperf-channel_1-sndtcp.png

無線LANの敵は無線LAN

無線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再送回数が妨害時に微小に増大しており、妨害されたことは分かるが、作業上の影響は見られない。

無線LANに外部アンテナは必要か

WiFiの通信の安定性に疑問を持っている。

PCIスロット無線LANの無指向性外部アンテナによる室内の見通し可能な距離5mのアドホックモードによる通信において、無線LANの怪しさを感じた。

その怪しさとは、

  • 1cm動かしただけでスループットが5Mbps程度変動すること
  • 5cm動かしただけでスループットが最大で20Mbps程度変動すること

である。
これは1秒ごとのスループット測定(netperf)を行いながらアンテナを移動させた体験が元になっている。

以上の結果を踏まえて、無線LANに外部アンテナが必要か否かという議論において、必要であるとしか言わざるを得ない。アンテナの位置しだいで室内見通し可能な通信範囲でさえ最大スループットが変動するからである。

しかしながら、ユーザは無線LANにおける最大スループットを気にするかどうか、思案すると気にしない方が多いのではないかと思われる。ノートPCのように可搬的なデバイスの場合はもっともそうだと思う。

反面、イーサネットコンバータのように移動性がなく、かつ、なんらかの事情で途中経路を無線LANにする必要があった場合だと、影響は謙虚だと思う。移動性がないデバイスの場合、スループットのパフォーマンスが影響する利用方法、例えばファイルサーバやネットゲームなどの用途が多いと思われるからだ。その場合、イーサネットコンバータを移動すればアンテナ問題は解決する。

ネットワークスループットが影響するデバイスの利用用途の場合、アンテナを移動することのできる(受信側)無線LANデバイスを購入した方がよい。単なるHTML目当てのWebアクセスの場合はそこまで考慮する必要はなく、ノートPC内臓のアンテナでも十分かと思われる。

問題は可搬性なアンテナをユーザが準備したとして、どうやって好ましい位置を特定するかである。電波状況は時間によって変化するので、常時ネットワークパフォーマンスを測定することが正確な値を取得できると思われるが、通常の用途に支障が出る。RSSIならパフォーマンスを失わずにうまくいくかもしれない。

インターネットWiFiラジオ

Japan.internet.com Webビジネス – CSR の WiFi テクノロジー、Intempo のインターネットラジオに採用

こんな世界があるなんてしらなんだ…

CSRって会社のWebサイトを見ると、いい感じに壊れていて、これはよい会社。

新幹線にも無線LAN

asahi.com:新幹線に無線LAN 総務省、周波数割り当てへ – ビジネス

高速さとトンネルが妨げになって安定した通信ができなかったんだけど、400MHz帯を無線LAN用に割り当てることで解決だって。09年春に導入予定だとか。

MPEG-2ヘッダ解析プログラム

最近、「mpeg pts」で検索にひっかかりやすいので置いておく。

mpeg-header-analysistar.gz

もう使い方を忘れていて、かつ、何をやっているのかも忘れて、かつ、バギーかもしれないプログラムを置いておく。たぶん、MPEG-2 TSからESにストリップしてMPEG-2ヘッダの解析をGOP_START_CODEとPICTURE_START_CODEまで(もしかしたらSLICE_START_CODEまで)やってくれるプログラムだったと思う。その途中でPTSを取得できたはずのプログラム。

昔、VLCで出力したTSを、このヘッダ解析プログラムに入れて損失を測定しようと思っていたけれど、結局、シーケンスが4bit(16までしかない)とかなんとかで解析をやめてしまった記憶がある。

中身が意味プーで置いてるだけで害があるかもしれないけど!

消えたACKの解

アプリケーションを変えると発症しなくなった。

スループットが良くなると発症しなくなった。

以上の結果から、アプリケーションがストリームのつなぎかえをやっている時に0.5s以下のロスが発生していると考えられる。

以上。

消えたACK

TCPにおいて送信バッファが溢れ、無線LANの帯域の余裕があるのにもかかわらず、TCPが送信してくれない状況に陥り、送信レートが落ちる現象が発生している。

TCPが送信しなくなる直前、送信バッファが溢れ、その兆候としてデータセグメントにPSHフラグが立てられたものが送信される。その後、どうやら受信側からACKが届かず、送信バッファがクリアされない。

受信側のTCPDUMPのログを見ると、TCPではデータセグメントを受信するとちゃんとACKを出している。データセグメント2回の受信ごとに1回出している。しかしながら送信側のログを見てみると、受信側で送信されたはずのACKが届いていない。連続で2回以上データセグメントが届いているように見える

とすれば、受信側TCPがACKを出すことには成功したが、その後無線LANあたりで消失したと予想される。無線LANで消失した理由を考えるとバッファ溢れが考えられるが、バッファ溢れが発生する要因はなく、実際に無線LANのログでもバッファ溢れが発生した様子はない。再送制限回数を超えた様子もない

いったい何なんだ?