tailscale VPNとRaspberryPiを使って、拠点間での同一セグメントネットワークを構築する の続きとなります。実際どのくらいの速度で通信できているのかを計測してみました。
測定対象
- 拠点AにおいたRaspberry Pi A, Mac A
- 拠点BにおいてRaspberry Pi B, Mac B
上記4台中2台の組み合わせでiperfを使ってスピードを測定します。RaspberryPiは2台とも4B。
なおどちらの拠点も回線はフレッツ光ネクストギガファミリーで、V6プラス対応。早朝での測定です。
インターネットスピードテスト
- RaspbyAのインターネットスピードテスト
pi@raspberrypi4:~ $ speedtest
Speedtest by Ookla
Server: fdcservers.net - Tokyo (id = 28910)
ISP: JPNE
Latency: 3.51 ms (0.30 ms jitter)
Download: 806.74 Mbps (data used: 1.4 GB)
Upload: 703.50 Mbps (data used: 460.1 MB)
Packet Loss: Not available.
なかなか速いです。ちなみにWiFi経由のWindowsやMacはこの半分程度のスコアです。
- RaspbyBのインターネットスピードテスト
こちらも、回線はフレッツ光ネクストギガファミリー
pi@raspberrypi4-2:~ $ speedtest
Speedtest by Ookla
Server: i3D.net - Tokyo (id = 21569)
ISP: NTT
Latency: 4.68 ms (0.44 ms jitter)
Download: 677.35 Mbps (data used: 998.6 MB)
Upload: 559.67 Mbps (data used: 350.3 MB)
Packet Loss: 0.0%
tailscaleネットワーク上のスピード測定
tailscaleアドレスを指定しての速度計測。L2トンネルは関係なく、純粋なtailscaleネットワークの速度測定となります。
iperfをつかって測定します。
pi@raspberrypi4:~ $ iperf -c 100.92.41.28
------------------------------------------------------------
Client connecting to 100.92.41.28, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 100.86.118.83 port 50576 connected with 100.92.41.28 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 103 MBytes 86.2 Mbits/sec
結果は以下。単位はbps。上の段がiperfでサーバー(受信)側となった装置、左がクライアント(送信)側となった装置です。
| RaspiA | MacA | RaspiB | MacB | |
|---|---|---|---|---|
| RaspiA | - | 214M | 165M | 129M |
| MacA | 209M | - | 82.0M | 62.4M |
| RaspiB | 168M | 178M | - | 176M |
| MacB | 136M | 209M | 155M | - |
L2トンネル間でのスピードテスト
LANアドレスを指定しての計測。拠点Aと拠点Bにまたがる*のついた数字が、L2トンネルを通った場合のスコアとなります。
| RaspiA | MacA | RaspiB | MacB | |
|---|---|---|---|---|
| RaspiA | 6.2G | 318M | N/A | *58.4M |
| MacA | 326M | 17.8G | *74.5M | *48.9M |
| RaspiB | N/A | *122M | 5.86G | 292M |
| MacB | *84.0M | *105M | 318M | 52.1G |
RaspberryPi同士の速度は測定できませんでした。前投稿のMTUの問題でパケットの送信に失敗しています。
それ以外の通信は問題なく、L2トンネルを通っても50～100Mbpsと、まあまあのスピードが出ています。
L2トンネル間でのスピードテスト (フラグメント化の影響を確認)
ひとつ上のテストは、パケットのフラグメントありでの結果でした。
iperfの通信をtcpdumpでみてわかったのですが、iperfはTCPプロトコルを独自で処理してるようで、TCPのSynを書き換えてMSS clampを行おうとしても無視されています。
iperfの-Mオプションで直接MSSの値を指定して、フラグメントありとなしの場合を比較して見ます。なお、Macではiperfの-Mオプションが有効にならなかったのでRaspberryPiのみの結果です。MSSを小さめに指定すれば、上のテストで失敗していたRaspberryPi同士のテストも正しく行えました。
- MSS=1100 (フラグメントなし)
RaspiA → RaspiB : 109Mbps
RaspiB → RaspiA : 92.1Mbps
- MSS=1400 (フラグメントあり)
RaspiA → RaspiB : 87.3Mbps (20%の速度低下)
RaspiB → RaspiA : 75.5Mbps (18%の速度低下)
L2トンネル間でのスピードテスト(IPv6)
面倒なのでMac間だけ。IPv4の場合と違い、パケットのフラグメンテーションが発生しているのですが、思ったほど遅くないようです。
MacA → MacB : 78.1Mbps
MacB → MacA : 64.8Mbps
L2トンネル間でのスピードテスト (IPv4 UDP)
面倒なのでMacA→MacBだけ。帯域30Mbpsまではパケットロスなし。
- 40Mbps
$ iperf -c 192.168.2.108 -u -b 40M -t 10
------------------------------------------------------------
Client connecting to 192.168.2.108, UDP port 5001
Sending 1470 byte datagrams, IPG target: 280.38 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.2.15 port 59532 connected with 192.168.2.108 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 50.0 MBytes 41.9 Mbits/sec
[ 4] Sent 35667 datagrams
[ 4] Server Report:
[ 4] 0.0-10.0 sec 50.0 MBytes 41.9 Mbits/sec 0.460 ms 26/35667 (0.073%)
[ 4] 0.00-10.00 sec 456 datagrams received out-of-order
- 50Mbps
$ iperf -c 192.168.2.108 -u -b 50M -t 10
------------------------------------------------------------
Client connecting to 192.168.2.108, UDP port 5001
Sending 1470 byte datagrams, IPG target: 224.30 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.2.15 port 61937 connected with 192.168.2.108 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 62.5 MBytes 52.4 Mbits/sec
[ 4] Sent 44584 datagrams
[ 4] Server Report:
[ 4] 0.0-10.0 sec 62.2 MBytes 52.2 Mbits/sec 0.304 ms 182/44584 (0.41%)
[ 4] 0.00-10.00 sec 519 datagrams received out-of-order
- 60Mbps: この辺からロス率が上昇します
$ iperf -c 192.168.2.108 -u -b 60M -t 10
------------------------------------------------------------
Client connecting to 192.168.2.108, UDP port 5001
Sending 1470 byte datagrams, IPG target: 186.92 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.2.15 port 61371 connected with 192.168.2.108 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 75.0 MBytes 62.9 Mbits/sec
[ 4] Sent 53500 datagrams
[ 4] Server Report:
[ 4] 0.0-10.0 sec 69.2 MBytes 58.0 Mbits/sec 0.322 ms 4148/53500 (7.8%)
[ 4] 0.00-10.01 sec 1413 datagrams received out-of-order
L2トンネル間でのスピードテスト (IPv4 UDP フラグメントなし)
上記UDPテストでは30Mbps以上でパケットロスが発生していましたが、これはパケットのフラグメント化が発生している状態での値となります。-l 1100オプションでフラグメント化がない場合も測定してみます。
- 60Mbps: パケットロス０％。
$ iperf -c 192.168.2.108 -u -b 60M -t 10 -l 1100
------------------------------------------------------------
Client connecting to 192.168.2.108, UDP port 5001
Sending 1100 byte datagrams, IPG target: 139.87 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.2.15 port 58531 connected with 192.168.2.108 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 75.0 MBytes 62.9 Mbits/sec
[ 4] Sent 71495 datagrams
[ 4] Server Report:
[ 4] 0.0-10.0 sec 75.0 MBytes 62.9 Mbits/sec 0.212 ms 0/71495 (0%)
[ 4] 0.00-10.00 sec 1436 datagrams received out-of-order
- 80Mbps: まだまだいける感じ
$ iperf -c 192.168.2.108 -u -b 80M -t 10 -l 1100
------------------------------------------------------------
Client connecting to 192.168.2.108, UDP port 5001
Sending 1100 byte datagrams, IPG target: 104.90 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.2.15 port 59674 connected with 192.168.2.108 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 100 MBytes 83.9 Mbits/sec
[ 4] Sent 95326 datagrams
[ 4] Server Report:
[ 4] 0.0-10.0 sec 99.9 MBytes 83.9 Mbits/sec 0.183 ms 52/95326 (0.055%)
[ 4] 0.00-10.00 sec 2499 datagrams received out-of-order