Wysoki średni FPS, ale słabe 1% low: co to znaczy

Licznik pokazuje 200, a gra sprawia wrażenie 90. Nic nie jest zepsute, nic nie zamarza na całą sekundę, ale walka nigdy nie wypada tak, jak obiecuje ta liczba. To odczucie ma swoją nazwę i swój pomiar, a kiedy potrafisz je odczytać, przestajesz gonić niewłaściwą liczbę.

Najpierw uczciwe zdanie. Ta strona tłumaczy pomiar, a nie naprawę. w0a nigdzie nie wypisuje liczby „zyskane FPS”, więc to, czy zmiana pomogła, odczytujesz z własnych przebiegów przed i po, na tle własnego szumu między przebiegami — a każdą liczbę poniżej da się przeliczyć z pliku, który zapisuje strona Benchmark.

Czym naprawdę są te trzy liczby

Ustaw wszystkie klatki z przebiegu od najwolniejszej do najszybszej.

• Średni FPS to średnia z nich wszystkich. To najmniej użyteczna liczba na całej stronie.
• 1% low to najgorszy jeden procent tych klatek. Podaje się go zwykle jako wartość FPS, więc „1% low równe 70” znaczy, że każda z twoich najgorszych klatek trwała mniej więcej tyle, ile klatka w grze chodzącej na 70 FPS.
• 0,1% low to najgorsza jedna na tysiąc — rzadkie, głębokie zdarzenia.

Czas klatki to te same dane w milisekundach, a tę arytmetykę warto zapamiętać, bo dzięki niej reszta tej strony robi się konkretna: 16,7 ms to 60 FPS, 6,9 ms to 144, 4,2 ms to 240.

Przebieg ze średnią 200 i 1% low równym 70 to więc przebieg, w którym typowa klatka trwała około 5 ms, a najgorsza setna około 14 — prawie trzy razy dłużej. A przy 200 FPS jeden procent twoich klatek to dwie klatki na sekundę. Dwa razy na sekundę obraz stoi w miejscu przez czas trzech klatek. To właśnie czujesz, i żadna ilość średniej ci o tym nie powie.

Czytaj różnicę, nie samą liczbę

1% low równe 70 jest znakomite w przebiegu na 90 FPS i niepokojące w przebiegu na 200. Użytecznym odczytem jest relacja między nimi:

Ten trzeci wiersz łatwo źle odczytać. Jeśli twoje 1% low jest w porządku, a 0,1% low fatalne, nie masz problemu z równomiernością — masz garść konkretnych zdarzeń, a zdarzenia da się znaleźć.

Dlaczego zły ogon to inny problem niż niska średnia

Niska średnia to pytanie o obciążenie: maszyna robi tyle, ile potrafi, i to za mało. Odpowiedzią jest ustawienie, rozdzielczość albo inny sprzęt.

Zły ogon to pytanie o zdarzenie: maszyna w większości nadąża, a coś ją okresowo zatrzymuje. Odpowiedzią jest znalezienie tej rzeczy. Lista jest krótka i każda pozycja zostawia ślad — sterownik trzymający rdzeń procesora, strony wracające z dysku, odczyt zasobu, zadanie w tle, kompilowany shader, reset sterownika. Dlaczego gry przycinają na Windows 11 przechodzi tę listę przyczyna po przyczynie, a czego szuka skan przycięć to jej wersja automatyczna — oznacza każde znalezisko jako udowodnione, prawdopodobne, kandydata albo niesprawdzone, zamiast wręczać ci wskaźnik pewności, na który sobie nie zapracowała.

Jest też przypadek pośredni: maszyna, która średnio nie jest ograniczona przez kartę graficzną, ale w najbardziej zajętych chwilach uderza w limit. Klatki, które zostają w tyle, to dokładnie te klatki, w których dzieje się najwięcej — czyli walka. Jeśli twoja karta graficzna siedzi wyraźnie poniżej pełnego obłożenia, a lowy cierpią, stroną diagnostyczną jest GPU nie na 100%.

Dyscyplina pomiaru, bez której nic z tego nie ma sensu

Percentyle są bardziej szumne niż średnie, bo liczy się je z mniejszej liczby klatek. Dwa przebiegi tej samej, niezmienionej konfiguracji nie dadzą tego samego 1% low, a różnica między nimi to najmniejsza zmiana, jaką w ogóle jesteś w stanie wykryć.

Dlatego pomiar jest użyteczny tylko obok własnego szumu. Strona Benchmark przed / po wylicza szum pomiarowy z rozrzutu każdego przebiegu minuta po minucie i wypisuje go osobno dla średniej, dla 1% low i dla 0,1% low — i nie ogłosi różnicy, która mieści się w jego środku. To cała dyscyplina zamknięta w jednym zachowaniu: wynik mniejszy niż twoje własne wahanie między przebiegami nie jest wynikiem.

W wersji praktycznej:

1. Ta sama gra, ta sama mapa albo powtórka, ta sama długość, te same ustawienia w grze.
2. Graj tak samo. Przebieg spędzony na patrzeniu w ścianę i przebieg spędzony w wymianie ognia nie są porównywalne.
3. Zmierz niezmienioną konfigurację co najmniej trzy razy, zanim cokolwiek zmienisz, żebyś wiedział, jak wygląda twój własny szum.
4. Zmień jedną rzecz. Pięć zmian i jeden pomiar nie mówią nic o tym, która z nich miała znaczenie — a dodanie do siebie pięciu osobno zmierzonych zysków to arytmetyka, a nie pomiar.
5. Porównaj lowy. Jak czytać wynik benchmarku omawia, do czego służy każda liczba na tej stronie.

Dokładna arytmetyka, liczba po liczbie

Oto, co strona Benchmark robi z przebiegiem, w kolejności, w jakiej to robi.

Sprawdź sam: przelicz z CSV

Zapisz CSV na stronie Benchmark zapisuje jedną tabelę z kolumnami side,kind,name,value. Wiersze z kind = metric to liczby podsumowania; wiersze z kind = frame to odstępy między klatkami, jeden na wiersz, z czasem klatki w milisekundach w value. Wiersze klatek przechowują całą serię, razem z zatrzymaniami, właśnie po to, żebyś mógł sam zastosować regułę 200 ms i dojść do tych samych liczb.

Dwie rzeczy, zanim zaczniesz:

• Liczby w pliku zawsze używają kropki jako separatora dziesiętnego, niezależnie od ustawień regionalnych Windows. W polskich ustawieniach regionalnych separatorem dziesiętnym jest przecinek, więc przy imporcie powiedz o tym arkuszowi kalkulacyjnemu, inaczej 6.94 przyjdzie jako tekst.
• Nazwy kolumn to stałe identyfikatory po angielsku. Są przeznaczone dla skryptów i są takie same w każdym języku.

W arkuszu kalkulacyjnym: przefiltruj jedną wartość side i kind = frame, usuń wiersze powyżej 200, posortuj value od największej do najmniejszej, uśrednij pierwsze N wierszy, gdzie N to liczba wierszy podzielona przez 100 i zaokrąglona w górę, i podziel 1000 przez tę średnią. Wynik powinien być równy low_1pct_fps dla tej strony.

W PowerShell (dla drugiej strony zamień before na after):

$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

Dla 0,1% low użyj 0.001 zamiast 0.01. Dwa szybkie sprawdzenia spójności z tego samego pliku: liczba wierszy klatek z wartością 200 lub mniejszą jest równa metryce frames, a liczba wierszy powyżej 200 — metryce excluded_over_stall_ms.

Dwie rzeczy, które po cichu psują percentyl

Generowanie klatek. Wstawione klatki nie niosą nowego stanu gry. 1% low policzone ze zliczania klatek dalej daje jakąś liczbę, ale przestało opisywać to, jak szybko gra odpowiada na twoje ruchy — a to jedyny powód, dla którego w ogóle na nie patrzyłeś. Na czas pomiaru wyłącz generowanie. To uwaga o definicji, a nie twierdzenie, że generowanie klatek powoduje przycięcia.

Ekrany ładowania i pauzy. Trzysekundowe zatrzymanie na ładowaniu to pojedynczy „odstęp między klatkami” o długości trzech tysięcy milisekund, a zostawiony w danych staje się twoim 0,1% low i grzebie wszystko, co prawdziwe. Właśnie dlatego tak długie odstępy są wyłączane z percentyli i raportowane osobno, żeby żadna liczba nie została po cichu zbudowana na jednym z nich.

Co nie rusza 1% low

To trzeba powiedzieć wprost, bo łatwo pomylić te dwie rzeczy: funkcje od opóźnienia i stabilność percentyli to dwa różne twierdzenia. Tryby niskiego opóźnienia od producentów zmniejszają głębokość kolejki renderowania i to zmniejszenie zostało zmierzone. Nie ma opublikowanego pomiaru pokazującego, że poprawiają percentyle czasu klatki. Obie rzeczy mogą być warte posiadania; nie są tym samym, a strona, która przedstawia jedną jako drugą, coś ci sprzedaje. Czysta instalacja dla stabilnych 1% low przechodzi przez opublikowane dowody ze źródłami, a Opóźnienie wejścia, którego nie naprawi żaden program to uczciwe rozliczenie tego, dokąd praca nad opóźnieniem sięga, a dokąd nie.

Ta sama ostrożność dotyczy list wpisów do rejestru obiecujących lepsze lowy. Wartości zarządzania pamięcią jądra i wymuszanie rozdzielczości timera są tutaj odrzucane wprost — nie dlatego, że są egzotyczne, tylko dlatego, że nikt nie opublikował ich pomiaru, który przetrwałby zetknięcie z metodą.

Czego strona Benchmark nie wypisuje

• Żadnej liczby „zyskane FPS” — dla żadnego ustawienia, nigdzie w w0a. Zysk to to, co pokazują twoje własne dwa przebiegi, albo nic.
• Żadnej przyczyny, tylko czas. Gdy przycięcie zbiega się z czymś innym, co się wydarzyło, karta mówi, że oba wypadły w tym samym oknie. Nie mówi, że jedno spowodowało drugie.
• Żadna różnica wewnątrz poziomu szumu nie jest pokazywana jako zmiana, w żadną stronę.

Jeśli twoje lowy są słabe i chcesz przyczyn, a nie liczb, listą jest Dlaczego gry przycinają na Windows 11, a to, co w0a sprawdza automatycznie, opisuje Czego szuka skan przycięć. Dla samego CS2 Niskie FPS i przycięcia w CS2 stosuje to wszystko do jednej gry.

Powiązane

• Dlaczego gry przycinają na Windows 11
• GPU nie na 100%
• Jak czytać wynik benchmarku
• Jak zmniejszyć input lag: co program może skrócić, a czego nie
• Przycięcia od kompilacji shaderów
• Niskie FPS i przycięcia w CS2