それでは、毎秒125回以下のアクセスだと何が起きるか?
・・・・確かめてみましょう。単純に考えるとオーバーフローしやすくなり、データ長が8bitの場合、+127とか-128になりやすくなる、と思えますね。しかし、もしかしたら一定時間で変位が切り捨てられているのかも、という。
データの取得を毎秒1回程度にして実験してみます。
(データ割愛)
予想通り、+127や-128が多くなります。恐らく、内部的には1フレーム毎(ここでのフレームはGPUの描画やUSBの転送のことではなく、センサのフレームの事)に変位を該当Registerに加算する処理がなされているのでしょう。
要するに取得回数を極端に減らした場合、オーバーフローしながらもセンサは正常に動作するということです。何らかの形でマウスの負荷が上昇し、暫くの間データの取得が出来なくても安心です(そんな状況が発生している時点では全く安心出来ないですが)。
極々当たり前の結果ですが実際に確認した人は少ないと思いますので意味のない検証ではないはず。
ちなみにアクセス回数の上限ですがデータレートより、
・tSWW、tSRW、tSRR、tSWRと呼ばれるパラメタ値
によって決められます。この値はセンサによって多少大小があります。
加えて、当たり前ですがセンサのフレームレート以下のアクセスレートである必要もあるでしょう。
もっとレートを稼ぎたい場合はMotionBurstを使うような実装にするのでしょうか。
・ポーリングレート(レポートレート)について
ゲーミング用途においてはレートを減らす意味はあまりないです。
(最近NVIDIAのG-SYNCが話題ですので、フレーム描画に合わせてレポートするとかすれば「何か」起きるような気もします。)
「レートを上げすぎるとシステムへの負荷が増える」という説に関して :
確かにホストシステムへの負荷は上がっているはずで、間違っていないのですが、私が不勉強なせいなのか、「ベンチマークにおいてパフォーマンスの有意な低下を確認した」という資料は見かけていません。自分が「無い」と思っているものを探すのは不可能に近いので知ってらっしゃる方はコメントで情報お願いします。昔の話だとちらほら出なくもないのですが、当時とはMCUの性能、センサのスペックも違うのでホスト/マウスのどちらが原因かは断定出来ないんじゃないかと思っています。
また、いくつかのF2Pタイトルにおいて、125Hz以外のセッティングの場合に照準が波打つ現象は事実なのですが、あれはゲームの仕様という線が濃厚だと思っています(未検証)。
それでもって私が一番知りたいのは125、500、1000Hzどれが一番強いの?というテーマです。
最近考えているのは、
「想定速度域とMCU / ホストシステムの実装によって最適値は変わる」
という結論です。想定速度域がDPIとセンシティビティが大きく関わってきますし、実装に至ってはブラックボックスな上にメーカによって大きく異なりますので結論は出ないというのが結論じゃないでしょうか。そして、もし1000Hzが強いと証明されても、某F2Pタイトルで活躍しているユーザーさん達は125Hz一択なわけですしホストの方も考慮に入れる必要があります。ぶっちゃけた話ポーリングレート変えてもそこまで大きな変化がないという説が・・・ここで言ったらおしまいですね。ヤバイヤバイ。
ちなみに自分はパフォーマンスは置いておいても、入力遅延が少なさそうなので1000Hzにしています。
レポートレートに関してはもう少し掘り下げられると良いのですが・・・・
USBに関しては素人なので、USBのHIDのドキュメントや関連書籍をもう少し読み込む必要がありそうです。
ハード関係はちょっと深くなると日本語文献がグッと減るのが最近の悩みだったりします。
とても参考になる実証記事ありがとうございます。
返信削除少ないカウントでクリップしてしまうマウスを沢山持ってますが
USBのデータ転送が
僅か128or256カウント/Frame/axis程度で飽和するのは変だなぁと感じていました。
やはりセンサーの内部バッファがオーバーフローしてこういう現象が起きていたのですか。
素人思考ですとMCU⇔センサー間のSPI通信のクロックを
可能な限り高速にしていればクリップを防げるのではと思ってしまいますが
そう単純なことでも無さそうですね。。。
rafaさん
削除コメントありがとうございます。
USB自体でも1軸当たりに1バイト(-128~127count)という実装だったらクリップするかもしれません。
Windows標準のドライバは16bitなんでしょうか。USB HIDの規格が難しくて未だに確認がとれていません・・・
メーカが出している16bit対応のマウス用のドライバは当然16bitだと思うのですが。
>素人思考ですとMCU⇔センサー間のSPI通信のクロックを
>可能な限り高速にしていればクリップを防げるのではと思ってしまいますが
SPIのオーバークロックは面白そうです。今度やってみます。
後、1レポート(125?500?1000)の間に⊿X、Yを複数回リクエストすればセンサーのオーバーフローをある程度は防げると思います。
流石に16bitには叶わないと思いますが。実際この方法が使われているかどうか分かりませんが。問題はデータの処理時間とかなのでしょうか。
例えば1000Hzですとスイッチやセンサーとのやりとり、データ処理、USBでの転送を1ミリ秒の間に1スレッドで行わないといけないので。
しかし、センサーとUSBの伝送が両方8bitでも、毎秒125*127=15875カウント、つまり1フレームで267ピクセル程度の視点移動はできるので、
(特にローセンシの人は)過剰に高いDPI設定を避ければ問題は無いのでは?と思ったりします。それでも結構ギリギリではあるのですが・・・
>Windows標準のドライバは16bitなんでしょうか。
削除各メーカーのフィルタドライバが変な挙動をすると困るため
基本的に全てのマウスをWin7標準の HID準拠マウス ドライバで
カウントログを採るようにしていますが
マウスによってはちゃんと1Frameで8bit以上のカウントを返すため
Win7の標準ドライバでも16bits/axisには対応してるようです。
>センサーとUSBの伝送が両方8bitでも、毎秒125*127=15875カウント、つまり1フレームで267ピクセル程度の視点移動はできるので、
(特にローセンシの人は)過剰に高いDPI設定を避ければ問題は無いのでは?
有名所だとMSマウス辺りが当てはまりますね。
デフォルトの400dpi/8msPollingだと
丁度仰られる辺りのカウントで飽和します。
それでも低dpiなので確かに約1m/s以下の速度で動かす分には問題は無いようです。
しかし最近になってG502のように毎秒1,000,000カウント以上でも
安定して返してくるようなマウスも出てきたので
マウスごとの性能差が広がってきたと感じています。
データパスの実装までしっかりしてるメーカーと
杜撰なメーカーがはっきりしており面白いです。
歪なカウント応答をするマウスは
MCUファームで簡易的なdpiスケーリングをしているせいだと考えていましたけど
データパスでのバッファ処理も一枚噛んでいそうなことが解り収穫でした。
また実験記事楽しみにしております:)