ブロげ

休日はたくさん研究が出来る日…

平日はたくさん研究が出来ない日…

あれ…これは…ゆとり…？

2.6.20ではDCCP、期待通りに動作する印象。以下は、無線LANアドホック54Mbpsの1対1環境においてttcpを行った結果。TCPとDCCP。DCCPはCCID2。

TCP送信側

$ ./ttcp -t 192.168.2.11
ttcp-t: buflen=8192, nbuf=2048, align=16384/+0, port=5001 tcp(inet) -> 192.168.2.11
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 5.21 real seconds = 3144.96 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 2.60, calls/sec = 393.12
ttcp-t: 0.0user 0.0sys 0:05real 0% 0i+0d 0maxrss 0+4pf 235+0csw

TCP受信側

$ ./ttcp -r
ttcp-r: buflen=8192, nbuf=2048, align=16384/+0, port=5001 tcp(inet)
ttcp-r: socket
ttcp-r: accept from 192.168.2.12
ttcp-r: 16777216 bytes in 5.26 real seconds = 3114.58 KB/sec +++
ttcp-r: 11114 I/O calls, msec/call = 0.48, calls/sec = 2112.76
ttcp-r: 0.0user 0.0sys 0:05real 1% 0i+0d 0maxrss 0+2pf 11584+0csw

TCP時

$ athstats | grep queue
146 tx frames discarded due to queue depth
$ athstats | grep queue
207 tx frames discarded due to queue depth

DCCP送信側

$ ./ttcp -c -l1424 -t 192.168.2.11
ttcp-t: buflen=1424, nbuf=2048, align=16384/+0, port=5001 dccp(inet) -> 192.168.2.11
ttcp-t: socket
ttcp-t: connect
ttcp-t: 2916352 bytes in 1.02 real seconds = 2780.63 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 0.51, calls/sec = 1999.56
ttcp-t: 0.0user 0.0sys 0:01real 8% 0i+0d 0maxrss 0+3pf 339+0csw

DCCP受信側

$ ./ttcp -r -c
ttcp-r: buflen=8192, nbuf=2048, align=16384/+0, port=5001 dccp(inet)
ttcp-r: socket
ttcp-r: accept from 192.168.2.12
ttcp-r: 2916352 bytes in 1.04 real seconds = 2730.85 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 0.52, calls/sec = 1964.72
ttcp-r: 0.0user 0.0sys 0:01real 0% 0i+0d 0maxrss 0+1pf 2524+0csw

DCCP時

$ athstats | grep queue
207 tx frames discarded due to queue depth
$ athstats | grep queue
207 tx frames discarded due to queue depth

TCPでは25Mbps、DCCPでは22Mbps。
TCPでは61フレームがdiscard。それに対してDCCPではフレームが落ちていない。

DCCPはCCID2で実験を行ったが、CCID3はttcpが終わらない。以下のコマンドでdccpだけ抽出してキャプチャしてトラヒックの動きを見る。

$ sudo tshark -i ath0 -R dcp

CCID3では最初の景気はいいのだが、途中から1秒に1回程度しか出さなくなる。

オーケー、オーケー、

DCCPって奴はどちらかっていうとUDPじゃなくTCPに近い…そう…再送がないTCPのような存在だ。俺が2.6.18の時分のときはそう思ってた。

$ ls /proc/sys/net/dccp/default/
ack_ratio rx_ccid send_ackvec send_ndp seq_window tx_ccid

だが、2.6.20に代えたとたんにどういうことなんだ？これは？

$ ls /proc/sys/net/dccp/default/
ack_ratio retries1 rx_ccid send_ndp tx_ccid
request_retries retries2 send_ackvec seq_window tx_qlen

ああ、もう、頭が痛い…request_retriesって何だよ…なんでretriesが1と2もあるんだよ…

胃に穴が空きそうだ…

[BUG] DCCP : Suspected race in ackvec codeみたいなメーリングリストの記事を見つけて考え込む。

When send_ackvec sysctl is on DCCP locks the machine. Unfortunately it
doesn’t send any output to the kernel.

日付が28 Feb 2006だったのだが、現在使っているカーネルは2.6.18で2006のOctにリリースされたもの。大丈夫か。

このメールの著者は、現在のCCID関係の実装を行っているIan McDonald氏。氏のサイトDCCPを見ると、

Download 2.6.20 and if using CCID3 in particular use my set of working patches below on top (use stgit to help you manage them).
…

と、2.6.20を示唆する内容。

そこで、現在使っている2.6.18のDCCPのCCIDコードと最新の2.6.21とを見比べると、”そこそこ”違う。当然のことながらDCCPは最近の仕様なのでバグも多いことが予想される…それは、もっと新しいカーネルをコンパイルしろと、そういうことか。

めーんどくせー

少なくとも無線LAN上ではqueueが足らんでdiscardされている予感。

[code]
$ athstats | grep queue
42591 tx frames discarded due to queue depth
[/code]
ttcpで以下のコマンドによるDCCPを測定する。
[code]
# ./ttcp -n2000 -c -r
# ./ttcp -c -l1424 -t 192.168.2.10
[/code]
すると、
[code]
$ athstats | grep queue
42900 tx frames discarded due to queue depth
[/code]
42900-42591=409コのフレームが新たにdiscardされたことになる。その後、ttcpは終わらず、tcpdumpでトラヒックを見ても時々しかDCCPのDataフレームを出さないくらい抑制？されているみたいな。

有線の場合は、UDPでは88Mbps程度のスループットが見られるのに対して、DCCP(CCID3)では３Mbpsしか出ない。

何処の設定だ？

ぶろゲ DCCP編にてDCCPを使う実装を触っていたのだが、その実装が期待通りに動かない。

その現象とは、DCCPでローカルループバックでは期待する動作をするのだが、別PC間で接続を行うときちんと動作しない。この差は、おそらく、パケットの消失があるか、ないかの違いだと思われる。

CCID2はデフォルトの状態で、CCID3は以下の設定を行い、実験を行った。（参考：DCCP – LinuxNet）
[code]
echo 3 > /proc/sys/net/dccp/default/rx_ccid
echo 3 > /proc/sys/net/dccp/default/tx_ccid
echo 10000 > /proc/sys/net/dccp/default/seq_window
echo 0 > /proc/sys/net/dccp/default/send_ackvec
[/code]

ttcpというDCCP検証に使えそうなスループット測定プログラムを走らせても期待通りにはならない（本プログラムではUDPも期待通りに動作しないため、損失を考慮しないと思われる）。

今回はDCCPによって、インターフェースで発生するだろうバッファ溢れを解消したい希望があり採用したのだが、それ以上に消失に対してセンシティブである印象を受ける。これはDCCPのカスタマイズ次第でどうにかなるだろうと現状では判断しているが、DCCPの仕組みを把握していないためにいまいち何処の設定を変更すればいいのか分からない。

【COMPUTEX】1万円以下の802.11nドラフト2.0対応無線LAN APが登場：ITpro

　このGN-BR30N-RHのように安価な802.11n対応無線LAN APへの搭載が進んでいるのが台湾のRalink Technology製チップである。すでに昨年から搭載製品が登場しており，「ローコストのため採用が進んでいる」（無線LAN機器のOEM提供を手がける台湾Gemtek Technologyの担当者）という。

Ralinkの802.11nはノーマークでした。メーカー間の相互接続性が保ててるのかしら。いや、ドラフト時点じゃそんなもんは気休めで、同じメーカ同士の製品で接続性が保てれば、どーでもいいや。2.4GHz帯にしか対応してないみたいだけど、2.4GHz帯でも使えるっちゃ使えるんで、安ければオーケーデス。

似たり寄ったりの無線LAN APじゃ、差別化は新機能か安価。新機能ったってWiiに対応すりゃいいんでしょ的な感じ。この前のSSIDを仮想的に分けてWEPとWPAを共存させるのには感動したけれど、この先は特にやることないんじゃないでしょーか。プロジェクタをワイヤレスにしたり、家庭内VoIPが流行らない限りは。

以前、aodvdおよびolsrdを入れて実験してうまくルーティングされなくて失敗した。

発端と終端がノートPC。途中ノードがdd-wrtを入れたイーサネットコンバータ。

aodvが動作させて実験できるほど我が家は広くないので、とりあえずstaticなルーティングを手で書き込んで実験。

[code]
noch@x31:~$ traceroute 192.168.100.101
traceroute to 192.168.100.101 (192.168.100.101), 30 hops max, 40 byte packets
1 192.168.100.216 (192.168.100.216) 1.432 ms 0.946 ms 0.789 ms
2 192.168.100.217 (192.168.100.217) 2.742 ms 2.370 ms 1.919 ms
3 192.168.100.218 (192.168.100.218) 3.887 ms 3.051 ms 3.078 ms
4 192.168.100.219 (192.168.100.219) 4.718 ms 4.359 ms 4.257 ms
5 192.168.100.101 (192.168.100.101) 10.110 ms 56.712 ms 4.992 ms
noch@x31:~$ ping -R 192.168.100.101
PING 192.168.100.101 (192.168.100.101) 56(124) bytes of data.
64 bytes from 192.168.100.101: icmp_seq=1 ttl=60 time=5.91 ms
RR: 192.168.100.100
192.168.100.216
192.168.100.217
192.168.100.218
192.168.100.219
192.168.100.101
192.168.100.101
192.168.100.219
192.168.100.218

64 bytes from 192.168.100.101: icmp_seq=2 ttl=60 time=24.9 ms (same route)
64 bytes from 192.168.100.101: icmp_seq=3 ttl=60 time=48.9 ms (same route)
64 bytes from 192.168.100.101: icmp_seq=4 ttl=60 time=72.7 ms (same route)
64 bytes from 192.168.100.101: icmp_seq=5 ttl=60 time=5.85 ms (same route)
64 bytes from 192.168.100.101: icmp_seq=6 ttl=60 time=17.4 ms (same route)
64 bytes from 192.168.100.101: icmp_seq=7 ttl=60 time=41.2 ms (same route)

— 192.168.100.101 ping statistics —
7 packets transmitted, 7 received, 0% packet loss, time 6000ms
rtt min/avg/max/mdev = 5.851/31.031/72.776/22.846 ms
[/code]
この状況でnetperfをすると…
[code]
noch@x31:~$ netperf -H 192.168.100.101
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.101 (192.168.100.101) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 10.23 3.80
[/code]
当初、netperfして5.4Mbpsが表示されてかなり帯域が出ると思ったら、戻り道のルーティングを設定していないことに気がついた。んで、戻り道の設定をした結果が上記。改めて、双方向通信の難しさを実感。

それでも3.8Mbps出てるので、映像転送。Webカメラのドライバを入れて控えめに400kbps程度のmp4v、http、tsで送信したが、問題なくクライアント側で見ることができた。ただし、表示されるまでかなり遅い。

pingの結果を見ても、50ms以上の遅延があるなど、このままではVoice over IP(VoIP)はうまくできなそうな予感。

以上の結果から、staticなルーティングを書き込めば、5hopでも3.8Mbps出ることがわかった。現状では6端末がすべて手元にある状態なので、ある端末が出した電波が全ての端末に届く状況。これが実環境だと距離で減衰したり、隠れ端末などの問題を引き起こしたりしてスループットが低下すると考えられる。

次は広い場所に持っていってaodvdやolsrdの動作確認およびカスタマイズが必要か。

追記：

映像はUDPで伝送しても大丈夫だった。UDPの場合、損失が出るかと思ったが、ブロックノイズらしきものは現れなかった。端末がすべて手元にある状態ということから当然の結果か。

モトローラ、802.11n標準完成まで対応製品販売せず – CNET Japan

偉くて偉くて涙が出てくる。

　同社のシニア製品マーケティングマネージャーであるAngelo Lamme氏は、ロンドンで開催されたWireless EventにおいてZDNet UKに対し、Motorolaは、規格の正式版に準拠しないかもしれない機器を顧客に購入してもらいたくはないと述べた。802.11n規格は、 Institute of Electrical and Electronics Engineers（IEEE）が2009年の標準化を目指している。

正式版が出るまで製品を出さないという方針はその通りで、ドラフト2.0が出たらしいが、詳しい人に話を聞くとドラフト2.0でも正式版に対応できない可能性がある、とのこと。NECが11n ドラフト2.0無線LANルータを出したりしてますが。

ちなみにこのNEC製品、NDSがWEPにしか対応しない問題に関して、Multi SSIDによる解決策を出している。ただしVLANに対応してないので現状ではつまらない。もちろんWPSに対応。５月からのチャンネルボンディングに対応。

そんな製品が将来、標準に対応しないかもしれない、という問題はどれだけ認知されているだろうか。どちらかというと、11nが標準対応しないことで不利益をこうむる人、団体がそれほど多いのかという話がある。正式対応まで製品が出せないと、どうしても設計で差がついてしまう。

それを分かった上でモトローラはそういってるのだから、顧客や無線LANの業界を大事に思っているんだなー、と。

前回から2ページ半くらい訳した。

070527_80211etoj.pdf

そういえば学部時代に英語の授業で不可をとって再履修になったことがある。

そんな僕が訳をする、というのも変な話だ。大学の講義の英語が出来なくても翻訳は出来るんだな、と。その基礎になっているのは、高校時代の英語、とくに文法だ。後はこういう技術書を読むためのバックグランドがあるかどうか。

802.11eを翻訳しなければならない用事が出来たので翻訳中。

802.11e(070520時点)
今日はここまで。

Latexで執筆していたのだが、途中で表のセル内で改行する方法が分からなかった。

\begin{tabular}{|c|l|p{10pt}|}

と、セルをp{セル長}で定義して、改行したい場所で\parを挿入すればセル内で改行できることが分かった。