Taux de polling souris : 1000 Hz vaut-il vraiment 500 Hz ?

Doubler le polling de 500 Hz à 1000 Hz réduit l'intervalle de rapport de deux millisecondes à une et l'attente moyenne de planification d'environ une demi-milliseconde. Cette amélioration n'affecte qu'une seule étape de la chaîne d'entrée et compte surtout quand le rafraîchissement de l'écran, la fréquence d'images et le traitement sont déjà rapides. Pour le bureau et le jeu occasionnel, 500 Hz suffit généralement et peut réduire la charge du processeur ou la consommation de batterie. Un testeur navigateur peut révéler des motifs de synchronisation des événements, mais seul un utilitaire natif peut vérifier le taux de rapport USB lui-même.

En chiffres

Le saut de 125 Hz à 1000 Hz supprime 3,5 ms d’attente moyenne de planification. Le saut de 1000 Hz à 8000 Hz en supprime environ 0,44 ms. Ce sont des différences calculées à l’étape du polling, pas des mesures de bout en bout d’une souris ou d’un système particulier.

Les fabricants de souris font désormais du polling 8000 Hz un argument de fiche technique, avec l’implication claire que tout taux inférieur vous freine. Le passage de 500 Hz à 1000 Hz est réellement vrai sur le papier, mais la conséquence à l’écran est considérablement plus petite que ne le suggère le chiffre doublé, et poursuivre des taux plus élevés a des coûts que le marketing omet. Voici les comptes honnêtes.

Ce que le taux de polling décrit réellement

Votre souris échantillonne sa position et transmet ces données à l’ordinateur à une fréquence fixe. À 500 Hz, elle signale toutes les deux millisecondes. À 1000 Hz, chaque milliseconde. À 8000 Hz, toutes les 0,125 milliseconde. Un taux plus élevé signifie des mises à jour de position plus fréquentes, donc potentiellement moins de délai entre le mouvement de votre main et la réponse du curseur. Le mot opératoire est potentiellement. Le polling est une étape d’un pipeline de latence, et c’est presque jamais la plus longue.

Le calcul que tout le monde cite, et le contexte qu’il omet

La différence entre 1000 Hz et 500 Hz est d’une milliseconde dans l’intervalle de rapport. C’est tout l’avantage mesurable à l’étape du polling, et comme le mouvement survient à des moments aléatoires dans un intervalle, l’économie réalisée en moyenne est plus proche d’une demi-milliseconde.

Placez cela à côté des autres étapes de la même chaîne :

Étape	Durée typique
Intervalle de polling à 1000 Hz	1 ms
Intervalle de polling à 500 Hz	2 ms
Rafraîchissement d’écran à 144 Hz	6,9 ms
Rafraîchissement d’écran à 60 Hz	16,7 ms
Temps de frame GPU à 60 fps	16,7 ms
Réaction visuelle humaine	~200 ms (pas un délai de pipeline — une tout autre catégorie)
La milliseconde gagnée en doublant le taux de polling est un arrondi négligeable à côté du rafraîchissement d’écran et du rendu des frames. Notez que la réaction visuelle humaine d’environ 200 ms listée ci-dessus appartient à une tout autre catégorie de mesure — c’est le temps que met le cerveau à traiter une stimulus visuel et à y répondre, pas un délai du pipeline d’entrée — donc la diviser par l’intervalle de polling n’est pas une comparaison valable. Cette relation proportionnelle est toute la raison pour laquelle beaucoup d’utilisateurs ne distinguent pas fiablement 500 Hz de 1000 Hz en usage ordinaire, même si la sensibilité varie selon le matériel, la tâche et les différences individuelles.

Quand 1000 Hz et au-delà aident réellement

Le polling élevé a le plus de chances de compter quand les autres maillons de la chaîne sont déjà rapides. Cela peut inclure, par exemple :

• Un écran à haut rafraîchissement, dans la plage 240 à 360 Hz, pour que l’écran puisse réellement présenter des mises à jour à des intervalles inférieurs à quatre millisecondes.
• Des fréquences d’images soutenues bien au-dessus du taux de rafraîchissement, pour que des frames rendues existent pour remplir ces occasions de rafraîchissement.
• Une latence système faible de bout en bout, avec une connexion USB directe, un traitement d’arrière-plan minimal et aucun overlay sur le chemin d’entrée. Dans cette fenêtre compétitive étroite et délibérément optimisée, certains joueurs peuvent tirer une valeur réelle de 1000 Hz et parfois de taux supérieurs. En dehors, le bénéfice est plus difficile à remarquer, car le goulot se déplace ailleurs et les rapports supplémentaires risquent d’être fusionnés ou échantillonnés avant d’influencer quoi que ce soit de visible.

Les coûts d’une montée plus haut

Le polling élevé n’est pas gratuit, et au-delà de 1000 Hz les compromis deviennent matériels :

Charge processeur

Chaque rapport traverse la pile d’entrée du système d’exploitation et souvent le moteur du jeu. À quatre mille ou huit mille hertz, cela consomme un temps processeur mesurable, et sur des systèmes plus faibles, la réduction de fréquence d’images qui en résulte peut augmenter la latence totale au lieu de la réduire.

Consommation de batterie

Les souris sans fil consomment généralement plus d’énergie à taux élevés, et 8000 Hz peut réduire substantiellement l’autonomie entre charges sur certains modèles.

Des rapports qui se traduisent rarement en bénéfice visible

Une souris 8000 Hz signale toutes les 0,125 milliseconde tandis qu’un écran 360 Hz se rafraîchit toutes les 2,8. Plus de vingt rapports arrivent entre deux frames consécutives ; le système d’exploitation et le moteur de jeu les fusionnent, les groupent ou les échantillonnent à leur propre cadence, donc la granularité excédentaire n’atteint pas fiablement une frame rendue.

Le taux de polling n’est ni la visée ni le DPI

Deux confusions tenaces faussent les décisions d’achat :

• Le DPI est la sensibilité du capteur : il décrit le déplacement du curseur par pouce de mouvement physique. Il est entièrement indépendant du polling et se règle pour le confort, pas pour la latence.
• La qualité de visée vient de la précision du capteur, de la surface, de la prise en main et de l’entraînement. Une souris 1000 Hz avec un capteur qui lisse ou accroche les angles visera moins bien qu’une souris 500 Hz à implémentation propre. Aucune des deux n’est améliorée par la spécification de polling, et les fabricants profitent de cette ambiguïté.

Vérifiez ce que vous obtenez réellement

Le taux configuré et le taux délivré peuvent diverger, mais un navigateur ne peut pas lire directement le taux de polling du matériel : les événements de souris sont soumis à la fusion du navigateur, à l’ordonnancement du thread principal et au traitement des entrées du système, donc un chronométrage web ne peut pas prouver le vrai intervalle de rapport USB. Pour une mesure fiable, utilisez un utilitaire natif dédié qui lit les données de niveau USB, ou le logiciel du fabricant de votre souris. Ce qu’un outil navigateur comme notre testeur de souris peut apporter, c’est un contrôle de motif grossier — des écarts inhabituellement longs et constants entre mises à jour enregistrées peuvent suggérer un problème de connexion, de pilote, de récepteur ou d’ordonnancement à vérifier avec un outil natif. Connectez-vous directement à un port de carte mère reconnu fiable et retestez avant de conclure que la souris est en cause.

Valeurs par défaut recommandées

• Souris gaming filaire : 1000 Hz est un choix par défaut sensé sur la plupart des systèmes modernes ; baissez si vous observez des problèmes de processeur ou de temps de frame.
• Souris sans fil : beaucoup de récepteurs 2,4 GHz modernes supportent 1000 Hz, choisissez donc par priorité : 1000 Hz pour l’intervalle de rapport le plus court, ou 500 Hz si l’autonomie compte davantage. La différence de ressenti est difficile à détecter pour beaucoup d’utilisateurs, tandis que l’économie de batterie à 500 Hz peut être réelle.
• Configuration compétitive avec écran à haut rafraîchissement et fréquences d’images élevées : essayez 1000 à 2000 Hz et évaluez honnêtement si vous détectez une différence. Sinon, redescendez et récupérez la marge processeur.
• Tout le reste, y compris la plupart des usages bureautiques : 500 Hz suffit généralement. Ne vérifiez le réglage que pour diagnostiquer un problème précis.

Comment l’USB gère les rapports de souris au niveau du protocole

Les périphériques USB communiquent avec l’hôte par des endpoints, chacun configuré pour un type de transfert précis. Les souris utilisent des transferts d’interruption, dont l’intervalle d’interrogation est planifié par le contrôleur hôte à la fréquence configurée — l’hôte réserve ces créneaux horaires, mais la livraison réelle peut quand même osciller sous charge système. Le périphérique répond avec les données qu’il a prêtes. La granularité temporelle dépend de la vitesse USB : un périphérique Full-Speed (typique des souris) est planifié en trames d’une milliseconde, tandis qu’un périphérique High-Speed utilise des microtrames de 125 microsecondes. Une souris configurée à 1000 Hz obtient donc un créneau d’une milliseconde sur une connexion Full-Speed ; la sémantique exacte de l’intervalle d’endpoint diffère entre Full-Speed et High-Speed, et la cadence réelle des rapports dépend aussi de la façon dont le descripteur du périphérique déclare son intervalle. Le paquet de rapport lui-même est défini par le descripteur HID du périphérique, qui déclare la structure et la taille des données envoyées par la souris. Un rapport standard contient un octet d’état des boutons, un delta X, un delta Y et, en option, la molette et des axes supplémentaires. La charge utile totale est petite — typiquement huit à seize octets — ce qui signifie que la bande passante en est presque jamais la contrainte principale. La contrainte, c’est le timing : à quelle fréquence l’hôte planifie un transfert, à quelle vitesse le périphérique peut le remplir, et à quelle rapidité la pile d’entrée du système d’exploitation peut le traiter. Au niveau du système d’exploitation, chaque rapport reçu déclenche une interruption qui se propage à travers la pile de pilotes USB, le pilote de classe HID et finalement le sous-système d’entrée, qui met à jour la position du curseur ou transmet l’événement à l’application au premier plan. Le système d’exploitation ne transmet pas simplement chaque rapport au moteur de jeu ; il les groupe, les fusionne ou les traite selon sa propre conception de gestion des entrées, ce qui signifie que tout rapport n’influence pas nécessairement une frame rendue. Cette compréhension au niveau du protocole clarifie plusieurs points. D’abord, le taux de polling est une propriété de la configuration de l’endpoint USB, pas du capteur de la souris — le capteur peut échantillonner à son propre rythme, indépendamment. Ensuite, un hôte et un périphérique compatibles peuvent planifier des rapports à l’intervalle configuré, mais la cadence réelle dépend toujours du descripteur, du firmware, de la connexion et de l’ordonnancement du système d’exploitation. Enfin, le coût de traitement s’accumule aux taux extrêmes et peut réduire les performances de jeu sur certains systèmes. La spécification décrit une cadence de planification, pas une garantie d’amélioration perceptible, et les couches entre le câble et l’écran introduisent chacune une latence que le taux de polling ne peut pas traiter. Une subtilité supplémentaire : l’ordonnancement du contrôleur USB n’est pas parfaitement déterministe. Le contrôleur hôte gère plusieurs périphériques partageant le même bus, et d’autres trafics peuvent introduire de petites variations de timing. L’ampleur de cette variation dépend du contrôleur, des pilotes, des périphériques connectés et du système d’exploitation : elle doit donc être mesurée plutôt que présumée. Un port direct de la carte mère est une comparaison diagnostique raisonnable, mais l’USB 3.x n’est pas intrinsèquement requis pour une souris.

Une milliseconde est l’écart maximal d’intervalle entre 500 Hz et 1000 Hz à l’étape du polling. C’est réel et mesurable, mais pour beaucoup d’utilisateurs difficile à remarquer. Les autres étapes du pipeline — temps de frame GPU, traitement du système, rafraîchissement de l’écran — peuvent contribuer bien davantage, et aucun réglage de souris ne peut les raccourcir. Si vous possédez une souris gaming et un écran à haut rafraîchissement, 1000 Hz est un point de départ raisonnable, mais évaluez la charge processeur, le temps de frame, la consommation de batterie et votre propre expérience plutôt que d’en faire une exigence universelle.

Pour comprendre où se situe le taux de polling dans la chaîne de latence globale, suivons un seul mouvement de souris à travers chaque étape, de la surface physique au changement de curseur visible. Chaque étape ajoute du temps, et le polling n’en est qu’une. Échantillonnage du capteur. Le capteur optique de votre souris capture des images de la surface à un rythme interne élevé — souvent 12 000 à 16 000 images par seconde — et compare les images consécutives pour calculer le mouvement. Ce processus est entièrement interne au capteur et fonctionne à sa propre fréquence, indépendante du taux de polling USB. Le capteur produit un delta de position et le transmet au microcontrôleur de la souris. Traitement par le microcontrôleur. Le MCU reçoit le delta du capteur, applique les traitements configurés — accrochage d’angles, lissage, accélération — et l’assemble en paquet de rapport USB. Cette étape ajoute un délai petit mais non nul — les modèles illustratifs suggèrent moins d’une milliseconde sur un firmware bien conçu, mais les valeurs réelles varient selon le périphérique et peuvent être plus longues sur les périphériques à traitement DSP lourd. Transfert USB. C’est l’étape gouvernée par le taux de polling. À 1000 Hz, le rapport assemblé attend le prochain transfert d’interruption planifié, qui survient chaque milliseconde. En moyenne, le rapport attend la moitié de cet intervalle — 0,5 milliseconde — avant d’être transmis à l’hôte. À 500 Hz, l’attente moyenne double pour atteindre une milliseconde. Pile d’entrée du système d’exploitation. L’hôte reçoit le rapport et le traite à travers le pilote USB, le pilote de classe HID et le sous-système d’entrée. La position du curseur est mise à jour dans le compositeur du système, et l’événement d’entrée brut est transmis au jeu. Cette étape est communément modélisée entre une et trois millisecondes selon le système, la version des pilotes et la charge — à traiter comme une fourchette illustrative, pas comme une mesure d’un système particulier. Traitement par le moteur de jeu. Le jeu reçoit l’événement d’entrée, applique sa propre logique de gestion des entrées (échelle de sensibilité, raw input contre entrée tamponnée, échantillonnage dépendant de la fréquence d’images) et intègre le mouvement dans la prochaine frame rendue. Si le jeu tourne à 60 fps, chaque frame prend 16,7 millisecondes, ce qui signifie que le mouvement ne peut pas apparaître à l’écran avant que la prochaine frame soit rendue et présentée à l’écran. Présentation à l’écran. La frame rendue voyage vers le moniteur, qui la présente à son propre intervalle de rafraîchissement. À 144 Hz, la frame apparaît à l’écran dans les 6,9 millisecondes suivant son arrivée dans la mémoire tampon d’entrée de l’écran. En additionnant les étapes typiques avec les attentes moyennes selon un modèle illustratif (pas une mesure d’une souris ou d’un jeu particulier) : capteur (~0,25 ms) + MCU (~0,5 ms) + USB à 1000 Hz (~0,5 ms d’attente moyenne) + système (~2 ms) + jeu à 60 fps (~8,3 ms d’attente moyenne de frame) + écran à 144 Hz (~3,5 ms d’attente moyenne de rafraîchissement) ≈ environ 15 millisecondes au total. Dans ce modèle, l’étape de polling USB contribue pour environ 3 % du total. Doubler l’intervalle pour passer à 500 Hz ajoute ~0,5 milliseconde en moyenne, portant le total à ~15,5 millisecondes. Voilà pourquoi la différence mesurée entre 500 Hz et 1000 Hz reste systématiquement sous la milliseconde — le reste du pipeline est inchangé. Ces chiffres sont un modèle illustratif, pas une mesure d’une souris, d’un système ou d’un jeu particulier ; les valeurs réelles dépendent entièrement de votre matériel, de vos pilotes et de vos logiciels. L’implication n’est pas que le taux de polling soit sans importance, mais qu’il soit le dernier composant à optimiser. Avec le même modèle d’attente moyenne : si votre jeu tourne à 60 fps, monter à 144 fps supprime environ 4,9 millisecondes d’attente moyenne de frame (16,7 ms / 2 moins 6,9 ms / 2) — soit environ dix fois l’économie du doublement du taux de polling. Si votre écran fonctionne à 60 Hz, passer à 144 Hz supprime en moyenne environ 4,9 millisecondes (16,7 ms / 2 moins 6,9 ms / 2). Les chiffres exacts dépendent de ce que vous mesurez — attente moyenne, temps de frame complet ou latence de bout en bout — traitez-les donc comme illustratifs plutôt qu’universels. Ces deux changements produisent aussi des améliorations visibles de la clarté de mouvement qu’aucun ajustement du taux de polling ne peut égaler. Ce n’est que quand la fréquence d’images et le taux de rafraîchissement sont déjà élevés que la contribution du polling devient une part proportionnellement plus grande de la latence restante, et même là, elle reste petite en valeur absolue.

Le seul chiffre à retenir

1000 Hz peut réduire l’intervalle de l’étape de polling d’au plus une milliseconde par rapport à 500 Hz, ce qui est réel mais souvent difficile à remarquer. Orientez d’abord votre optimisation vers le taux de rafraîchissement de l’écran et la fréquence d’images soutenue, car ces étapes peuvent apporter des retards bien plus grands, puis évaluez si le taux de polling change quelque chose de perceptible pour vous. Traitez 8000 Hz comme une option de signalement à haute résolution plutôt que comme une amélioration ressentie garantie, tant que le reste du pipeline ne peut pas l’exploiter.