Como investigamos o Windows

Na secção «Investigação do Windows» verificamos afirmações técnicas concretas. Em cada artigo explicamos o que foi verificado, em que condições e a que sistemas se aplica o resultado.

A existência de um parâmetro, o seu impacto no funcionamento do sistema e o ganho de desempenho exigem provas separadas.

O que é considerado prova

Utilizamos vários tipos independentes de evidência:

1. Documentação primária. Documentos oficiais da Microsoft, especificações e documentação do fabricante do equipamento ou da aplicação.
2. Observação estática. Indícios de implementação numa versão concreta do componente. Essa observação está limitada à compilação 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 rastreios obtidos no cenário descrito.
4. Medição controlada. Comparação de uma métrica previamente escolhida com uma alteração conhecida e um retorno do estado verificado.
5. Reprodução. Repetição do resultado numa execução independente, noutro sistema ou compilação.

Os métodos internos de automatização da recolha e do tratamento 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.

Estados dos materiais

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

O estado refere-se a uma afirmação isolada e não automaticamente a todo o artigo. Não utilizamos uma percentagem de confiança arbitrária e não declaramos um resultado universalmente provado sem verificação noutros sistemas.

Como se constrói o experimento

Antes da medição, fixam-se:

• uma questão a verificar;
• a variável independente;
• a métrica principal e a sua unidade;
• a compilação do Windows, o equipamento relevante, os controladores e as versões das aplicações;
• um limiar praticamente significativo;
• o modo de reposição do estado inicial.

Comparamos o estado inicial e o estado alterado e, em seguida, verificamos o retorno. Sempre que possível, alternamos a ordem das execuções emparelhadas. 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 rastreio mostram alterações ao longo do tempo, mas não são considerados repetições independentes. O resultado de uma máquina virtual não pode ser automaticamente transferido 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 os estudos de jogos utilizamos uma bancada de hardware própria. Esta mede fisicamente a latência total desde o sinal elétrico do botão do rato até à alteração do brilho do pixel no ecrã, sem avaliação por software desse intervalo.

O percurso principal está organizado assim:

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

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

Um microcontrolador HID separado no formato Arduino Nano pode enviar cliques para o Windows automaticamente. Este percurso é utilizado quando é necessário eliminar as diferenças do pressionamento manual e repetir o sinal de entrada a um ritmo controlado. Responde a outra questão e não se mistura com as séries que começam na linha física do botão do rato.

No CS2 utiliza-se o mapa workshop BXLAT, onde o clique provoca uma alteração previsível da área de teste. Um cenário visual semelhante é aplicado no Valorant. A posição do fotossensor, a resolução, a frequência 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 guardamos a média, o desvio padrão, o mínimo, o máximo, os percentis, incluindo o P90, e a distribuição para construir gráficos. Os disparos errados, as ultrapassagens do tempo de espera e os valores fora do intervalo previamente estabelecido são assinalados e tidos em conta na verificação da adequação da série.

Os estudos nesta bancada decorrem há vários anos e o formato de armazenamento mudou entretanto. 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 conservam-se apenas AVG, STDDEV, MIN e MAX; os P90 ou gráficos em falta não são reconstruídos a partir dos agregados e são assinalados diretamente como indisponíveis. As novas séries serão publicadas com estatística alargada.

O que é publicado no resultado

O artigo contém:

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

Se o resultado não confirmou uma recomendação popular ou uma função do BoosterX, ainda assim pode ser publicado. A existência de uma definição no produto não é prova da sua eficácia.

Como verificar por conta própria

Uma parte significativa das observações dinâmicas dos nossos estudos é reproduzível com ferramentas públicas: Sysinternals ProcMon para rastreios do sistema e WinDbg com símbolos públicos da Microsoft. O percurso básico de verificação é o seguinte.

1. Leitura do parâmetro — ProcMon. Abra Options → Configure Symbols e indique o servidor público de símbolos da Microsoft, para que as pilhas mostrem os nomes dos módulos e das funções. Depois adicione um filtro Path contains — por exemplo SystemResponsiveness de HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Pelos eventos de leitura vê-se se o valor é lido, quando e por que processo.
2. Quem lê — a pilha de chamadas. Um duplo clique no evento abre as suas propriedades; no separador Stack mostra-se a cadeia de módulos — é precisamente o «leitor» do parâmetro. Por exemplo, uma cadeia de user32.dll para win32kfull.sys significa que o valor é da responsabilidade do subsistema Win32k.
3. Comportamento em runtime — WinDbg. Com os símbolos públicos da Microsoft é possível colocar um ponto de interrupção numa função da pilha 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 rato são medidos por testadores públicos de frequência de interrogação.

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

Limites da medição da latência

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

De forma análoga, o tempo de CPU de um processo isolado não é igual ao impacto global nos FPS, no frametime, no consumo de energia ou na capacidade de resposta do sistema. Tais conclusões são verificadas com métricas separadas.

Proteção de dados

Os ETL, PML, registos de eventos, despejos de memória e exportações do registo originais não são publicados por predefinição. Os rastreios do sistema podem conter nomes de utilizadores, caminhos, linhas de comando, endereços de rede e outros dados sensíveis. A Microsoft avisa especificamente sobre isso nos termos do Sysinternals.

No site são colocadas apenas tabelas selecionadas manualmente e anonimizadas. Removemos identificadores únicos de dispositivos e instalações, caminhos de utilizador, dados de contas, identificadores de rede, dados de início de sessão e informações sobre processos não relacionados com o estudo.

Correção das conclusões

O Windows, os controladores e as aplicações mudam. Cada artigo recebe uma data da última verificação e um âmbito 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 compilação.

Independência e marcas comerciais

Os estudos são publicados pela equipa do BoosterX e podem referir-se a funções do produto. Este possível conflito de interesses é tido em conta ao separar a metodologia, os valores medidos, as limitações e os resultados negativos da recomendação de produto.

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

Histórico de alterações

• 2026-08-24: metodologia publicada.
• 2026-09-20: adicionada a secção «Como verificar por conta própria»; corrigida a ligação à fonte de dados do rato.

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