ネットワーク転送レートを計測するときによく使われるiperf。
今回「ネットワークが片方向だけしか繋がらない環境」で、iperfを使う場合について調べました。
普通は双方向のイーサネットで接続されているので「片方向だけでしか繋がらない環境」はあり得ないのですが、無線の開発現場ではあり得ます。ダウンリンクだけ実装するとかそういうことですね。
使用したソフトウェア
iperfは測定開始前にクライアント(送信側)からサーバ(受信側)にTCPで接続を行い、測定の開始・終了などを通知し、測定終了後結果をクライアントに返しています。
なので、片方向通信環境の場合、iperfは使えません。
ですが、iperf3とiperf2では挙動が異なります。
iperf3の場合、サーバに接続できない時点でクライアントがエラーを表示して終了してしまいます(-u オプションのUDPモードでも)。
ですが、iperf2はサーバからAckが返ってこないというメッセージは表示するもののUDP送信は開始します。
というわけで片方向の場合は、iperf2を使用します。
あと、-b 100Mとして転送帯域幅を指定するとその帯域幅で送信されます。
タスクマネージャで見ている限り98.5Mbps程度で送信されていますが、あくまでも「98.5Mbpsで送り出しただけ」で、実際にこのレートで届いているとは限りません。UDPですしね。
物理層を実装している場合、物理層のフレームサイズに合わせて上側のパケットサイズを同じ長さに合わせて送った方が都合が良いとかそういうことがありますので、調べました。
iperfをコマンドラインで-lオプションを付けると送信バイト数を指定できます。-l 100なら1回で100バイト送信します。
で、試してみたところ、最小は16バイトのようです。
で、最長はUDPのペイロード長の最大値 65507バイトです。
わざと"65508"を指定したところ、エラーは出ませんでしたが送信できていませんでした。
UDP送受信テストに大活躍のUdpIpTool.exeで受信して見てみると、16バイト受信しています。
やはり最小サイズは16バイトですね。
念のため -l オプションのバイト数を変えながらいくつかデータを受信してみました。
以下は、UdpIpToolで受信したのログですが、見やすいように10バイト毎に改行を入れています。
-lで指定したバイト数(最小16バイト)のデータがUDPペイロードに入って送られてきているようです。
->受 192.168.10.80 (60807)
<00><00><32><15><5d><8a><f9><9e><00><0b>
<83><7a><00><00><00><00><08><00><00><00>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><00><34><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
->受 192.168.10.80 (56571)
<00><00><fa><89><5d><8a><f7><a9><00><0a>
<a4><4e><00><00><00><00><08><00><00><00>
->受 192.168.10.80 (61682)
<00><01><39><c0><5d><8a><f7><7b><00><0b>
<df><e4><00><00><00><00>
->受 192.168.10.80 (52166)
<00><01><39><af><5d><8a><f7><32><00><07>
<9a><3f><00><00><00><00>
次回はiperfが送信しているパケットフォーマットをwiresharkで解析してみます。
私たちドルフィンシステムは、お客様の様々な要望に答えられるように色々と実験をしています。最適な無線システムを提案していけるよう努力しております。
SDRを用いた無線システムのご要望はドルフィンシステムへ。
今回「ネットワークが片方向だけしか繋がらない環境」で、iperfを使う場合について調べました。
普通は双方向のイーサネットで接続されているので「片方向だけでしか繋がらない環境」はあり得ないのですが、無線の開発現場ではあり得ます。ダウンリンクだけ実装するとかそういうことですね。
使用したソフトウェア
Wireshark
|
v2.6.1-0-g860a78b3
|
iperf2
|
2.0.14a-win
|
片方向だけで使う場合はiperf3ではなくiperf2
iperfはUDPを使ってレート測定をするモードがありますが、実はTCP接続も使用するのです。iperfは測定開始前にクライアント(送信側)からサーバ(受信側)にTCPで接続を行い、測定の開始・終了などを通知し、測定終了後結果をクライアントに返しています。
なので、片方向通信環境の場合、iperfは使えません。
ですが、iperf3とiperf2では挙動が異なります。
iperf3の場合、サーバに接続できない時点でクライアントがエラーを表示して終了してしまいます(-u オプションのUDPモードでも)。
ですが、iperf2はサーバからAckが返ってこないというメッセージは表示するもののUDP送信は開始します。
C:\Users\Mikio Fukushima\Desktop\iperf-2.0.14a-win64>iperf -u -c 192.168.10.80
------------------------------------------------------------
Client
connecting to 192.168.10.80, UDP port 5001
Sending
1470 byte datagrams, IPG target: 11215.21 us (kalman adjust)
UDP
buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.22 port 50300 connected
with 192.168.10.80 port 5001
[
ID] Interval Transfer Bandwidth
[ 3]
0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 892 datagrams
[ 3] WARNING: did not receive ack of last
datagram after 10 tries.
C:\Users\Mikio
Fukushima\Desktop\iperf-2.0.14a-win64>
あと、-b 100Mとして転送帯域幅を指定するとその帯域幅で送信されます。
タスクマネージャで見ている限り98.5Mbps程度で送信されていますが、あくまでも「98.5Mbpsで送り出しただけ」で、実際にこのレートで届いているとは限りません。UDPですしね。
iperfの送信長を調べる
次にiperfの最小送信データ長を調べました。物理層を実装している場合、物理層のフレームサイズに合わせて上側のパケットサイズを同じ長さに合わせて送った方が都合が良いとかそういうことがありますので、調べました。
iperfをコマンドラインで-lオプションを付けると送信バイト数を指定できます。-l 100なら1回で100バイト送信します。
で、試してみたところ、最小は16バイトのようです。
で、最長はUDPのペイロード長の最大値 65507バイトです。
わざと"65508"を指定したところ、エラーは出ませんでしたが送信できていませんでした。
送信データ数1バイト(option "-l 1")で送信してみる
"Sending 16 byte datagrams"と表示されていますので、1バイトを指定しても16バイトを送っているようです。
R:\work>iperf-2.0.14a-win.exe
-u -p 40001 -c 192.168.10.80 -l 1
WARNING:
Client UDP buffer size (-l value) increased to 16 bytes for proper operation
------------------------------------------------------------
Client
connecting to 192.168.10.80, UDP port 40001
Sending
16 byte datagrams, IPG target: 122.07 us (kalman adjust)
UDP
buffer size: 64.0 KByte (default)
------------------------------------------------------------
[344]
local 192.168.10.80 port 52166 connected with 192.168.10.80 port 40001
[344]
WARNING: did not receive ack of last datagram after 10 tries.
[
ID] Interval Transfer Bandwidth
[344] 0.0-10.0 sec
1.25 MBytes 1.05 Mbits/sec
[344]
Sent 81921 datagrams
R:\work>
UDP送受信テストに大活躍のUdpIpTool.exeで受信して見てみると、16バイト受信しています。
やはり最小サイズは16バイトですね。
パケット長比較
上記の試験で「iperf2は -lオプションで指定したバイト数を送る。最小は16バイト。最長は65507バイト」である事が分かりました。念のため -l オプションのバイト数を変えながらいくつかデータを受信してみました。
以下は、UdpIpToolで受信したのログですが、見やすいように10バイト毎に改行を入れています。
-lで指定したバイト数(最小16バイト)のデータがUDPペイロードに入って送られてきているようです。
-l 100
先頭から100バイトを送っていますね。->受 192.168.10.80 (60807)
<00><00><32><15><5d><8a><f9><9e><00><0b>
<83><7a><00><00><00><00><08><00><00><00>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><00><34><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
<30><31><32><33><34><35><36><37><38><39>
-l 20
20バイトは20バイト送っています。->受 192.168.10.80 (56571)
<00><00><fa><89><5d><8a><f7><a9><00><0a>
<a4><4e><00><00><00><00><08><00><00><00>
-l 10
10バイトの指定では、16バイト送信しています。->受 192.168.10.80 (61682)
<00><01><39><c0><5d><8a><f7><7b><00><0b>
<df><e4><00><00><00><00>
-l 1
1バイトの指定では、16バイト送信しています。->受 192.168.10.80 (52166)
<00><01><39><af><5d><8a><f7><32><00><07>
<9a><3f><00><00><00><00>
まとめ
今回はここまで。- iperf2やiperf3は、クライアントからサーバに対しTCP接続をして測定制御をしている(UDPモードでも)
- Iperf3は、片方向通信環境の場合エラーが発生し測定は出来ない。
- iperf2はUDPモードならクライアントから送信は行うが、表示される送信結果は「送信したデータ長であり、サーバ側に到達したデータ量ではない」
- -l オプションを付けることで送信データ長を指定できるが、最小は16バイト・最長は最大値 65507バイト。
次回はiperfが送信しているパケットフォーマットをwiresharkで解析してみます。
私たちドルフィンシステムは、お客様の様々な要望に答えられるように色々と実験をしています。最適な無線システムを提案していけるよう努力しております。
SDRを用いた無線システムのご要望はドルフィンシステムへ。
コメント
コメントを投稿