USBプロトコル層で解析する
今回の検証は、LGPを使う・使わないことでマウスレポートが届くタイミングがどの程度乱れる（＝ジッターが増える）か、さまざまな条件で検証する。何らかの理由でジッターが増えれば、それを基準に実効ポーリングレートも算出できる。LGPの使用・不使用で差がでるかに注目した。
検証環境は以下の通りだ。メモリーやGPUは検証内容には直接関係ないが、そこが律速にならないよう強めのものを選択しただけである。GPUドライバーはAdrenalin 26.6.4を、Resizable BARやSecure Boot、メモリー整合性やカーネルモードハードウェア強制スタック保護、HDRなどは一通り有効化、ディスプレーのリフレッシュレートは144Hzに設定した。
| 検証環境 | |
| CPU | AMD「Ryzen 7 9800X3D」 (8コア/16スレッド、最大5.2GHz) |
| CPUクーラー | ASRock「Challenger White 360 Digital」（簡易水冷、360mmラジエーター） |
| マザーボード | ASRock「B850M Challenger WiFi White」（AMD B850、BIOS 4.03） |
| メモリー | Micron「CP2K32G64C40U5B」 (32GB×2、DDR5-5600) |
| ビデオカード | ASRock「Radeon RX 9070 XT Taichi 16GB OC」（RX 9070 XT、16GB GDDR6） |
| ストレージ | Micron「CT2000T700SSD3」（2TB M.2 SSD、PCIe Gen 5） |
| 電源ユニット | ASRock「TC-1300T」（1300W、80 PLUS TITANIUM） |
| OS | Microsoft「Windows 11 Pro」（25H2） |
マウスの検証の多くは、MouseTeserが利用される。小さな点の並びがそろっている/バラけているかを見て、クリックやスクロールの反応精度を手軽に確認できるが、OS由来のノイズも交じる。
MouseTeserでは定性的だが複数パターンの微細な差は表しづらいため、今回はマウスレポートが届くタイミングに着目して検証していく。
そのため、今回はよりディープに計測できる「USBPcap」を利用し、OSやドライバーよりもさらにハードウェアに近い層でやりとりされるデータを直で観測することとした。OSの影響を受けない生のデータでLGPはどう働くのか、そこをダイレクトに比較したい。
検証方法は「マウスを高速で動かしつづけ、その際のマウスレポートをUSBPcapでキャプチャーし分析する」というもの。マウスを接続するポートや競合するUSBポートにDACやWebカメラ、キーボードを接続し、マウスレポートの出方に変化があるかを検証する。負荷を追加した結果マウスレポートに変化あるか否かを見極め、変化があるならLGPの使用・不使用で挙動が変化するかを見極める。
計測時においてマウスとキーボードのポーリングレートは8000Hzに設定。マウスの感度は3200cpi（Counts Per Inch）に設定した。検証自体はシンプルで、振り幅30〜34cmになるよう一定のリズムで左右に動かす。動かすスピードは1往復0.5秒となるようにした。1セット15秒とし、マウスの動きはじめと動き終わり（ログ取得操作などといった人間由来のノイズが入る区間）は破棄、残った区間のレポートを集計するというものだ。
ちなみに、3200cpiで30〜34cmというのは確実にマウスのレポートをキャプチャーするための選択だ。マウスは光学センサーが動きを感知した時、あるいはボタンやホイールの変化を検知した時「のみ」レポートを送信する。つまりマウスを小さくゆっくりとしか動かさなければ、レポートの絶対量も減る。検証が困難になってしまうのだ。
どの程度の速度でマウスを動かせばレポートが出るか気になる人のための理屈も解説しておこう。
マウスの1カウントに対応する移動量（mm）は、「25.4/CPI」※で計算できる。毎ポーリングで1カウント以上が検出できないとマウスレポートは送られず次のポーリング以降に持ち越しになる。
※マウスの1カウントは、1インチ（約25.4mm）動かしたときにマウスのセンサーが読み取る分解能の最小単位
１秒間に最低これだけ動かせば１カウントが保証されるという距離は、ポーリングレートとCPIの組み合わせで変わる。表にまとめると以下の通りだ。低CPIでゆっくり＆短距離動かすとレポートが出ないので、高ポーリングレートの意味がないともいえる。
今回の計測条件である3200cpiで30〜34cmを0.5秒で1往復という条件は、マウスレポートを安定して生み出すための条件なのだ。
| ポーリングレート | |||
| CPI | 8000Hz | 1000Hz | 125Hz |
| 400 | 508mm/s | 63.5mm/s | 7.9mm/s |
| 800 | 254mm/s | 31.8mm/s | 4.0mm/s |
| 1600 | 127mm/s | 15.9mm/s | 2.0mm/s |
| 3200 | 63.5mm/s | 7.9mm/s | 1.0mm/s |
| 6400 | 31.8mm/s | 4mm/s | 0.5mm/s |
| 12800 | 15.9mm/s | 2mm/s | 0.2mm/s |
Lightning Gaming Portsは他デバイスの干渉を避けられるか？
まずはLGPを利用すればマウスは他のデバイスの影響を受けないのか？ という確認から始める必要がある。USBPcapでキャプチャーしたログから、マウスレポートの届く間隔の変化をチェックしよう。
理論上125マイクロ秒きっちりで届くのが理想だが、マウスの加減速や他に干渉するデバイス（今回はWebカメラやキーボード）がある場合は大きく下がる。ただ125マイクロ秒の計算に使用するタイムスタンプは、OS側の処理の影響を受けるため、理論値±5%を許容範囲としている。
セットA：Webカメラとの競合
マウスにとって最悪の相手であるWebカメラやDACと同時併用するセットAの検証からスタートしよう。どのUSBのポートに何を接続するかは１〜５の５パターン準備した。この検証の為に、あえてどのパターンでもキーボードは隔離された①に装着し、一切操作はしないが、負荷源としてWebカメラを②、DACを⑧にセット。パターン１と２はマウスを④に接続しているが、これはB850側のUSBコントローラーにすべてぶら下げる最もUSBが混雑しやすい最悪のパターンだ。
そしてパターン3と4はマウスをLGPに接続したパターンだが、3は負荷のないクリーンなデータがとれるはず。２と４を比較し4が優位になる結果が出るのが一番うれしい（LGPの効果が証明できる）。もしLGPに意味がなければ、2と4は同じようなデータになるはずだ。5はやや特殊でLGP⑦は使っていないが、LGP⑦と同根の⑥を使っているためトポロジー的には4と同じだ。
まずパターン3のベースライン、すなわちLGPの⑦にのみマウスを装着した場合は60％のマウスレポートが定刻どおり届いている。LGPに装着しなくても負荷がオフのパターン１、負荷がオンでもLGPに装着したパターン４はベースラインとほぼ同じ。
つまり、Webカメラのようなアイソクロナス転送デバイスをマウスと同じUSBコントローラーに接続する（パターン２）と、今まで10回に6回はほぼ定刻どおりに届いていたマウスレポートが、10回に２回しかほぼ定刻に届かなくなる。マウスレポートが消える訳ではないので操作が破綻する訳ではないが、マウスレポートのジッターのばらつきが増える（上のグラフではジッターの標準偏差として表記）のはよろしくない。
しかし、なぜLGPにマウスだけを接続したパターン３でも、ほぼ定刻に届くマウスレポートは60％しかないのか？ そこでマウスレポート同士の間隔を計算し、レポート間隔の頻度を確認してみよう。今回はパターン1つあたり15〜20万件ものレポートが入っているため、グラフは全体に対する％でプロットしている。
この図が今回のLGP検証のすべてを物語っている。負荷の源としてWebカメラとDACを使用したセットAでは2を除く全てのパターンにおいて、定刻125マイクロ秒付近の山が最も高くなった。しかしポート②④⑧を使用しマウスと負荷源を同居させた場合、山の形は完全に崩れてしまう。つまりマウスレポートが定刻取りに来なくなったわけだ。
そして2を基準にLGPを利用するパターン4を見ると、USB 2.0のWebカメラやDACを使っていてもマウスがLGPを利用するだけでベースラインであるパターン3と同程度のジッターのないレポートが得られる。
そしてパターン2/4を基準にパターン5を見よう。アイソクロナス転送の負荷源を使い、LGPを使っていないという条件では、2と5は共通だが、5のマウスは負荷源とは別のUSBコントローラーに接続されている。接続の内容としては4と5はほぼ同じ。ただLGPと銘打たれているUSBポートを使っているか、いないかの差だけでマウスは同じUSBコントローラーに接続されている。LGPを使っていても、強力なアイソクロナス転送デバイスと同じUSBコントローラーに接続される（パターン2）なら効果がないが、物理的に異なるUSBコントローラーに接続される（パターン4）であれば効果はある。
さらに注目したいのは、山がもうひとつ、250マイクロ秒付近にも出現している点だ。この小山が250マイクロ秒ということは、定刻125マイクロ秒の2倍。つまり250マイクロ秒の山はレポート送出が1回飛ばされたことを意味している。
スキップが発生する理由は前述の通り、その瞬間CPIから計算できる所定の距離以上動いていなかったため。この250マイクロ秒の小山は、検証の都合どうしても出現する「マウスを切り返す時に発生する速度ゼロ区間」に近いカウントを拾っているということだ。LGPにマウスだけ接続するパターン3（ベースライン）であっても、ほぼ定刻通り到着するマウスレポート数が60％程度と解説したが、この原因はここにある。
ちなみにこのセットAにおける（マウスから見た）最大の悪役は「USB 2.0接続の」Webカメラである。先に述べた通りWebカメラは125マイクロ秒の枠内のうち平均20％程度を占有し、かつ毎回データ量が変化する。ただ今どきの高画質モデルはUSB 3.0接続になるため、マウスと競合する可能性は極めて小さい（理由は前述）。
セットB：マウスとキーボードは喧嘩するか？
ポーリングレート8000Hzのマウスとキーボードを同居させた場合、同じUSBコントローラーに接続するとマズいのだろうか？ それともLGPを使って異なるUSBコントローラーに隔離するのが良いのだろうか？ セットBではWebカメラやDACは排除し、キーボードとマウスのみで検証する。パターン6〜10の5種類であり、パターン8がLGPを使用するだけのベースライン、本命は両LGPにキーボードとマウスを接続するパターン9である。
ここでも検証方法はUSBPcapによるレポートの分析だが、キーボードの扱いがが問題だ。キーボードは基本的に打鍵することでレポートが送出されるため、キーを押しまくることが肝要だ。しかしマウスを30〜34cm幅で高速で動かす操作と、キーボードを押す操作を一人で実施するのは肉体的にとても辛い。最初は良くてもテストのランを重ねるごとに乳酸の効果でブレの大きなデータが出てくる（しかも後のデータほど悪化する）ほか、両者のリズムが同期しマウス移動速度が保てなくなる、といった問題が出てくるからだ。
そこで登場するのがキーボードを操作するデバイスである。キー数が1〜2キーであればソレノイドで物理的にキーを押す方法が楽だが、実際のゲームにおける操作を考えると6〜8キーは必要。ソレノイドでそれを実現すると大掛かりになるため断念。最終的に登場したのがキーボード内部のキースイッチ用端子に直接つなぎ、電気的にオン・オフをさせる寄生デバイスである。ちなみにキーボードのマクロ機能はUSBレポートが文字数分送出されないので、今回の用途には使えない。
この寄生デバイスでは「WASDQE」キーおよび「Shift」「Space」の合計8つのキーを、FPSっぽい操作になるような感じでランダムに送出するようプログラムしている。肝心の打鍵スピードは打鍵ベースで56キー/秒、レポートベースでは60キー/秒に設定した（ズレがあるのは状態報告だけのレポートも出るため）。
タイピング速度の非公式世界記録（305WPM）では打鍵数で換算するとおよそ25〜26キー/秒、FPSゲーマーの打鍵数は2〜10キー/秒であるため、今回の寄生デバイスは生身の人間では到底到達できない超高速入力をしていると考えるとよいだろう。
では最初にほぼ定刻通りに到着したレポートの割合を観察してみよう。
どのパターンにおいても定刻どおりに到着したレポートは全体の60％以上を占めている。100％にならない理由は前述の通りマウスの切り返し時に必ず発生する低速区間由来のものであるため、今回の計測手順では100％になることはない。
つまり何が言えるかといえば、ポーリングレート8000Hzのキーボードは、たとえマウスと同じUSBコントローラーに接続（パターン7/ 9/ 10）し、常人の倍以上の速度で打鍵したとしてもマウスの脅威にはならないということだ。
度数分布を見てもどのパターンも大半が125マイクロ秒に集中し、低速部分由来の250マイクロ秒にも山ができる。キーボードとマウスであれば、同じUSBコントローラーに接続しても問題は起きにくいという事実もデータから得られる。
こうして見ると「キーボードにポーリングレート8000Hzはマウスほど意味がない」という事もわかる。毎秒8000回レポートを送る能力はあるものの、毎秒56回打鍵したらレポートを送ることができるのは56回。キーボードの大半の時間はレポートなしで終わるのだ。マウスはある程度以上の速度で動かしていればマイクロフレームごとにレポートを出力するので、8000Hzは意味がある。キーボードは（基本的に）押さないとレポートが出ない。これが決定的な違いだ。
その分ユーザーの入力を伝えることができるため、キーボードのポーリングレート8000Hzは完全に無意味なスペックではない、ということも覚えておきたい。
コメント