Taxa de polling do mouse: 1000 Hz é melhor que 500 Hz mesmo?
Dobrar a taxa de polling de 500 Hz para 1000 Hz encurta o intervalo de relatório de dois para um milissegundo — uma melhoria mínima numa única etapa de uma cadeia de latência muito mais longa. Na prática o ganho é imperceptível diante do intervalo de atualização da tela, do tempo de frame da GPU e da reação humana, todos uma ordem de magnitude maiores. Polling mais alto ajuda só quando todo outro elo já é rápido. Para escritório e jogos casuais, 500 Hz é funcionalmente idêntico e consome menos CPU e, no sem fio, menos bateria — embora receptores 2,4 GHz modernos suportem 1000 Hz.
Em números
| Taxa de polling | Intervalo de relatório | Espera média | Latência total do pipeline (típica) |
|---|---|---|---|
| 125 Hz | 8,0 ms | 4,0 ms | ~21 ms |
| 500 Hz | 2,0 ms | 1,0 ms | ~17 ms |
| 1000 Hz | 1,0 ms | 0,5 ms | ~16 ms |
| 2000 Hz | 0,5 ms | 0,25 ms | ~15,75 ms |
| 4000 Hz | 0,25 ms | 0,125 ms | ~15,6 ms |
| 8000 Hz | 0,125 ms | 0,06 ms | ~15,5 ms |
O salto de 125 Hz para 1000 Hz remove aproximadamente cinco milissegundos de espera média. O salto de 1000 Hz para 8000 Hz remove meio milissegundo adicional — e esse meio milissegundo está enterrado em quinze milissegundos de outros atrasos que o mouse não pode encurtar.
Fabricantes anunciam hoje polling 8000 Hz como especificação de destaque, com a clara implicação de que qualquer coisa menor o está segurando. O passo de 500 Hz para 1000 Hz é genuinamente real no papel, mas a consequência na tela é consideravelmente menor que o número dobrado sugere, e perseguir taxas mais altas carrega custos que o material de marketing omite. Aqui está o balanço honesto.
O que a taxa de polling descreve de fato
Seu mouse amostra sua posição e transmite esses dados ao computador numa frequência fixa. A 500 Hz ele reporta a cada dois milissegundos. A 1000 Hz, a cada um milissegundo. A 8000 Hz, a cada 0,125 milissegundo. Uma taxa mais alta significa atualizações de posição mais frequentes e portanto potencialmente menos atraso entre sua mão mover e o cursor responder.
A palavra operativa é potencialmente. Polling é uma etapa numa cadeia de latência, e quase nunca a mais longa.
A conta que todos citam, e o contexto que ela omite
A diferença entre 1000 Hz e 500 Hz é de um milissegundo no intervalo de relatório. Essa é toda a vantagem mensurável na etapa de polling, e como o movimento ocorre em pontos aleatórios dentro de um intervalo, a economia média realizada é mais perto de meio milissegundo.
Coloque isso ao lado das outras etapas da mesma cadeia:
| Etapa | Duração típica |
|---|---|
| Intervalo de polling a 1000 Hz | 1 ms |
| Intervalo de polling a 500 Hz | 2 ms |
| Atualização a 144 Hz | 6,9 ms |
| Atualização a 60 Hz | 16,7 ms |
| Tempo de frame GPU a 60 fps | 16,7 ms |
| Reação visual humana | ~200 ms |
O um milissegundo ganho ao dobrar a taxa de polling é erro de arredondamento perto da atualização de tela e do render de frame, e cerca de duzentas vezes menor que sua própria velocidade de reação. Essa relação proporcional é a razão inteira pela qual a maioria dos jogadores genuinamente não distingue 500 Hz de 1000 Hz em comparação às cegas, independente do que espera sentir.
Quando 1000 Hz e acima ajudam de verdade
Polling mais alto produz valor só quando todo outro elo da cadeia já é rápido. Isso exige especificamente:
- Um display de alto refresh, na faixa 240 Hz a 360 Hz, para a tela poder apresentar atualizações em intervalos sub-quatro-milissegundos.
- Frame rates altos sustentados, significativamente acima de trezentos, para que frames renderizados existam preenchendo essas oportunidades de refresh.
- Baixa latência de sistema em toda parte, incluindo conexão USB direta, processamento de fundo mínimo e nenhum overlay no caminho de entrada.
Dentro dessa janela competitiva estreita e deliberadamente otimizada, um pequeno número de jogadores extrai valor real de 1000 Hz e ocasionalmente de taxas maiores. Fora dela o benefício colapsa em imperceptibilidade, porque o gargalo simplesmente se move para outro lugar e os relatórios adicionais são coalescidos ou amostrados antes de influenciar algo visível.
Os custos de elevar ainda mais
Polling mais alto não é grátis, e acima de 1000 Hz os trade-offs tornam-se materiais:
Carga de processador
Cada relatório atravessa a pilha de entrada do sistema e frequentemente o motor do jogo. A quatro mil a oito mil hertz isso consome tempo de processador mensurável, e em sistemas mais fracos a redução de frame rate resultante pode aumentar a latência total em vez de reduzi-la.
Dreno de bateria
Mouses sem fio consomem substancialmente mais energia em taxas elevadas, e 8000 Hz pode reduzir a autonomia entre cargas drasticamente.
Relatórios que raramente se traduzem em benefício visível
Um mouse 8000 Hz reporta a cada 0,125 milissegundo enquanto um display 360 Hz atualiza a cada 2,8. Mais de vinte relatórios chegam entre frames consecutivos, e a granularidade extra não tem destino.
A taxa de polling não é mira nem DPI
Duas confusões persistentes distorcem decisões de compra:
- DPI é sensibilidade do sensor, descrevendo o deslocamento do cursor por polegada de movimento físico. É inteiramente independente do polling e ajustado para conforto em vez de latência.
- Qualidade de mira deriva de precisão do sensor, superfície, pegada e prática. Um mouse 1000 Hz com sensor exibindo suavização ou angle snapping mirará pior que um 500 Hz com implementação de sensor limpa.
Nenhuma das duas é melhorada pela especificação de polling, e fabricantes lucram com a ambiguidade.
Verifique o que você realmente recebe
A taxa configurada e a entregue podem divergir, mas um navegador não consegue ler a taxa de polling do hardware diretamente: eventos de mouse estão sujeitos a coalescing do navegador, agendamento da main thread e tratamento de input do SO, então o timing baseado em web não pode comprovar o verdadeiro intervalo de relatório USB. Para medição confiável use um utilitário nativo dedicado que leia dados a nível de USB, ou o software do fabricante do mouse. O que uma ferramenta de navegador como nosso testador de mouse pode contribuir é uma verificação de padrões grosseiros — lacunas incomumente longas e consistentes entre atualizações registradas podem sugerir que o caminho da conexão (um hub compartilhado, um header de painel frontal ou um cabo medíocre) está limitando a entrega, algo que vale verificar com ferramenta nativa. Conecte direto a uma porta USB 3.0 traseira da placa mãe e reteste antes de concluir que o mouse está com defeito.

Padrões recomendados
- Mouse gamer com fio: 1000 Hz. Seguro, padrão, sem desvantagem relevante.
- Mouse sem fio: receptores 2,4 GHz modernos suportam 1000 Hz, então escolha por prioridade: 1000 Hz se quiser máxima responsividade, ou 500 Hz se a bateria importar mais — a diferença no feel é imperceptível para a maioria dos usuários, e a economia de bateria a 500 Hz é real.
- Rig competitivo com display de alto refresh e frame rates altos: tente 1000 Hz a 2000 Hz e avalie honestamente se você percebe diferença. Se não, volte e recupere a folga de processador.
- Todos os outros, incluindo toda produtividade: 500 Hz é inteiramente suficiente. A questão não merece mais atenção.
Como o USB lida com relatórios do mouse a nível de protocolo
Dispositivos USB se comunicam com o host através de endpoints, cada um configurado para um tipo de transferência. Mouses usam transferências de interrupção, cujo intervalo de sondagem o controlador host agenda na frequência configurada — o host reserva esses slots de tempo, embora a entrega real ainda possa sofrer jitter sob carga do sistema. A granularidade temporal depende da velocidade USB: um dispositivo Full-Speed (típico para mouses) é agendado em frames de um milissegundo, enquanto um dispositivo High-Speed usa microframes de 125 microssegundos. Um mouse configurado a 1000 Hz portanto recebe um slot de um milissegundo numa conexão Full-Speed; a semântica precisa do intervalo de endpoint difere entre Full-Speed e High-Speed, e o ritmo real de relatório também depende de como o descritor do dispositivo declara seu intervalo.
O pacote de relatório é definido pelo descritor HID do dispositivo. Um relatório padrão contém um byte de estado de botões, um delta X, um delta Y, e opcionalmente roda e dados adicionais. A carga total é pequena — tipicamente oito a dezesseis bytes — o que significa que a largura de banda quase nunca é o gargalo. A restrição é o timing.
A nível de sistema operacional, cada relatório recebido dispara uma interrupção que se propaga pela pilha de drivers USB, o driver de classe HID e o subsistema de entrada. O SO não simplesmente repassa cada relatório ao motor do jogo; processa-o de acordo com seu próprio design.
Uma sutileza adicional é que o agendamento do controlador USB não é perfeitamente determinístico. O controlador gerencia múltiplos dispositivos compartilhando o mesmo barramento, e embora as transferências de interrupção tenham seu slot garantido, outro tráfego pode introduzir jitter. Em um sistema bem configurado é desprezível; em um onde o mouse compartilha controlador com armazenamento externo, a contenção pode produzir atrasos mensuráveis.
Para entender onde a taxa de sondagem se situa na cadeia de latência, ajuda rastrear um movimento do mouse por cada etapa desde a superfície física até a mudança visível do cursor.
Amostragem do sensor. O sensor óptico captura imagens da superfície a uma taxa interna alta — muitas vezes 12.000 a 16.000 fps — e compara quadros consecutivos para calcular movimento. Este processo é interno ao sensor e independente da taxa de sondagem USB.
Processamento do MCU. O microcontrolador recebe o delta, aplica processamento como angle snapping ou suavização, e o monta em um pacote de relatório USB. Adiciona um pequeno atraso, tipicamente abaixo de um milissegundo.
Transferência USB. Esta é a etapa governada pela taxa de sondagem. A 1000Hz, o relatório espera o próximo microframe, que ocorre a cada milissegundo. Em média espera 0,5ms.
Pilha de input do SO. O host processa o relatório através do driver USB, driver HID e subsistema de entrada. Leva de um a três milissegundos.
Processamento do motor do jogo. O jogo recebe o evento, aplica sua lógica de input e o incorpora ao próximo quadro. A 60fps, cada quadro leva 16,7ms.
Apresentação na tela. O quadro viaja ao monitor, que o apresenta segundo seu intervalo de atualização. A 144Hz aparece na tela dentro de 6,9ms.
Somando: sensor (0,25ms) + MCU (0,5ms) + USB a 1000Hz (0,5ms) + SO (2ms) + jogo a 60fps (8,3ms em média) + tela a 144Hz (3,5ms) = aproximadamente 15ms. A etapa de sondagem USB contribui aproximadamente 3% do total. Doblá-la a 500Hz adiciona 0,5ms. Por isso a diferença medida entre 500Hz e 1000Hz é consistentemente inferior a um milissegundo. Estes números são ilustrativos; valores reais dependem do SO, driver, jogo e display específicos.
A implicação não é que a taxa de sondagem seja irrelevante, mas que é o último componente a otimizar. Se seu jogo roda a 60fps, subir para 144fps elimina cerca de 4,9 milissegundos de espera média de frame (16,7ms/2 menos 6,9ms/2) — aproximadamente dez vezes a economia de dobrar a taxa de sondagem. Se seu display roda a 60Hz, o upgrade para 144Hz elimina em média cerca de 4,9 milissegundos (16,7ms/2 menos 6,9ms/2). Os números exatos dependem de você medir espera média, tempo total de frame ou latência de ponta a ponta, então trate-os como ilustrativos em vez de universais.
O unico numero
1000 Hz é genuinamente melhor que 500 Hz por exatamente um milissegundo, melhoria real mas quase sempre invisível. Direcione seu esforço de otimização primeiro à taxa de atualização da tela e ao frame rate sustentado, pois essas etapas contribuem com atrasos uma ordem de magnitude maiores, e só depois considere se a taxa de polling move algo que você perceba. Trate 8000 Hz como conquista de ficha técnica em vez de upgrade sentida até que o resto da cadeia possa consumir essa resolução.