Monthly Archives: 6月 2007 - Page 2

DCCPの検証 (8)

前回のkernel BUGについての情報が入った。

kernel BUG at kernel/timer.c:407!によると、linux-2.6.20 and linux-2.6.21-pre1で発生しうるようだ。日付は2007 Mar 5。かなり近い。

2.6.20で対処するのが面倒なので、2.6.21のroot file systemの方を対処。

The day-to-day thoughts – vmwareと2.6.21によると2.6.21に加えられた変更とvmware上でのSCSIエミュレーションで相性が悪いらしい。確かにbuslogicに代えると上手くいった。

ということなら実機なら上手くいくはず。

意を決してリモートホストに2.6.21を入れた。

…動いた。

DCCPの検証 (7)

そう、アレはttcpの検証が出来たところでVLCの検証を行おうとしたときだ。

以下のメッセージが表示されて何も出来ない。

[code]
————[ cut here ]————
kernel BUG at kernel/timer.c:407!
invalid opcode: 0000 [#6]
SMP
Modules linked in: wlan_scan_sta ath_rate_sample ath_pci wlan ath_hal(P) dccp_ccid3 dccp_tfrc_lib dccp_ccid2 dccp_ipv4 dccp binfmt_misc nfs ipv6 nfsd exportfs lockd nfs_acl sunrpc dm_snapshot dm_mirror dm_mod ide_generic ide_disk i810_audio ac97_codec snd_intel8x0 i2c_i801 psmouse snd_ac97_codec i2c_core rtl8150 rtc tsdev ac97_bus snd_pcm snd_timer snd soundcore parport_pc parport iTCO_wdt serio_raw snd_page_alloc evdev pcspkr ext3 jbd mbcache ide_cd cdrom sd_mod ata_piix usbhid hid ata_generic ahci uhci_hcd ehci_hcd libata scsi_mod piix generic ide_core usbcore tg3 thermal processor fan
CPU: 0
EIP: 0060:[] Tainted: P VLI
EFLAGS: 00210246 (2.6.20-1-686 #1)
EIP is at mod_timer+0x6/0x1f
eax: f50f77e0 ebx: f50f7480 ecx: 00102c3b edx: 00102c3b
esi: dfced180 edi: 000003e7 ebp: f50f5f40 esp: f50f5d44
ds: 007b es: 007b ss: 0068
Process lt-vlc (pid: 4581, ti=f50f4000 task=dff88030 task.ti=f50f4000)
Stack: c0235ce7 f50f7480 f8bfdf7b 00200282 00000000 7fffffff c0299764 f50f7480
00000000 c01c37f8 f50f5f48 00000524 00000524 00200246 dfced180 f50f7480
e4de148c f50f5f40 f8bff8fd f50f5d98 7fffffff 00000000 f8b9c000 f50f7480
Call Trace:
[] sk_reset_timer+0xc/0x16
[] dccp_write_xmit+0x56/0x29e [dccp]
[] _spin_lock_bh+0x8/0x18
[] __next_cpu+0x12/0x21
[] dccp_sendmsg+0x12a/0x150 [dccp]
[] inet_sendmsg+0x3b/0x45
[] sock_sendmsg+0xd0/0xeb
[] autoremove_wake_function+0x0/0x35
[] __next_cpu+0x12/0x21
[] find_busiest_group+0x1b4/0x4c5
[] sys_sendto+0x116/0x140
[] __sched_text_start+0x804/0x8c9
[] read_tsc+0x6/0x7
[] getnstimeofday+0x30/0xb6
[] lock_hrtimer_base+0x19/0x35
[] hrtimer_try_to_cancel+0x3c/0x42
[] sys_send+0x37/0x3b
[] sys_socketcall+0x12d/0x242
[] syscall_call+0x7/0xb
=======================
[/code]

ふっざけんじゃねー

DCCPの検証 (6)

2.6.20で実験を行っている。当初は2.6.21のカーネルを入れて起動しようとしたのだが、root file systemが見つからないということで起動できなかった。

リモートホストの実機のカーネルを入れ代える前に、VMwareで実験するようにしているで、それが原因なのかもしれない。2.6.20はVmwareで単純に入れて成功したので、それを利用している。カーネルはbackportから入れている。

2.6.21と2.6.20のDCCPにどの程度の差分があるのか分からないので、そちらも検証する必要がある。

DCCPの検証 (5)

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

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

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

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の検証 (4)

オーケー、オーケー、

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もあるんだよ…

胃に穴が空きそうだ…

DCCPの検証 (3)

[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は最近の仕様なのでバグも多いことが予想される…それは、もっと新しいカーネルをコンパイルしろと、そういうことか。

めーんどくせー

DCCPの検証 (2)

少なくとも無線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)では3Mbpsしか出ない。

何処の設定だ?

DCCPの検証

ぶろゲ 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の仕組みを把握していないためにいまいち何処の設定を変更すればいいのか分からない。

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

【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が流行らない限りは。

5hopの実験

以前、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の場合、損失が出るかと思ったが、ブロックノイズらしきものは現れなかった。端末がすべて手元にある状態ということから当然の結果か。