前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。
本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。
ただ70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないということかと思うのだが、せっかくなので、ではTCPではどうなのか確かめてみた。以下、その結果。
追記書いてます。
—
#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか？
という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。
テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。
テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。
テストサーバー
テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。
結果は以下の通りである。
テストケース1: PM9時台に実施
| フレッツ光(Wi-Fi) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 0% | 11.704 | 16.691 | 23.845 | 3.0003ms |
| www.google.co.jp | 0% | 43.708 | 46.835 | 54.807 | 2.081ms |
| テストサーバー1 | 0% | 139.024 | 187.894 | 239.065 | 30.026ms |
| テストサーバー2 | 0% | 18.814 | 22.512 | 25.306 | 1.460ms |
| docomo(データ定額) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 0% | 108.174 | 118.389 | 154.171 | 8.798ms |
| www.google.co.jp | 0% | 128.898 | 141.954 | 155.505 | 6.944ms |
| テストサーバー1 | 0% | 206.165 | 217.398 | 361.339 | 26.932ms |
| テストサーバー2 | 0% | 106.566 | 132.891 | 613.313 | 89.298ms |
| Softbank(iPhone) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 73% | 88.733 | 179.106 | 370.456 | 92.697ms |
| www.google.co.jp | 86% | 116.306 | 120.867 | 126.555 | 4.248ms |
| テストサーバー1 | 76% | 240.308 | 259.038 | 318.825 | 24.805ms |
| テストサーバー2 | 90% | 121.751 | 131.433 | 146.446 | 10.763ms |
テストケース2: AM2時台に実施
| Softbank(iPhone) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 3% | 114.327 | 245.465 | 2133.128 | 403.058ms |
| www.google.co.jp | 23% | 107.446 | 178.063 | 896.914 | 161.420ms |
| テストサーバー1 | 0% | 533.464 | 1064.434 | 1991.588 | 373.095ms |
| テストサーバー2 | 3% | 401.674 | 967.69 | 1886.757 | 345.000ms |
比較のためWi-Fi(回線はフレッツ光)も付記している。
まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。
ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。
僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。
ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。