Como pesquisamos o Windows

Na seção «Pesquisas do Windows» verificamos afirmações técnicas específicas. Em cada artigo explicamos o que foi verificado, em quais condições e para quais sistemas o resultado se aplica.

A existência de um parâmetro, sua influência no funcionamento do sistema e o ganho de desempenho exigem evidências separadas.

O que é considerado evidência

Usamos vários tipos independentes de evidências:

1. Documentação primária. Documentos oficiais da Microsoft, especificações e documentação do fabricante do hardware ou do aplicativo.
2. Observação estática. Indícios de implementação em uma versão específica do componente. Essa observação é limitada à build estudada e, por si só, não prova a execução do caminho durante o funcionamento.
3. Observação dinâmica. Eventos do sistema, estado dos componentes e rastreamentos obtidos no cenário descrito.
4. Medição controlada. Comparação de uma métrica escolhida previamente com uma alteração conhecida e um retorno de estado verificado.
5. Reprodução. Repetição do resultado em uma execução independente, em outro sistema ou build.

Os métodos internos de automação da coleta e do processamento não são publicados. Isso não altera a exigência de divulgar a questão verificada, a configuração, as métricas, o número de execuções e as limitações.

Status dos materiais

Status	Significado
Documentado	Comportamento descrito em fonte pública primária.
Observado	Evento ou estado detectado no ambiente indicado.
Medido	Diferença numérica obtida pela metodologia descrita.
Reproduzido	Resultado repetido de forma independente.
Não reproduzido	Efeito declarado não detectado nas condições indicadas.
Dados insuficientes	A metodologia ou a amostra não permitem concluir.

O status se refere a uma afirmação individual, e não automaticamente ao artigo inteiro. Não usamos percentual de confiança arbitrário e não chamamos um resultado de universalmente comprovado sem verificação em outros sistemas.

Como o experimento é construído

Antes da medição, são fixados:

• uma questão verificável;
• a variável independente;
• a métrica principal e sua unidade;
• Windows build, hardware relevante, drivers e versões dos aplicativos;
• um limiar praticamente significativo;
• a forma de retornar ao estado inicial.

Comparamos os estados inicial e alterado, depois verificamos o retorno. Quando possível, alternamos a ordem das execuções pareadas. Controlamos o aquecimento, a alimentação, as temperaturas e a carga em segundo plano; se isso não for possível, indicamos a limitação.

Intervalos separados de um mesmo rastreamento mostram mudanças ao longo do tempo, mas não são considerados repetições independentes. O resultado de uma máquina virtual não pode ser transferido automaticamente para um computador físico. Para concluir sobre todos os dispositivos de uma classe, não basta verificar um único dispositivo.

Bancada física click-to-photon

Para pesquisas de jogos usamos uma bancada de hardware própria. Ela mede fisicamente a latência total desde o sinal elétrico do botão do mouse até a mudança de brilho do pixel na tela, sem estimativa por software desse intervalo.

O trajeto principal é organizado assim:

1. Um fio é soldado à linha do botão esquerdo do Logitech G PRO X SUPERLIGHT de primeira geração. A borda elétrica dispara o timer do Arduino Uno.
2. O mesmo clique passa pelo controlador do mouse, USB, Windows, o jogo, a fila de renderização, a GPU e o monitor.
3. Um fotossensor fixado na tela para o timer quando o brilho da área de teste cruza um limiar escolhido previamente.
4. Um resultado contém o intervalo completo click-to-photon em milissegundos.

Esse início inclui intencionalmente o processamento pelo controlador do mouse e seu click debounce, mas não inclui o curso mecânico do botão até o fechamento do contato. Não subtraímos a latência do mouse do valor final. Na metodologia atual de medições independentes do RTINGS para o G PRO X SUPERLIGHT são indicados 2.5 ms por cabo e 3.1 ms via receiver. A baixa click latency medida torna esse mouse uma parte estável adequada da bancada, mas não transforma o resultado na latência pura do Windows ou do jogo.

Um microcontrolador HID separado no formato Arduino Nano pode enviar cliques ao Windows automaticamente. Esse caminho é usado quando é preciso eliminar as diferenças do pressionamento manual e repetir o sinal de entrada em um ritmo controlado. Ele responde a outra pergunta e não é misturado com as séries que começam na linha física do botão do mouse.

No CS2 é usado o mapa workshop BXLAT, onde o clique provoca uma mudança previsível na área de teste. Um cenário visual análogo é aplicado no Valorant. A posição do fotossensor, a resolução, a taxa do monitor, o limite de FPS, o modo display scaling, o presentation mode e o limiar de luz são fixados para toda a série comparada.

O padrão atual exige pelo menos 300 cliques válidos por estado. Nas novas séries mantemos a média, o desvio padrão, o mínimo, o máximo, os percentis, incluindo P90, e a distribuição para a construção de gráficos. Disparos errôneos, excedentes de tempo de espera e valores fora da faixa estabelecida previamente são marcados e considerados na verificação da adequação da série.

As pesquisas nessa bancada são realizadas há vários anos, e o formato de armazenamento mudou nesse período. Na tabela pública de medições históricas há séries de 300 cliques e séries mais antigas de 100. Para parte dos testes antigos foram preservados apenas AVG, STDDEV, MIN e MAX; os P90 ou gráficos ausentes não são reconstruídos a partir dos agregados e são marcados diretamente como indisponíveis. As novas séries serão publicadas com estatísticas ampliadas.

O que é publicado no resultado

O artigo contém:

• resposta curta;
• a afirmação verificável;
• o escopo da pesquisa;
• a metodologia e o número de rastreamentos independentes;
• os valores das métricas e a dispersão;
• conclusões confirmadas e não confirmadas;
• métricas excluídas ou contaminadas;
• limitações;
• recomendação prática sem garantia de resultado idêntico;
• confirmação do retorno do estado;
• fontes públicas primárias e a data da verificação.

Se o resultado não confirmou uma recomendação popular ou uma função do BoosterX, ele ainda assim pode ser publicado. A presença de uma configuração no produto não é prova de sua eficácia.

Como verificar por conta própria

Uma parte significativa das observações dinâmicas das nossas pesquisas é reproduzível com ferramentas públicas: Sysinternals ProcMon para rastreamentos do sistema e WinDbg com símbolos públicos da Microsoft. O caminho básico de verificação é assim.

1. Leitura do parâmetro — ProcMon. Abra Options → Configure Symbols e indique o servidor público de símbolos da Microsoft, para que os stacks mostrem nomes de módulos e funções. Depois adicione um filtro Path contains — por exemplo SystemResponsiveness de HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Pelos eventos de leitura dá para ver se o valor é lido, quando e por qual processo.
2. Quem lê — o stack de chamada. Um clique duplo no evento abre suas propriedades; na aba Stack é mostrada a cadeia de módulos — é justamente o «leitor» do parâmetro. Por exemplo, a cadeia de user32.dll para win32kfull.sys significa que o subsistema Win32k é responsável pelo valor.
3. Comportamento em runtime — WinDbg. Com os símbolos públicos da Microsoft é possível definir um breakpoint em funções do stack e ver como o valor lido é aplicado.
4. Testes sintéticos. Altere o valor e meça o comportamento observado. Por exemplo, os intervalos de entrada do mouse são medidos por testadores públicos de taxa de polling.

Fronteira honesta. A análise estática de binários e os rastreamentos completos não são publicados nos artigos. O caminho acima reproduz a parte dinâmica das nossas observações, mas não substitui a análise estática — suas conclusões se referem à build estudada.

Limites da medição de latência

A latência por software, a profundidade da fila, o período do motor de áudio, o tempo de agendamento da thread e a latência física total descrevem grandezas diferentes. Por exemplo, a fila do XAudio2 não determina todo o intervalo desde a ação do usuário até o som sair do alto-falante. Para medi-lo é necessário equipamento externo.

De forma análoga, o tempo de CPU de um processo individual não é igual à influência total sobre FPS, frametime, consumo de energia ou responsividade do sistema. Tais conclusões são verificadas por métricas separadas.

Proteção de dados

Os ETL, PML, logs de eventos, dumps de memória e exportações de registro originais não são publicados por padrão. Os rastreamentos do sistema podem conter nomes de usuários, caminhos, linhas de comando, endereços de rede e outros dados sensíveis. A Microsoft alerta especificamente sobre isso nos termos do Sysinternals.

No site são publicadas apenas tabelas selecionadas manualmente e anonimizadas. Removemos identificadores únicos de dispositivos e instalações, caminhos de usuário, dados de contas, identificadores de rede, dados de login e informações sobre processos não relacionados à pesquisa.

Correção de conclusões

Windows, drivers e aplicativos mudam. Cada artigo recebe a data da última verificação e a área de aplicabilidade. Se uma nova medição contradiz uma conclusão antiga, o artigo é atualizado com a explicação do motivo. O resultado antigo não é transferido automaticamente para uma nova build.

Independência e marcas registradas

As pesquisas são publicadas pela equipe do BoosterX e podem se referir a funções do produto. Esse possível conflito de interesses é considerado pelo fato de que a metodologia, os valores medidos, as limitações e os resultados negativos são separados da recomendação de produto.

O BoosterX Wiki é uma publicação independente e não é associado, autorizado, patrocinado ou aprovado pela Microsoft Corporation. Os nomes Microsoft e Windows são usados apenas para descrever com precisão o objeto da pesquisa. Mais detalhes: Microsoft Trademark and Brand Guidelines.

Histórico de alterações

• 2026-08-24: metodologia publicada.
• 2026-09-20: adicionada a seção «Como verificar por conta própria»; corrigido o link para a fonte dos dados do mouse.

Última verificação da metodologia: 2026-09-20.