清水理史の「イニシャルB」
Wi-Fiの「遅延」をどう計るか？ Microsoft「PsPing」による計測を試す
2024年9月2日 06:00
Wi-Fi 7の登場で、「遅延」をどう評価すべきかに悩んでいる。
これまで本連載では、主にiPerf3を使った「速度」（帯域）でWi-Fi製品を評価してきた。しかし、Wi-Fi 7時代は速度だけでなく「遅延」も考慮した製品評価が求められており、何らかの評価方法を考える必要がある。まずは、MicrosoftがWindows向けに提供している、Pingを拡張したツール「PsPing」を試してみた。
遅延とは
「遅延」は、ビデオ会議向けサービスやオンラインゲームなどの利用時に話題になるネットワーク性能を示す指標のひとつだ。
一般的には、ICMPプロトコルの往復時間を計測する「Ping」というツールを利用して計測することが多い。例えば、Windows環境の場合、下図のようにPingコマンドを入力することで、「手元のPC→接続先→手元のPC」と小さなデータ（標準は32バイト）が、どれくらいの時間で戻ってくるのかをミリ秒（ms：1000分の1秒）単位で確認できる。
この遅延の値を「Ping値」または「Ping」、もしくはラウンドトリップタイム（RTT）と呼ぶことがある。仮にゲームを想定した場合、Ping値が10msなら、ゲームのプレイ時に、キャラクターを左に動かすためにパッドの左ボタンを押したとして、その情報がゲームサーバーに伝達されるまでに半分の5msかかるという意味になる。
遅延の値は、一般的には、ネットワーク上の端末間の通信時間を計測するために利用される。通信時間が短いほど遅延は低く、反対に長くなると遅延は大きくなる（実際にはバッファで調整）。
例えば、以下のマイクロソフトの文書では、Teams利用時の指標として、RTTが500ミリ秒未満という値が示されており、RTTが高いと、会議のシーンで、参加者が意図せず発言のタイミングが重複してしまう例が挙げられている。
また、インテルの文書では、オンラインゲームでパケットロスが発生する状況のPing値として300msという例を挙げている。
このほか、バトルロイヤルゲーム「PUBG」のサポートサイトの情報によると、「似たpingを持ったプレイヤーのマッチが成立・不成立されます」という記述がある。ゲームの品質のみならず、対戦プレイ時のマッチングの可否などにも、ユーザーの通信環境の遅延が影響している。
▼マイクロソフトの文書
リアルタイム テレメトリを使用して低品質の会議をトラブルシューティングする（マイクロソフト）
▼インテルの文書
パケットロスを解決する方法（インテル）
▼PUBGのサポートサイトの情報
pingでマッチングされますか？
RTTの値の例としては、以下のAzureの統計がひとつの目安となるだろう。国内や近隣なら10～20ms。米国などでは150ms前後になる。ただし、ウェブなどはCDNでキャッシュされた国内拠点から応答が戻る場合もあるのでケースバイケースと言える。
▼Azureのラウンドトリップ値統計
Azure ネットワーク ラウンドトリップ待ち時間統計
WindowsのPingツールの欠点
このように、Pingの値は意外に身近に使われているが、Windows版のPingコマンドは、あくまでも到達の可否を判断するためのツールとなるため、設定の自由度が低い。
具体的には、1ms以下の精度を計測できないうえ、計測の間隔も1秒以下に設定できない。
前述したようにインターネット上の計測をするのであれば問題ないが、筆者としては、LAN内の機器の値を計測したい。具体的には、今後、普及するであろうWi-Fi 7のMLOによる遅延の違いを計測したいので、より高い精度で計測できるツールが必要になる
Linuxの場合であれば、標準で1ms以下の値も計測できるうえ、「sudo ping 192.168.0.1 -i 0」とsudoによる管理者権限でiオプションを付けて実行すれば、連続してパケットを送信できるが、Windows版はこれができない。
以下のGoogleの文書によると、クラウド上のサーバーの遅延は「Netperf」を使うケースもあるようだが、Windowsで実行するとなると、WSL2環境が必要になり、ネットワークの構成が値に影響する可能性もある。
▼Googleが公開している遅延計測に関する文書
クラウドでのネットワーク レイテンシの測定
そこで、今回はMicrosoftが公開している「PsPing」を使って、どこまで遅延を計測できるかを検証してみることにした。Microsoft Storeから「Sysinternals」をインストールすると、たくさんのツールと一緒にインストールされる。導入は簡単なので、誰でも試すことができるだろう。
なお、今回の目的と関係ないが、クラウド上の特定のサービスに対してのPingをビジュアル化して確認したい場合は、「PingPlotter」というツールもある。0.1ms以下を計測できないので、今回は使わなかったが、経路やパケットロスなども計測できるので、試してみる価値はあるだろう。
▼PingPlotterのウェブサイト
PingPlotter
PsPingを使った遅延計測方法
前置きが長くなったが、今回はLAN内の機器の遅延を計測してみた。具体的には、有線と無線の違い、無線の周波数帯の違い、同時通信の有無の違いなどだ。
計測方法は、2台のWindows PCを用意し、それぞれで以下のオプション付きでPsPingを実行した。利用したWi-Fiルーターは、アイ・オー・データ機器「WN-7T94XR」で、クライアントには「Lenovo Yoga Slim 7x Gen9」（Snapdragon X搭載機）を利用した。双方ともWi-Fi 7対応でQualcommの無線チップを採用しており、相性がいい構成となっているはずだ。
サーバー：
psping -s ［自分のIPアドレス］:5000
クライアント：
psping -l 172 -n 100000 -h 100 ［サーバーのIPアドレス］:5000
PsPingは、通常のPingと同様にサーバー側でプログラムを実行しなくても利用できるのだが（ICMPモード）、今回は後述するヒストグラムを出力したかったのでサーバーを用意してTCPモードで計測した。
なお、パラメーターの「-l 172」はパケットサイズを示す。今回はCiscoのドキュメントで想定されている音声通信の容量を参考に172バイトに設定している（ゲームも同じくらいの通信量が想定される）。
また、「-n 100000」で10万回計測しているのは、試行錯誤した結果たどり着いた値となる。回数が少ないと短時間で終わってしまうので、ある程度の回数は必要だが、あまり多くすると無線のテストが終わらない。10万回だと、有線で10秒前後、無線で5分程度なのでテストとして適切という判断に至った。
ちなみに、ゲームや音声を想定するなら、UDPで計測すべきだという意見があるのはもっともなのだが、PsPingでUDPが利用できるのは帯域幅測定モードのみで、遅延の計測に利用できないため、今回はTCPで計測した（UDP計測ならNetPerfを使った方がよさそう）。
やっぱり有線は優秀
というわけで、PsPingの結果を見ていこう。
まずは、有線と6GHz帯の無線の遅延を比較したのが以下の結果となる。グラフは、横軸が往復にかかった時間（ms）で、縦軸が各時間で往復したパケットの数となる。値の開きが大きいので、目盛に対数を使っている点に注意してほしい。
例えば、以下のグラフで、青い点で示される有線の結果は、10万回のうちのほとんど（約8万回）のPing値が0.11msという結果で、次いで、0.13msが1万回……、というように続き、最大の2.49msはわずか1回ということを表している。
繰り返しになるが、各グラフのタイトルに示しているように目盛に対数を使っているので、各目盛の間隔が10倍になっている点に注意してほしい。
このグラフを見ると、有線がいかに優秀かということがわかる。平均で比べると、有線の遅延はわずか0.12msとなっており、1万分の1秒の範囲に分布している。逆に対数グラフだとわかりにくいが、10万パケットの約99％が0.2ms以下に集中している。
最大値こそ2.49msとなるが、これは10万回のうちの1回しか登場しないごく稀な値で、非常にばらつきが狭く、安定している。
速度（スループット）という点では、有線並みになったWi-Fiだが、遅延の数値を比べると、まだまだ差は大きい印象だ。
一方、6GHz帯の無線は、有線に比べて遅いとはいっても、平均で2.93msとなっており、ほとんどの値が10ms以下に収まっている。10ms以下であれば、ビデオ通話やオンラインゲームなどのアプリケーション側でも差を感じることはほとんどないレベルだ。
ただし、課題となるのが、稀に大きな遅延が発生することだ。グラフの右端の部分に注目すると、LAN内での計測であっても、精密なオンライン対戦ゲームなどで遅延が問題になる閾値の100msを超えてしまうことがあった。上記のグラフでは、100msを超えた回数が57回だった。
10万回のうちの57回なので、ごくわずかではあるが、計測時間での割合で考えると約5分間で57回なので、ゲーム環境などではこれを嫌うユーザーもいるかもしれない。
なお、100msを超えた値の原因まではPsPingだけでは判別できない。あくまでも推測となるが、外部からの無線の干渉というよりは、クライアント上での別の通信（何らかのブロードキャストとか？）が発生したのではないかと考えられる。
試しに、有線でも100万回、1000万回と回数を増やすことで、計測時間を長くし、その間に他の通信が発生するかどうかを検証してみた。すると、100万回時で最大22ms値が1回、1000万回時で最大61.99msが1回（20ms以上合計4回）、登場することが確認できた。同様にクライアント上で何らかの通信が同時に発生していることが影響していると考えられる。しかしながら、他の通信が発生したとしても、さすがに100msを超えるような遅延に至らない点で、有線は優秀だと言えるだろう。
無線は値がばらつく
上記のテスト結果のように、無線の場合、値がばらつくことが多いが、計測タイミングによっては100ms以上の値が出ないこともあった。正確に数えていないので、印象で申し訳ないが、100ms以上が出現するケースと出現しないケースは、7：3くらいの印象だ。
100ms以上の値が出現しなかったケース（1回目）と出現したケース（2回目）の状況をプロットし、比較したのが以下のグラフになる。
どちらも平均でみるとほぼ一緒なのだが、青い1回目の方は最大でも36.59msで収まっているのに対して、オレンジの2回目の方は148.64msとなっている。
つまり、無線の場合、外部からの干渉、もしくは内部通信が同時に発生しなければ、LAN内で100msを超えるようなことはないが、実際に計測していて100msを超えないケースは少なかった。印象としては、前述のように7：３くらいで100msを超える値を見かけるケースの方が多い印象だ。
周波数帯の違いを見る
続いて、無線の周波数帯の違いを検証してみた。6GHz帯と5GHz帯のSSIDのそれぞれでPsPingを実行したのが以下のグラフだ。
これに関しては、ほぼ同じという印象だ。細かな値の違いはあるが、最小、平均、最大ともに似通った値となっており、グラフも似たような分布になっている。
iPerf3による速度の場合、5GHz帯は外部の干渉を確認できるケースがあるが、今回の検証では、こうした傾向はみられなかった。
さらに、MLO接続時の値も検証してみた。今回の検証で利用したアクセスポイントとPCはともにWi-Fi 7のMLOに対応しており、標準設定では5GHz+6GHzの帯域を使った通信が可能になっている。
MLOには複数の方式があり、2つの帯域を合計してスループットを向上させるものと、両方の帯域を使い分けて接続性を向上させるものがあるが、今回は後者の方式の接続となる。
結果を見ると、これも大きな違いはないが、若干、MLOの方が遅延が大きくなっている印象がある。最小が1.9msで、平均も3msを超えている。グラフの10～30msの値もMLOの方が多い。全体的に、ほんのわずかだが値にゲタを履かされている印象がある。
MLOに関しては、現状、チップベンダーやWindows側の詳細なドキュメントや仕様が明らかにされておらず、正直、動作がよくわからない状況だが、原因を推測すると、2つある5GHzと6GHzの帯域のどちらを使うかを判断するための時間がプラスされているのではないかと考えられる。
おそらく、もっと状況の悪いケース、例えば5GHz帯と6GHz帯のどちらか片方の電波状況が極端に悪いケースではMLOが効果を発揮するが、そうではないケースではあまり意味がないのかもしれない。
同時通信は？？ 負荷が足りない？
最後に、筆者がもっとも知りたかった本命となる同時通信時の検証をしてみた。
有線の同時通信、5GHz帯の同時通信で、それぞれ3台のPCを用意し、2台のPCでアクセスポイントに対して連続してPsPingを実行し続けていた状態（前述した-i 0で終了次第次のパケットを送信）で、クライアントから遅延を計測している。
結果は以下の通りだ。
有線の場合、ほとんど影響を受けていないことがわかる。計測タイミングの違いによって、単独の方が最大値が2.49msと大きくなってしまったが、これは誤差の範囲と言える。
よくわからないのは、無線の同時通信の結果だ。最小と平均は単独の方が優秀だが、最大値は同時通信の方が小さい値となった。
計測時のタイミングによってたまたまこうした値が出たのかと思い、3日ほど使って同じテストを複数回繰り返したのだが、この傾向は変わらなかった。
これも内部的な処理を推測するしかないのだが、複数同時通信の場合、OFDMAが効果的に使われているのかもしれない。OFDMAは、無線の帯域を細かなリソースユニット（RU）に分割し、複数のユーザーに個別に割りあって同時通信できる技術となる。
OFDMAはWi-Fi 6から搭載された技術だが、Wi-Fi 6では、クライアントに対して1つのRUしか割り当てられなかった。ところがWi-Fi 7では、クライアントに対して複数のリソースユニットを割り当てることができるようになっている（MRU：Multi-RU）。
今回使用したアイ・オー・データ機器のWN-7T94XRではOFDMAが標準でオンになっており、このあたりの通信のしくみによって複数台接続時の通信効率が高くなっているのではないかと考えられる（Wi-Fi 6でも効果は期待できそう）。
PsPingで検証するか？ 別の方法を検討すべきか？
以上、今回はPsPingの使い方を紹介しながら、今後、本連載で「遅延」をどう扱っていくべきかを検討した。
個人的には、最後の同時通信時の遅延で何かしらの効果が出ることを期待していたのだが、この検証は課題が残ると言えそうだ。おそらく、こうすればよさそうという目途は立っているものの、どう実装すればいいのかが、まだよくわかっていない。さらに検証を進めていこうと思う。
ただ、今回の検証で、ひとつ明らかになったのは、やはり少しでも遅延の値を低くしたいなら有線が有利ということだ。
参考として以下のデータも掲載しておく。これはAzureのJapan Eastリージョンに仮想マシンを設置して、WAN経由でPsPingの値を計測した結果だ。WAN経由だと、ローカルの有線と無線の違いは関係なくなるかと思ったが、有線の方が遅延の値は低く収められた。
正直、この差なら、精密さが求められるオンライン対戦ゲームなどでも大きな違いにはならないかもしれないが、少しでも遅延を低くしたいなら有線が有利という印象だ。
製品レビューなど幅広く執筆しているが、実際に大手企業でネットワーク管理者をしていたこともあり、Windowsのネットワーク全般が得意ジャンル。最新刊「できるWindows 11」ほか多数の著書がある。