O que ele mede
Tempos de quadro do jogo que você está realmente jogando, lidos da própria pilha gráfica em vez de um overlay enganchado no jogo. Inicie a captura, jogue normalmente, pare.
Jogar o seu próprio jogo faz diferença. Uma cena sintética diz como a máquina lida com aquela cena; ela não consegue dizer se o seu jogo engasga no único lugar em que ele sempre engasga.
Os números
| Número | O que ele diz |
|---|---|
| FPS médio | o dado menos útil daqui. Duas máquinas com a mesma média podem parecer completamente diferentes. |
| 1% low | o 1% pior dos quadros. É isso que se sente como engasgo — uma média alta com um 1% low ruim é o clássico "muito fps e mesmo assim parece ruim". |
| Tempo de quadro | os mesmos dados em milissegundos. 16,7 ms são 60 FPS, 6,9 ms são 144. |
Leia os lows, não a média. Ir de 200 para 210 de média não muda nada que você consiga sentir. Ir de 90 para 140 no 1% low muda tudo.
Comparar duas execuções com honestidade
- Mesmo jogo, mesmo mapa, mesmas configurações, mesma duração.
- Mude uma coisa entre as execuções. Mude três e a comparação não diz nada sobre qual delas importou.
- Jogue do mesmo jeito. Uma execução olhando para uma parede e uma execução no meio do tiroteio não são comparáveis.
O que fica de fora
Os quadros que o jogo desenha quando não está em primeiro plano não são contados: os segundos entre iniciar a captura e passar para o jogo, os segundos depois de voltar para pará-la, qualquer alt-tab no meio e o primeiro segundo depois que o jogo volta ao primeiro plano. Um jogo em segundo plano costuma desenhar uma fração do seu ritmo normal, e só esses quadros já podem definir o 1% low. O resultado diz quantos segundos ficaram de fora, e uma captura salva por um w0a mais antigo, que ainda os contava, não é julgada contra uma mais recente.
Por que os números mudam entre execuções
Eles sempre mudam. Temperaturas, carga em segundo plano, por onde você andou, o que os outros jogadores fizeram. Alguns por cento entre duas execuções é normal e não é prova de nada. Se uma mudança é real, ela aparece repetidas vezes e aparece nos lows.
Depois de uma atualização do driver ou do jogo
Um par feito dos dois lados de uma atualização do jogo não é julgado: a página mostra as duas versões e deixa a diferença sem cor, como já faz com uma troca de driver. Um patch muda o que o próprio jogo faz, então nenhuma diferença através de uma atualização pode ser atribuída a uma configuração. O w0a lê a versão dos próprios arquivos do Counter-Strike 2; em outros jogos só o driver é comparado.
A primeira partida depois de uma atualização do driver ou do jogo pode compilar shaders que o cache já não tem. Quando a primeira execução após a atualização mais recente saiu pior que a seguinte nas mesmas versões, por mais que o ruído próprio das duas execuções, uma nota abaixo dos resultados diz isso. Se a compilação de shaders foi a causa não é medido; a nota só diz que as duas coisas se encaixam. Se as duas execuções não diferem, não há nota. Então, depois de uma atualização, jogue uma partida antes de medir e compare as configurações a partir da segunda execução.
Tirar a dúvida com uma série A/B
Uma execução de cada lado não consegue separar uma mudança pequena dessa variação. Uma série A/B repete a comparação até conseguir. Você decide o que são A e B (por exemplo A: motores desligados, B: ligados); o w0a não muda nenhuma configuração sozinho.
- Primeiro o piloto. Clique em Iniciar piloto e meça a mesma cena dez vezes sem mudar nada. O piloto mede quanto o seu 1% low varia sozinho de uma execução para outra e, a partir disso, a menor diferença que uma série consegue ver. Ele vale para o mesmo jogo no mesmo hardware.
- Depois a série. Clique em Iniciar série A/B. Antes de cada captura a página diz qual lado medir, na ordem A B B A, repetida. Mude para essa configuração, jogue a mesma cena e pare a captura. Cada B é comparado com o A medido ao lado dele, então o aquecimento lento da máquina ao longo da noite se anula.
- Cada execução é a mesma cena e dura pelo menos 100 segundos. Apague a primeira execução depois de abrir o jogo: os caches ainda estão aquecendo.
- O veredito sai só do 1% low, quando há pelo menos seis pares utilizáveis (oito é melhor); as outras linhas são informativas. Três respostas precisam concordar: um teste de postos com sinal, um intervalo de 95% da mediana da diferença que deixe o zero de fora e uma diferença pelo menos do tamanho da menor que a série consegue ver. Sem piloto, ou sem dez execuções A na série para fazer o papel dele, a diferença é mostrada mas não é decidida.
- "Dentro do ruído" também é um resultado: a mudança não mexeu nos lows mais do que eles se mexem sozinhos.
Um par que o cartão de comparação não julgaria sozinho (uma execução curta, eventos perdidos, um motor mudando de estado, outro hardware) não é contado, e a série diz quantos ficaram de fora. Clique em Encerrar série quando terminar; o resultado fica na página.
Quanto tempo o jogo esperou por um processador
Abaixo da lista de intervalos longos entre quadros, um cartão lê por uma janela curta os próprios registros do agendador do kernel, depois que o jogo já está apresentando quadros há algum tempo: quanto as threads do jogo esperaram entre ficar prontas para rodar e receber um processador, e quais outros programas ocuparam o processador nesse meio-tempo. Precisa de direitos de administrador, e uma janela em que o kernel perdeu eventos não mostra número nenhum em vez de um errado. Com duas execuções selecionadas, diz se a espera se moveu mais do que a própria dispersão das janelas.
O mesmo cartão mostra o processador em que a thread mais ocupada do jogo (tomada como a thread principal) mais rodou e o tempo de chamadas de procedimento adiadas (DPC) medido onde ela rodou, ao lado do processador médio. Uma série acrescenta uma linha: se, nas execuções de uma mesma configuração (o piloto ou o lado A), esse tempo de DPC e os engasgos subiram e desceram juntos. Descreve só coincidência no tempo; o que causa o quê não é medido.
A rede durante a captura
Durante uma captura, enquanto o jogo está aberto, o w0a envia dez vezes por segundo uma pequena sonda para 1.1.1.1, o endereço que o cartão Conexão ao vivo da página Conexão usa. Não é o servidor do seu jogo: mede a sua própria conexão (o roteador, o Wi-Fi, a rede do seu provedor), a parte que o tráfego de qualquer jogo atravessa primeiro. Uma sonda sem resposta em um segundo conta como perdida. Se a rede nunca responde ao ping, o w0a passa para handshakes TCP na porta 443 do mesmo endereço, cinco por segundo, e os pings de antes da troca saem do registro: foram filtrados, não perdidos. Enquanto nenhum jogo está aberto nada é enviado, e fora de uma captura o registro nem chega a rodar.
Com duas execuções selecionadas, o cartão de comparação ganha uma linha Rede: ida e volta p95, perda e picos de cada execução lado a lado, sem cor, porque o cartão compara quadros, não redes. O resultado copiado leva os mesmos três números. Se uma execução foi medida com handshakes, a linha diz isso; um handshake mede um pouco mais alto que um ping. A dica da linha acrescenta, para cada execução, p50, p99, a ida e volta mais longa e o limite de picos.
Um pico é uma sequência de sondas acima do limite de picos e conta uma vez só, dure o quanto durar. O limite é o quartil superior mais três amplitudes interquartis e nunca fica menos de 10 ms acima da mediana, para que a oscilação comum de uma conexão tranquila não conte. Ele precisa de pelo menos 20 sondas respondidas, assim como o p95; o p99 precisa de 100. Abaixo disso aparece um traço em vez de um número chutado. O registro para depois de uma hora de sondagem, ou antes, se o caminho pedir menos pacotes (ICMP source quench) ou a sonda falhar, e a dica diz o motivo. Uma execução salva por um w0a mais antigo não tem registro de rede.
Na lista de intervalos longos entre quadros, cada intervalo diz quantas sondas estavam no ar na mesma janela, quantas ficaram sem resposta e a ida e volta mais longa. Uma frase acima da lista conta os intervalos que caem na mesma janela que uma sonda sem resposta ou uma acima do limite de picos. É só isso que ela diz: as duas coisas aconteceram ao mesmo tempo. Se uma atrasou a outra não é medido.
Execuções salvas alimentam a análise de engasgos
As execuções que você salva servem de evidência para a análise de engasgos: quadros medidos claramente mais lentos que os quadros ao redor aparecem lá como um achado próprio, ao lado das causas possíveis. Uma execução salva do jogo que engasga é a evidência mais direta que você pode entregar a ela.
Relacionados
Das cerca de doze etapas entre um clique e um pixel que muda, três são do software; o resto é do firmware, da tela e do jogo: Como diminuir o input lag no PC: o que o software encurta e o que não
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.