Hoge gemiddelde FPS maar slechte 1% lows: wat dat betekent

De teller zegt 200 en de game voelt als 90. Er is niets stuk, er bevriest niets een hele seconde lang, maar een vuurgevecht voelt nooit zoals het getal belooft. Die ervaring heeft een naam en een meting, en zodra je die kunt lezen stop je met het najagen van het verkeerde getal.

Eerst de eerlijke zin. Deze pagina legt een meting uit, geen oplossing. w0a toont nergens een getal voor "gewonnen FPS", dus of een wijziging heeft geholpen, lees je af aan je eigen opnames van ervoor en erna, tegen je eigen ruis van run tot run — en elk getal hieronder kun je opnieuw berekenen uit het bestand dat de pagina Benchmark opslaat.

Wat die drie getallen werkelijk zijn

Sorteer elk frame uit een run van traagst naar snelst.

• Gemiddelde FPS is het rekenkundig gemiddelde van allemaal. Het is het minst bruikbare getal op de pagina.
• De 1% low is de slechtste procent van die frames. Hij wordt meestal als FPS-getal afgedrukt, dus een "1% low van 70" betekent dat je slechtste frames elk ongeveer even lang duurden als een frame in een game van 70 FPS.
• De 0,1% low is de slechtste op duizend — de zeldzame, diepe voorvallen.

Frametijd is dezelfde informatie in milliseconden, en het rekenwerk is het onthouden waard omdat het de rest van deze pagina concreet maakt: 16,7 ms is 60 FPS, 6,9 ms is 144, 4,2 ms is 240.

Een run met een gemiddelde van 200 en een 1% low van 70 is dus een run waarin het typische frame ongeveer 5 ms duurde en het slechtste honderdste ongeveer 14 — bijna drie keer zo lang. En bij 200 FPS is één procent van je frames twee frames per seconde. Twee keer per seconde staat het beeld stil voor de duur van drie frames. Dat is wat je voelt, en geen enkel gemiddelde vertelt je erover.

Lees het verschil, niet het getal

Een 1% low van 70 is uitstekend in een run van 90 FPS en alarmerend in een run van 200. Wat je moet lezen is de verhouding:

Die derde regel lees je makkelijk verkeerd. Is je 1% low in orde en je 0,1% low verschrikkelijk, dan heb je geen probleem met het frametempo — je hebt een handvol specifieke voorvallen, en voorvallen zijn te vinden.

Waarom een slechte staart een ander probleem is dan een laag gemiddelde

Een laag gemiddelde is een vraag over de werklast: de machine doet zoveel als hij kan en dat is niet genoeg. Het antwoord is een instelling, een resolutie, of andere hardware.

Een slechte staart is een vraag over een voorval: de machine houdt het grotendeels bij en iets legt hem periodiek stil. Het antwoord is dat ding vinden. De lijst is kort en elk punt laat een spoor na — een stuurprogramma dat een processorkern vasthoudt, pagina's die van schijf terugkomen, het lezen van een asset, een achtergrondtaak, een shader die wordt gecompileerd, een driverreset. Waarom games stotteren op Windows 11 werkt die lijst oorzaak voor oorzaak af, en wat de stotterscan zoekt is de geautomatiseerde versie, die elke bevinding aanmerkt als bewezen, waarschijnlijk, kandidaat of niet gecontroleerd in plaats van je een betrouwbaarheidsscore te geven die hij niet heeft verdiend.

Er is ook een tussengeval: een machine die gemiddeld niet door de GPU wordt begrensd maar op de drukste momenten wel tegen een limiet loopt. De frames die achterblijven zijn precies de frames waarin het meeste gebeurt — oftewel het vuurgevecht. Zit je GPU ver onder volledige bezetting terwijl de lows eronder lijden, dan is GPU niet op 100% daarvoor de diagnosepagina.

De meetdiscipline die dit alles de moeite waard maakt

Percentielen zijn ruiziger dan gemiddelden, omdat ze uit minder frames worden berekend. Twee runs van dezelfde ongewijzigde configuratie leveren niet dezelfde 1% low op, en het verschil daartussen is de kleinste verandering die je überhaupt kunt waarnemen.

Daarom is een opname alleen bruikbaar naast zijn eigen ruis. De pagina Benchmark berekent een meetruis uit de spreiding van minuut tot minuut binnen elke opname en drukt die apart af voor het gemiddelde, de 1% low en de 0,1% low — en hij claimt geen verschil dat daarbinnen valt. Dat is de hele discipline in één gedrag: een resultaat dat kleiner is dan je eigen zwabbering van run tot run is geen resultaat.

De praktische versie:

1. Dezelfde game, dezelfde map of replay, dezelfde lengte, dezelfde instellingen in de game.
2. Speel op dezelfde manier. Een run waarin je naar een muur staart en een run in een vuurgevecht zijn niet vergelijkbaar.
3. Draai de ongewijzigde configuratie minstens drie keer voordat je iets verandert, zodat je weet hoe je eigen ruis eruitziet.
4. Verander één ding. Vijf veranderingen en één meting vertellen je niets over welke ervan ertoe deed — en vijf apart gemeten winsten bij elkaar optellen is rekenen, geen meten.
5. Vergelijk de lows. De benchmark lezen legt uit waar elk getal op de pagina voor dient.

De precieze rekensom, getal voor getal

Dit doet de pagina Benchmark met een opname, in de volgorde waarin hij het doet.

Controleer het zelf: herbereken uit de CSV

CSV opslaan op de pagina Benchmark schrijft één tabel met de kolommen side,kind,name,value. Rijen met kind = metric zijn de samenvattende getallen; rijen met kind = frame zijn de frame-intervallen, één per rij, met de frametijd in milliseconden in value. De framerijen bevatten de hele reeks, haperingen inbegrepen, juist zodat je de regel van 200 ms zelf kunt toepassen en op dezelfde getallen uitkomt.

Twee dingen voordat je begint:

• De getallen in het bestand gebruiken altijd een punt als decimaalteken, wat je Windows-regio ook zegt. In de regio-instellingen voor Nederland en België is het decimaalteken juist een komma: vertel je spreadsheet bij het importeren dat het bestand een punt gebruikt, anders komt 6.94 binnen als tekst.
• De kolomnamen zijn vaste Engelse namen. Ze zijn bedoeld voor scripts en in elke taal hetzelfde.

In een spreadsheet: filter op één side en op kind = frame, verwijder de rijen boven 200, sorteer value van groot naar klein, neem het gemiddelde van de eerste N rijen, waarbij N het aantal rijen gedeeld door 100 is, naar boven afgerond, en deel 1000 door dat gemiddelde. De uitkomst moet gelijk zijn aan low_1pct_fps voor die kant.

In PowerShell (vervang before door after voor de andere kant):

$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

Gebruik 0.001 in plaats van 0.01 voor de 0,1% low. Twee snelle controles op samenhang uit hetzelfde bestand: het aantal framerijen tot en met 200 is gelijk aan de metriek frames, en het aantal boven 200 is gelijk aan excluded_over_stall_ms.

Twee dingen die een percentiel stilletjes bederven

Frame generation. Ingevoegde frames dragen geen nieuwe spelstatus. Een 1% low die uit het tellen van frames volgt levert nog steeds een getal op, maar hij beschrijft de reactiesnelheid niet meer — en dat was de enige reden dat je ernaar keek. Zet generatie uit terwijl je meet. Dit is een kwestie van definitie, geen bewering dat frame generation gestotter veroorzaakt.

Laadschermen en pauzes. Een laadpauze van drie seconden is één "frame-interval" van drieduizend milliseconden, en blijft die in de gegevens staan, dan wordt hij je 0,1% low en begraaft hij alles wat echt is. Intervallen van die lengte worden om die reden buiten de percentielen gehouden en apart gemeld, zodat er nooit stilletjes een getal bovenop wordt gebouwd.

Wat de 1% low niet beweegt

Dit verdient het om ronduit gezegd te worden, want de twee worden makkelijk door elkaar gehaald: latencyfuncties en de stabiliteit van percentielen zijn verschillende beweringen. De low-latencymodi van fabrikanten verkleinen de diepte van de renderwachtrij, en die verkleining is gemeten. Er is geen gepubliceerde meting die laat zien dat ze de percentielen van de frametijd verbeteren. Beide dingen kunnen het waard zijn; ze zijn niet hetzelfde, en een pagina die het ene als het andere presenteert verkoopt je iets. Schone installatie voor stabiele 1% lows werkt het gepubliceerde bewijs met bronnen door, en De invoervertraging die geen software oplost is de eerlijke boekhouding van wat werk aan latency wel en niet kan bereiken.

Dezelfde voorzichtigheid geldt voor registerlijsten die betere lows beloven. Kernelwaarden voor geheugenbeheer en het overschrijven van de timerresolutie worden hier botweg geweigerd, niet omdat ze exotisch zijn maar omdat niemand er een meting van heeft gepubliceerd die het contact met een methode overleeft.

Wat de pagina Benchmark niet toont

• Geen getal voor "gewonnen FPS", voor geen enkele instelling, nergens in w0a. Winst is wat je eigen twee opnames laten zien, of niets.
• Geen oorzaak, alleen het tijdstip. Valt een stotter samen met iets anders dat gebeurde, dan zegt de kaart dat beide in hetzelfde tijdvenster vielen. Hij zegt niet dat het ene het andere veroorzaakte.
• Geen verschil binnen de ruisvloer wordt als wijziging getoond, in geen enkele richting.

Zijn je lows slecht en wil je de oorzaken in plaats van de getallen, dan is Waarom games stotteren op Windows 11 de lijst en is wat de stotterscan zoekt wat w0a automatisch controleert. Specifiek voor CS2 past Lage FPS en gestotter in CS2 dit allemaal toe op één game.

Gerelateerd

• Waarom games stotteren op Windows 11
• GPU niet op 100%
• De benchmark lezen
• Input lag verminderen: wat software kan verkorten en wat niet
• Stotteren door shadercompilatie
• Lage FPS en gestotter in CS2