Sousu's ARENA

[ DIYに戻る ]
PC用ゲーミングデバイス（キーボード・マウス・ゲームパッド）の応答速度が知りたい
2022.02.01
新規作成
2022.02.20
更新(SteelSeries Apex PROの結果を追加)
2022.03.08
更新(マウスデータ数点およびSTORY追加)
2022.03.13
Conclusion(結論・まとめ)追加
2023.01.31
更新(SteelSeries Apex 9,Wooting 60HE,Wooting TWO HE追加)
2023.03.06
更新(CORSAIR K70 OPX,CORSAIR K60 OPX追加)
2023.03.30
更新(Razer BASILISK V3 PRO追加)
Abstract（概要）

HID入力デバイス（キーボード・マウス・ゲームパッド）の応答速度を横並びで比較できる装置がほしくて、作ってみました。

測定風景
Introduction（まえがき・序論）

みなさん、どんなゲーミングデバイスをお使いですか？

最新メカニカルキーボード？それとも、こだわりのゲームパッド？

いろいろ流派があるみたいですが、 理論値最強（最速）はどれなのよ！って気になりませんか？

そんな悩みに解決に糸口を用意しよう、というのが今回のテーマです。



Materials and Methods（材料および方法）
fig.1：
ブロック図

  1. IOボードにボタンを押すための信号を出力する。ここでタイマースタート！
  2. IOボードはUSBからの信号を受けてポート論理を変化させる。
  3. MOSFETを経由してソレノイドを駆動する
  4. ソレノイドが入力デバイスのスイッチを押し込む
  5. 入力デバイスからの信号を検知する。ここでタイマーストップ！

  6. １～５をボタン押し、ボタン離しについて繰り返す

１～５にそれぞれ遅延がありますが、３～４のソレノイド動作が遅いので、後からその分を差し引きます。

回路図にすると、ものすごく単純です

fig.2：回路図
回路図

結線はこんな感じです
fig.3：結線（クリックで拡大）
結線

HIDデバイスへの入力にソレノイドを使用していますが、 電気的に直接つなぐ場合は、フォトカプラ（＋負荷抵抗）に置き換えて使用しました。



用意する物：

シリアル変換モジュールはFTDIのFT232HL搭載のものです。 他のモジュールでも動作しますが、応答速度（応答時間）誤差の面で、FT232HLを強く推奨します。

ソレノイドは秋月で買いました。ソレノイドを三脚に取り付けるため、3Dプリンタでアダプタを作りました。

fig.4：ソレノイドアダプタ
ソレノイドアダプタ

FETはソレノイドに1A流すので、2Aぐらいは流せるものが安心です。今回はありものです。

電源は安定化電源を使用しました。ソレノイドに1A流すので、USBから給電するのはお勧めできません。

ソレノイドを使わず、電気的に直接つなぐ場合は、フォトカプラが便利です




参考：
Materials(測定方法)
測定プログラムはこちらです
HID Latency Checker(GitHub)

FTDIのUSBインターフェイスボードから出力し、Direct inputでHIDデバイスの応答を確認するソフトです。 FTDI社から提供されているFTDIドライバのラッパーライブラリ(FTD2XX_NET)を使っています。 実行にはFTD2XX_NET.dllが必要で、2022現在、下記リンク先で配布されています。

FTD2XX_NET配布元：C# Examples(FTDI)


動作としては下記ような流れになります。

  1. FTD2XXでポート出力(ボタン押信号)して、タイマースタート
  2. キーボードのHキー、マウスの左クリック、ゲームパッドのボタン１のいずれかの入力があったらタイマーストップ
  3. 次の出力まで少し待つ。待ち時間は少しずつずらす（0.1ms単位で加算ループ）
  4. FTD2XXでポート出力（ボタン離信号）して、タイマースタート
  5. ２．で検知したいずれかのキーが離されたらタイマーストップ
  6. ２．と５．で測定したそれぞれの時間(ms)を記憶する

  7. １～６を繰り返す

キーボードのCキー押下で記憶した全データをcsvに吐き出すことができます

注意点としては、最初の１回は自動で始まりませんので、 マウスクリックするなどの必要があり、 さらに、１回目のデータもcsvから手動で除去する必要があります。

あとは、csvなので好きなように統計を取るだけです。


データ例
fig.5：DaemonBiteArcadeEncoder Latency
DaemonBiteArcadeEncoder

fig.5のデータの場合、ボタンが押されてから0～1[ms]の間に、 ほぼ均等な頻度（矩形分布）で応答していることが分かります。 平均値(AVERAGE)は0.54[ms]、標準偏差（σ）は0.29[ms]です。

σ（標準偏差）は散らばり具合のことで、正規分布なら±3σ→99.7%区間です。 ただし、USBの一定周期でポーリングしている関係上、理想的には矩形分布になりますから、 分布が山なりから外れていた場合、±3σはあくまで目安です。

ONおよびOFFはそれぞれ、「キーを押し命令を出してからデバイスが反応するまでの時間」 および「キーを離し命令を出してからデバイスが反応するまでの時間」です 各マウスについて約1000回ずつ行っています。


Results（結果）

測定結果一覧です

fig.6 ：PC用入力デバイスの応答時間
PC用入力デバイスの応答時間

fig.6は途中から反映が面倒になって全部のデータは載せていません。各デバイスの個別解析は下記の個別ページを参照してください。

用意したHIDデバイス：

キーボード：

キーボードの反応時間

キーボードでは低Latencyが売りのHuntsman V2が頭一つ抜けています。 お気に入りのRealforceは、平均もばらつきも成績が振るわず、個人的には残念でなりません。 NiZ 84EC(S)BLeも静電容量スイッチで10[ms]前後の応答時間なので、Realforceも10[ms]は切ってほしいなと思ったりします。

キーボードは、他のデバイスと比較して応答時間を改善するのが難しいようです。また、この測定では見えてこないような、体感の応答時間低減する工夫が取り入れられていたりします。 このあたりの考察は、別記事にまとめましたので、下記リンク先を参照いただけるとうれしいです。

ゲーミングキーボードの応答時間考察


ゲームパッド
ゲームパッドの反応時間

ゲームパッド系では、LogitechのF310は約5[ms]です。このあたりからトップランナーが使うような低遅延ゾーンです。 その他、DaemonBiteArcadeEncoderがUSB Latency 1[ms](1000Hz)デバイスの限界特性を叩き出しており、リファレンスといっていいでしょう。 JY-PSUAD11だけは、hidusbfでUSBのLatencyを変更した値を載せています。あくまで参考ということで。


マウス：
マウスの反応時間

マウスは有線のViper 8KHzが飛びぬけて高性能ですが、無線のG Pro X SuperLiteやViper Ultimateも負けていません。 数年前までは無線≒遅いだったのですが、今は有線タイプを買う理由がかなり減ってきたいように感じます。

Discussion(考察)
苦労したところなどのメモ書きです

１．出力I/F
今回の測定系には元ネタがあります。

上記いずれも、PCからの出力に液晶ディスプレイを使っていて、VSYNC監視で出力タイミングのばらつきを抑えています。 今回も同様の方法を取ろうと思ったのですが、Windows11の現環境ではこの当時のようなデータが再現できず、 出力I/Fを見直しました。

出力I/FにFTDIのシリアル変換ボード使用することにしたのは、出力遅延が少ないからです。 出力遅延がきわめて小であれば、出力タイミングのばらつきも抑えられるという考え方です。 FT232RLを使用してみたところ、出力は即時usbに出力されるようでした。 最終的にはさらなる出力遅延やばらつきの低減のため、FT323HLに変更しました。（後述）



２．FTDIのシリアル変換ボードの遅延

FTDIのUSB変換ボードはBit-bangモードというのがあり、 FTD2XXというライブラリを使うと、汎用入出力のように使用できます。 当初、このBit-bangモードを使用してFT232RLを使用して測定していたのですが 出力までの遅延がわずかにあり、数十[us]レベルでばらつくようでした。(fig.7)

fig.7：FT232R
USB信号からポート出力までの遅延(この時間がばらつく）
FT232R

これではLatencyが数msのような最新デバイスを測定するには精度としては厳しいです。

そこで用意したのが、FT232HLを使用したUSB変換ボードです。

USBデータがFT232HLに到達してからピン出力までの遅延は1[us]未満でした（波形とりわすれた）。 ループバックで測定してみると、平均≒0.2[ms],σ≒0.05,でした。(fig.8)

fig.8：FT232HLループバック Latency
FT232hl

前述(fig.5)のDaemonBiteArcadeEncoderを測定したところ,0~1[ms]のきれいな矩形分布が得られています。 これはUSB FULL Speedのデバイスのほぼ理論値限界に近い測定結果であることから、 Latency＜1[ms]のようなデバイスの測定にも十分耐える実力ということがわかります。

また、今回はFT232HLの入力を使用していませんが、ループバックのデータから、入力Latencyも小であることがわかっています。 FT232Rと比較してきわめて高速であり（FT232RLは入力Latencyが最小でも2ms前後）、今後も高速なUSB I/Oデバイスとして使っていきたいと思いました。



３．PCからの出力タイミング

PCからの出力I/Fが決まったら、これをプログラムから制御して連続して出力をする必要があります。 ここで、「定期的」に出力したり、「一定時間後に出力」してしまうと、正しい測定が行えないことがわかりました。

たとえば、前回SW検出後、100[ms]たってからSWを反転とやった場合、 前回SW検出タイミングは当然USBのポーリング周期と同期していますから、 出力タイミングが毎回USBのポーリング周期と同期してしまうわけです。

こうなると、USBのポーリングに同期して先読みするようにSWを押すことになりますから、 たとえば、ポーリングタイミングの直前にSWを押すと、 直ちにSW検出からUSBデータ送信までつながってしまいます。

こうなると、USBのLatencyが8[ms]などと長周期なはずなのに、応答時間が一定のタイミングに集中するようなことになり、 正確な応答時間測定が行えません。

これを回避するために、前回検出後、次の出力までのDelayを順次変更する対策を入れました。 例えば、100.1, 100.2, 100.3, 100.4, 100.5...[ms]というように、次のSW出力までのDelayを順次変更します。 つまり、ボタン押下間隔を毎回変更していくわけです。

このことにより、Fig.9,Fig10のように、応答時間が矩形分布するようなデバイスでも正しく測定できるようになりました。

fig.9：DaemonBiteArcadeEncoder Latency（測定失敗）
DaemonBiteArcadeEncoder fig.10：DaemonBiteArcadeEncoder Latency（測定成功）
DaemonBiteArcadeEncoder

他の意人の検証結果を見ると、同じ機器を測定しているはずなのに、測定者によって応答時間データがまちまちなのは、この辺に原因があったりするかもしれません。

４．ソレノイドの遅延

電気的に接続して測定という手法がとりにくいデバイスの一つに、静電容量キーボードがあります。 これを解決するため、ソレノイドを利用したボタン押下による測定を実現しました。

ここで問題になったのが、ソレノイドの動作遅延です。

ソレノイドの物理的な動きはほとんど肉眼では追えませんから、 動作遅延も無視できるかと考えていました。

しかし、実際にボタン押下信号と実際に押されたタイミングを波形で確認すると、 数[ms]遅れているのがわかりました。特に押下時が遅く、約8ms遅延がありました。

色々調べてみると、ソレノイドの動作は、コイルによる磁界と磁石を使った動作であるため、 コイルの特性をもろに受け、始動動作は結構遅いのだそうです。

高速化手法はいろいろあるようなのですが、電圧コントロール等必要で複雑なため保留し、 記録データからソレノイド動作時間をオフセットする方法をとることにしました。

しかし、オフセットを求めようにも、静電容量キーボードの電極をプロービングすると容量が変わってしまうので、 直接的にオフセットを測定することができません。

そこで、他のキーON,OFF位置が似ているキーボード(Huntsman V2)を使用して、オフセット時間を求め、 そのオフセット時間を補正値として適用することにしました。

また、キーボードとソレノイドの距離を変えると、わずかに遅延時間が変わることがわかっています。 これは約0.5ms~1msのようで、ソレノイドの動作開始までの時間の他にソレノイド自体が動く時間なのだと考えられます。

Our Keyboard Typing Experience Tests Latency(RTINGS.COM)の動画を見ると、3[ms]もありますから、ソレノイドによっては侮れない遅延です。

今回は、オフセットを求めた状態に近い状態に設置することで、誤差を抑えるようにしました。

対象がRealforceだけであり（後で増えましたが）、Realforce自体が1msを論じるほど高速ではないという判断です。

さらに、ソレノイドの動作遅延にはばらつきがあるようです。

Huntsman V2を使用して比較したところ、σが0.13[ms]→0.28[ms]とわずかに増加しました（fig.11,fig.12)。

fig.11：Huntsman V2 FET駆動 Latency
Huntsman V2 FET駆動

fig.12：Huntsman V2 SOLENOID駆動 Latency
Huntsman V2 SOLENOID駆動

物理的な動作を伴う機械ですので、仕方がないのですが、今後の課題です。 現状では、フォトカプラやFETなどで直接電気的にスイッチを制御したほうが、 ばらつきが少ないデータになるという結論です。

５．USB入力デバイスのポーリングレート変更パッチ

入力デバイスの応答速度に大きな影響を及ぼすのがポーリングレートです。 HID入力デバイスのポーリングレートはUSB Low speedの125Hzにはじまり、 最近ではUSB high speed以上の8kHzのデバイスも出てきました

しかし、デフォルトでは低速なデバイスへの改善方法として、 USBドライバのポーリングレートの変更で対処する方法が知られています

これは、XPの頃はusbport.sysの改造で知られていた方法で、 Windows7あたりからhidusbfというフィルタドライバを適用する方法が知られています。

Windows11でも同様で、hidusbfが使用できるのですが、正直導入に詰まったので、正しく適用できた方法をここに残します

前提：
hidusbfインストール手順(Windows11 x64)

６．マウス設置状態

意外に盲点だったのがこれ。 マウスの移動読み取りセンサーの状態により、応答時間が変わる現象です。

例えば、マウスをマウスパッドに置いた状態と、浮かせた状態で、応答時間が約10msも変わってしまうマウスがあります。 Logicool G903（参考リンク）などが代表的です。(fig.13,Fig.14)

fig.13：Logicool G903 Latency 無線
Logicool G903 無線Latency

fig.14：Logicool G903 Latency 無線（マウスパッドから浮いた状態）
Logicool G903 無線Latency

これを防ぐ方法は単純で、マウスの移動読み取りセンサーをマウスパッド等に設置した状態で測定することです。

Conclusion(結論・まとめ)

今回のテーマは、USB HIDデバイスの応答時間解析で、ポイントは過去の測定の精度向上でした。

手段としてUSB出力I/Fの低遅延化、PCからの出力タイミング調整、 ソレノイド等の外部遅延の把握、PC用測定ソフトウェアの最適化などを実施することにより、 より精度の高い測定方法を実現できたとおもいます。

具体的には、絶対値で応答時間1[ms]以下のデバイスにも対応できるレベルに達していると考えられます。

そして、絶対値に近い値が測定できるようになったことにより、 異種デバイス間における応答速度比較ができるようになりました。

たとえば、従来キーボードの応答時間は比較的長く、ゲームパッドにはかないませんでした。 しかし、最近のキーボードーの応答時間を調べると、ゲームパッド同等以上の物が出て来ているという結果です。

その他分かったこととして、この手の測定データの難しさが少しわかりました。

この手の応答速度測定をしているサイトはいくつかあり、LDATを使用するもの、ASIO（音源）を使用するものなどあります。 しかし、上記最適化が不十分であるため意図した測定ができていないサイトはずいぶんあります。(RTINGS.COMなんかもそう)

皆さん苦戦されているんですね。

ソレノイドの遅延ばらつきなど、課題はありますので、機会があったら改良をめざしたいところです。

[ 「ゲーミングデバイス（キーボード・マウス・ゲームパッド）の応答速度が知りたい」に戻る ]
inserted by FC2 system