O contador diz 200 e o jogo parece 90. Nada está quebrado, nada congela por um segundo inteiro, mas um confronto nunca é o que o número promete. Essa sensação tem um nome e uma medição, e assim que você aprende a lê-la para de correr atrás do número errado.
Primeiro, a frase honesta. Esta página explica uma medição, não uma correção. O w0a não imprime nenhum número de "FPS ganhos" em lugar nenhum, então se uma mudança ajudou é algo que você lê nas suas próprias capturas de antes e depois, contra o seu próprio ruído entre execuções — e cada número abaixo pode ser recalculado a partir do arquivo que a página Benchmark salva.
O que esses três números são de verdade
Ordene todos os quadros de uma execução do mais lento para o mais rápido.
- FPS médio é a média de todos eles. É o número menos útil da página.
- O 1% low é o pior um por cento desses quadros. Costuma ser mostrado como um valor de FPS, então um "1% low de 70" quer dizer que cada um dos seus piores quadros demorou mais ou menos o que demora um quadro num jogo a 70 FPS.
- O 0,1% low é o pior de cada mil — os eventos raros e profundos.
O tempo de quadro é o mesmo dado em milissegundos, e vale decorar a conta porque é ela que torna concreto o resto desta página: 16,7 ms são 60 FPS, 6,9 ms são 144, 4,2 ms são 240.
Então uma execução com média de 200 e 1% low de 70 é uma execução em que o quadro típico levou uns 5 ms e o pior centésimo levou uns 14 — quase três vezes mais. E a 200 FPS, um por cento dos seus quadros são dois quadros por segundo. Duas vezes por segundo, a imagem fica parada pelo tempo de três quadros. É isso que você está sentindo, e nenhuma média te diz nada sobre isso.
Leia a diferença, não o número
Um 1% low de 70 é excelente numa execução de 90 FPS e alarmante numa de 200 FPS. A leitura útil é a relação entre eles:
| O que você vê | O que isso costuma significar |
|---|---|
| Média e 1% low próximos um do outro | Entrega consistente. É isso que "suave" é, mesmo numa taxa de quadros modesta. |
| 1% low muito abaixo da média | Alguma coisa está interrompendo uma execução que fora isso é saudável — um evento, não uma carga de trabalho. |
| 0,1% low muito abaixo do 1% low | Eventos raros e profundos: um reset do driver, uma tempestade de paginação, uma leitura longa de disco. |
| Tudo baixo junto | Você simplesmente está pedindo mais do que o hardware entrega. Baixe uma configuração. |
A terceira linha é fácil de ler errado. Se o seu 1% low está bom e o seu 0,1% low está péssimo, você não tem um problema de ritmo — você tem um punhado de incidentes específicos, e incidentes dá para achar.
Por que uma cauda ruim é um problema diferente de uma média baixa
Uma média baixa é uma questão de carga de trabalho: a máquina está fazendo tudo o que consegue e não é suficiente. A resposta é uma configuração, uma resolução, ou outro hardware.
Uma cauda ruim é uma questão de evento: a máquina está acompanhando na maior parte do tempo e alguma coisa a interrompe de tempos em tempos. A resposta é achar essa coisa. A lista é curta e cada item deixa um rastro — um driver segurando um núcleo do processador, páginas voltando do disco, a leitura de um asset, uma tarefa em segundo plano, um shader sendo compilado, um reset do driver. Por que os jogos engasgam no Windows 11 percorre essa lista causa por causa, e o que a análise de engasgos procura é a versão automática, que marca cada achado como comprovado, provável, candidato ou não verificado em vez de te entregar uma pontuação de confiança que ela não conquistou.
Existe também um caso intermediário: uma máquina que não está limitada pela GPU na média, mas bate num limite nos momentos mais cheios. Os quadros que ficam para trás são exatamente os quadros em que mais coisa está acontecendo — ou seja, o confronto. Se a sua GPU fica bem abaixo da ocupação total enquanto os lows sofrem, GPU abaixo de 100% é a página de diagnóstico disso.
A disciplina de medição que faz tudo isso valer a pena
Os percentis são mais ruidosos que as médias, porque são calculados a partir de menos quadros. Duas execuções da mesma configuração sem mudança nenhuma não vão produzir o mesmo 1% low, e a diferença entre elas é a menor mudança que você é capaz de detectar.
É por isso que uma captura só é útil ao lado do próprio ruído. A página Benchmark calcula um piso de ruído a partir da variação minuto a minuto de cada captura e o imprime separadamente para a média, para o 1% low e para o 0,1% low — e não vai afirmar uma diferença que caia dentro dele. É a disciplina inteira em um comportamento só: um resultado menor que a sua própria oscilação entre execuções não é um resultado.
A versão prática:
- Mesmo jogo, mesmo mapa ou replay, mesma duração, mesmas configurações dentro do jogo.
- Jogue do mesmo jeito. Uma execução passada olhando para uma parede e uma execução passada em tiroteio não são comparáveis.
- Rode a configuração sem mudança nenhuma pelo menos três vezes antes de mudar qualquer coisa, para conhecer o seu próprio ruído.
- Mude uma coisa. Cinco mudanças e uma medição não te dizem nada sobre qual delas importou — e somar cinco ganhos medidos separadamente é aritmética, não medição.
- Compare os lows. Como ler o benchmark explica para que serve cada número da página.
A aritmética exata, número por número
Isto é o que a página Benchmark faz com uma captura, na ordem em que faz.
| Passo | A regra | Por que ela existe |
|---|---|---|
| Quais quadros contam | Só os quadros desenhados enquanto o jogo era a janela em primeiro plano. Depois que o jogo volta para o primeiro plano, o primeiro segundo fica de fora; antes de uma perda de foco detectada, os últimos 0,2 segundo ficam de fora. O tempo deixado de fora é informado junto com a execução. | Uma captura começa e para a partir da própria janela do w0a, então as bordas dela são o jogo em segundo plano. Numa captura gravada, 94 dos 185 quadros por trás do 1% low eram essas bordas. O valor de um segundo é escolhido, não medido. |
| Pausas | Um intervalo de quadro maior que 200 ms é excluído da média e de todos os percentis, e contado à parte. | Acima de 200 ms é uma tela de carregamento, um alt-tab ou uma pausa do driver, não renderização. Entrando na média, ele enterraria todos os quadros de verdade. |
| FPS médio | Os quadros contados divididos pelo tempo que levaram: quadros × 1000 ÷ total de milissegundos. | |
| 1% low | Ordene os tempos de quadro contados. Pegue o 1% mais lento deles, arredondado para cima e nunca menos de um quadro, tire a média desses tempos de quadro e transforme o resultado em FPS: 1000 ÷ essa média. | A outra definição comum, a taxa de quadros no tempo de quadro do percentil 99, foi rejeitada de propósito: com exatamente 1% dos quadros engasgando, ela cai na fronteira e informa quase o mesmo número que a média. |
| 0,1% low | O mesmo, com o 0,1% mais lento. | |
| Tempo de quadro dos percentis 99 e 99,9 | Informado à parte, em milissegundos. | Para leitores e ferramentas que usam a definição por percentil. |
| Curta demais para ler | Abaixo de 900 quadros não há quadros suficientes para o percentil significar alguma coisa. | |
| Contagem de engasgos | Um quadro é um engasgo quando é mais longo que o dobro da mediana dos três segundos ao redor e também que essa mediana mais 8 ms, até um segundo. | Três segundos em vez de um número fixo de quadros, para que a regra signifique a mesma coisa a 60 FPS e a 300. O termo de 8 ms impede que a oscilação comum em taxas de quadros altas conte como engasgo. Quadros entre 200 ms e um segundo ficam fora dos percentis, mas entram aqui: um soluço de 250 ms de compilação de shaders é exatamente o que esta contagem existe para pegar. |
| Piso de ruído | A captura é cortada em blocos de 60 segundos. Cada lado de uma comparação precisa de pelo menos dois blocos inteiros, senão a página diz "não comparável" em vez de colorir um número. O piso é um intervalo de 95% a partir da variação de bloco a bloco dos dois lados (método de Welch), como porcentagem do valor "antes". Só contam blocos completos sem eventos perdidos, e nunca se produz um piso igual a zero. | Uma diferença dentro da sua própria oscilação de bloco a bloco não é um resultado. |
| Séries pareadas | Quando você roda uma série A/B, uma mudança só é informada se um teste exato de postos sinalizados e um intervalo bootstrap de 95% da mediana das diferenças (10.000 reamostragens) excluírem o zero, e a mediana for pelo menos o menor efeito que um piloto de 10 execuções mostrou que a configuração consegue detectar. A série precisa de pelo menos 6 pares — com 5, o menor valor-p possível é 0,0625 — e sugere 8, rodados na ordem ABBA. | Um único par antes e depois não separa uma mudança de uma GPU aquecida ou de um ponto de surgimento diferente. |
Confira você mesmo: recalcule a partir do CSV
Salvar CSV na página Benchmark escreve uma tabela com as colunas side,kind,name,value. As linhas com kind = metric são os números do resumo; as linhas com kind = frame são os intervalos de quadro, um por linha, com o tempo de quadro em milissegundos em value. As linhas de quadro guardam a série inteira, pausas incluídas, justamente para você aplicar a regra de 200 ms por conta própria e chegar aos mesmos números.
Duas coisas antes de começar:
- Os números no arquivo sempre usam ponto como separador decimal, seja qual for a região do seu Windows. Nas configurações regionais do português o separador decimal é a vírgula, então avise a sua planilha disso ao importar, senão
6.94chega como texto. - Os nomes das colunas são identificadores fixos em inglês. Eles são feitos para scripts e são os mesmos em todos os idiomas.
Na planilha: filtre um side e kind = frame, remova as linhas acima de 200, ordene value do maior para o menor, tire a média das primeiras N linhas, em que N é o número de linhas dividido por 100 e arredondado para cima, e divida 1000 por essa média. O resultado deve ser igual a low_1pct_fps daquele lado.
No PowerShell (troque before por after para o outro lado):
$ms = Import-Csv .\capture.csv |
Where-Object { $_.kind -eq 'frame' -and $_.side -eq 'before' } |
ForEach-Object { [double]::Parse($_.value, [Globalization.CultureInfo]::InvariantCulture) } |
Where-Object { $_ -le 200 } |
Sort-Object
$take = [Math]::Max(1, [Math]::Ceiling($ms.Count * 0.01))
1000 / ($ms | Select-Object -Last $take | Measure-Object -Average).Average
Para o 0,1% low, use 0.001 em vez de 0.01. Duas verificações rápidas de consistência no mesmo arquivo: o número de linhas de quadro com valor até 200 é igual à métrica frames, e o número acima de 200 é igual a excluded_over_stall_ms.
Duas coisas que arruínam um percentil em silêncio
Geração de quadros. Quadros inseridos não carregam estado novo do jogo. Um 1% low derivado da contagem de quadros continua produzindo um número, mas ele parou de descrever a responsividade — que é o único motivo pelo qual você estava olhando para ele. Desligue a geração enquanto mede. Isto é uma questão de definição, não uma afirmação de que a geração de quadros causa engasgos.
Telas de carregamento e pausas. Uma pausa de carregamento de três segundos é um único "intervalo de quadro" de três mil milissegundos e, se ficar nos dados, vira o seu 0,1% low e enterra tudo o que era real. Intervalos desse tamanho são excluídos dos percentis justamente por isso e relatados à parte, para que nenhum número seja construído calado em cima de um deles.
O que não mexe no 1% low
Isto merece ser dito com todas as letras, porque é fácil confundir as duas coisas: recursos de latência e estabilidade de percentis são afirmações diferentes. Os modos de baixa latência dos fabricantes reduzem a profundidade da fila de renderização, e essa redução foi medida. Não existe medição publicada mostrando que eles melhoram os percentis de tempo de quadro. As duas coisas podem valer a pena; elas não são a mesma coisa, e uma página que apresenta uma como se fosse a outra está te vendendo alguma coisa. Instalação limpa para 1% lows estáveis percorre as evidências publicadas com fontes, e a latência de entrada que nenhum software corrige é a contabilidade honesta do que o trabalho de latência alcança e do que não alcança.
A mesma cautela vale para as listas de registro que prometem lows melhores. Valores de gerenciamento de memória do kernel e sobrescritas de resolução do timer são recusados de saída aqui, não por serem exóticos, mas porque ninguém publicou uma medição deles que sobreviva ao contato com um método.
O que a página Benchmark não imprime
- Nenhum número de "FPS ganhos", para nenhuma configuração, em lugar nenhum do w0a. Um ganho é o que as suas duas capturas mostram, ou nada.
- Nenhuma causa, só o momento. Quando um engasgo coincide com outra coisa que aconteceu, o cartão diz que os dois caíram na mesma janela. Ele não diz que um causou o outro.
- Nenhuma diferença dentro do piso de ruído é mostrada como mudança, em nenhuma das direções.
Se os seus lows estão ruins e você quer as causas em vez dos números, por que os jogos engasgam no Windows 11 é a lista, e o que a análise de engasgos procura é o que o w0a verifica automaticamente. Para o CS2 especificamente, FPS baixo e engasgos no CS2 aplica tudo isso a um jogo.
Relacionados
- Por que os jogos engasgam no Windows 11 (e como achar a causa real)
- GPU abaixo de 100%: como saber se o gargalo é da CPU
- Como ler o benchmark
- Como diminuir o input lag no PC: o que o software encurta e o que não
- Engasgos de compilação de shaders
- FPS baixo e engasgos no CS2
Joga CS2? Quais opções de inicialização ainda fazem alguma coisa e onde estão de verdade os quadros no menu de vídeo: Como aumentar o FPS no CS2 e por que ele fica travando: um checklist medido
Esta página ajudou?
O que faltou, ou o que não funcionou? Lemos cada uma dessas respostas.
Se esta página não resolveu, escreva para nós — diga qual artigo você leu, e nós vamos corrigi-lo.