Moyenne de FPS élevée mais mauvais 1% low : ce que ça veut dire

Le compteur affiche 200 et le jeu donne la sensation d'en faire 90. Rien n'est cassé, rien ne se fige pendant une seconde entière, mais un combat ne ressemble jamais à ce que le chiffre promet. Cette sensation a un nom et une mesure, et dès que tu sais la lire, tu arrêtes de courir après le mauvais chiffre.

D'abord, la phrase honnête. Cette page explique une mesure, pas une correction. w0a n'affiche nulle part de chiffre de « FPS gagnés » ; savoir si un changement a aidé, c'est donc quelque chose que tu lis dans tes propres captures avant et après, face à ton propre bruit d'un run à l'autre — et chaque chiffre ci-dessous peut être recalculé à partir du fichier qu'enregistre la page Benchmark.

Ce que sont vraiment ces trois chiffres

Classe toutes les images d'un run, de la plus lente à la plus rapide.

Les FPS moyens sont la moyenne de toutes. C'est le chiffre le moins utile de la page.
Le 1% low, c'est le pire pour cent de ces images. Il est en général affiché comme un chiffre de FPS : un « 1% low de 70 » veut dire que tes pires images ont chacune duré à peu près aussi longtemps qu'une image dans un jeu à 70 FPS.
Le 0.1% low, c'est la pire image sur mille — les événements rares et profonds.

Le temps d'image, ce sont les mêmes données en millisecondes, et l'arithmétique vaut la peine d'être retenue parce qu'elle rend concret tout le reste de cette page : 16,7 ms font 60 FPS, 6,9 ms font 144, 4,2 ms font 240.

Donc un run avec une moyenne de 200 et un 1% low de 70, c'est un run où l'image typique a duré environ 5 ms et où le pire centième a duré environ 14 — presque trois fois plus. Et à 200 FPS, un pour cent de tes images, ça fait deux images par seconde. Deux fois par seconde, l'image reste immobile le temps de trois images. C'est ça que tu ressens, et aucune moyenne ne t'en parlera.

Lis l'écart, pas le chiffre

Un 1% low de 70 est excellent dans un run à 90 FPS et inquiétant dans un run à 200. La lecture utile, c'est le rapport entre les deux :

Ce que tu vois	Ce que ça veut dire en général
Moyenne et 1% low proches	Une livraison régulière. C'est ça, « fluide », même à une fréquence d'images modeste.
1% low très en dessous de la moyenne	Quelque chose interrompt un run par ailleurs sain — un événement, pas une charge de travail.
0.1% low très en dessous du 1% low	Des événements rares et profonds : une réinitialisation du pilote, une tempête de pagination, une longue lecture disque.
Tout est bas en même temps	Tu demandes simplement plus que ce que le matériel fournit. Baisse un réglage.

Cette troisième ligne est facile à lire de travers. Si ton 1% low est bon et ton 0.1% low catastrophique, tu n'as pas un problème de régularité — tu as une poignée d'incidents précis, et un incident, ça se retrouve.

Pourquoi une mauvaise queue de distribution n'est pas le même problème qu'une moyenne basse

Une moyenne basse est une question de charge de travail : la machine en fait autant qu'elle peut et ça ne suffit pas. La réponse, c'est un réglage, une résolution, ou un autre matériel.

Une mauvaise queue de distribution est une question d'événement : la machine suit la plupart du temps et quelque chose l'arrête périodiquement. La réponse, c'est de trouver ce quelque chose. La liste est courte et chaque entrée laisse une trace — un pilote qui retient un cœur, des pages qui reviennent du disque, la lecture d'une ressource, une tâche en arrière-plan, un shader en cours de compilation, une réinitialisation du pilote. Pourquoi les jeux saccadent sous Windows 11 parcourt cette liste cause par cause, et ce que cherche le scan des saccades en est la version automatique, qui étiquette chaque constat comme prouvé, probable, candidat ou non vérifié au lieu de te tendre un score de confiance qu'il n'a pas mérité.

Il y a aussi un cas intermédiaire : une machine qui n'est pas limitée par la carte graphique en moyenne, mais qui touche une limite dans les moments les plus chargés. Les images qui prennent du retard sont exactement celles où il se passe le plus de choses — c'est-à-dire le combat. Si ta carte graphique reste bien en dessous de la pleine occupation pendant que les low souffrent, GPU pas à 100 % est la page de diagnostic correspondante.

La discipline de mesure sans laquelle rien de tout ça ne sert

Les percentiles sont plus bruités que les moyennes, parce qu'ils sont calculés à partir de moins d'images. Deux runs de la même configuration inchangée ne donneront pas le même 1% low, et l'écart entre eux est le plus petit changement que tu sois capable de détecter.

C'est pour ça qu'une capture n'est utile qu'à côté de son propre bruit. La page Benchmark calcule un bruit de mesure à partir de la dispersion d'une minute à l'autre de chaque capture et l'affiche séparément pour la moyenne, le 1% low et le 0.1% low — et elle n'annoncera pas un écart qui tombe à l'intérieur. Toute la discipline tient dans ce seul comportement : un résultat plus petit que ta propre variation d'un run à l'autre n'est pas un résultat.

La version pratique :

Même jeu, même carte ou même replay, même durée, mêmes réglages en jeu.
Joue de la même manière. Un run passé à regarder un mur et un run passé en pleine fusillade ne sont pas comparables.
Fais au moins trois runs de la configuration inchangée avant de toucher à quoi que ce soit, pour savoir à quoi ressemble ton propre bruit.
Change une seule chose. Cinq changements et une mesure ne t'apprennent rien sur celui qui comptait — et additionner cinq gains mesurés séparément, c'est de l'arithmétique, pas de la mesure.
Compare les low. Lire le benchmark explique à quoi sert chaque chiffre de la page.

L'arithmétique exacte, chiffre par chiffre

Voici ce que la page Benchmark fait d'une capture, dans l'ordre où elle le fait.

Étape	La règle	Pourquoi elle existe
Quelles images comptent	Seulement les images dessinées pendant que le jeu était la fenêtre au premier plan. Quand le jeu revient au premier plan, la première seconde est écartée ; avant une perte de focus détectée, les 0,2 dernières secondes sont écartées. Le temps écarté est rapporté avec le run.	Une capture démarre et s'arrête depuis la fenêtre de w0a, donc ses bords, c'est le jeu en arrière-plan. Sur une capture enregistrée, 94 des 185 images derrière le 1% low étaient ces bords. La seconde est une valeur choisie, pas mesurée.
Blocages	Un intervalle d'image de plus de 200 ms est exclu de la moyenne et de tous les percentiles, et compté à part.	Au-delà de 200 ms, c'est un écran de chargement, un alt-tab ou un blocage du pilote, pas du rendu. Pris dans la moyenne, il enterrerait toutes les vraies images.
FPS moyens	Les images comptées divisées par le temps qu'elles ont pris : images × 1000 ÷ millisecondes totales.
1% low	Trie les temps d'image comptés. Prends-en le 1 % le plus lent, arrondi au supérieur et jamais moins d'une image, fais la moyenne de ces temps d'image et convertis le résultat en FPS : 1000 ÷ cette moyenne.	L'autre définition courante, la fréquence d'images au temps d'image du 99e percentile, a été écartée exprès : avec exactement 1 % d'images qui saccadent, elle tombe sur la frontière et rapporte presque le même chiffre que la moyenne.
0.1% low	La même chose, avec le 0,1 % le plus lent.
Temps d'image au 99e et au 99,9e percentile	Rapportés à part, en millisecondes.	Pour les lecteurs et les outils qui utilisent la définition par percentile.
Trop court pour être lu	En dessous de 900 images, il n'y a pas assez d'images pour que le percentile veuille dire quelque chose.
Nombre de saccades	Une image est un à-coup quand elle est plus longue à la fois que le double de la médiane des trois secondes qui l'entourent et que cette médiane plus 8 ms, jusqu'à une seconde.	Trois secondes plutôt qu'un nombre fixe d'images, pour que la règle veuille dire la même chose à 60 FPS et à 300. Le terme de 8 ms empêche que la simple gigue à haute fréquence d'images compte comme une saccade. Les images entre 200 ms et une seconde sont exclues des percentiles mais incluses ici : un accroc de 250 ms dû à la compilation des shaders est exactement ce que ce compte existe pour attraper.
Bruit de mesure	La capture est découpée en blocs de 60 secondes. Chaque côté d'une comparaison a besoin d'au moins deux blocs entiers, sinon la page dit « non comparable » au lieu de colorer un chiffre. Le plancher de bruit est un intervalle à 95 % tiré de la dispersion d'un bloc à l'autre des deux côtés (méthode de Welch), en pourcentage de la valeur « avant ». Seuls comptent les blocs complets sans événements perdus, et un plancher de zéro n'est jamais produit.	Un écart qui reste dans ta propre variation d'un bloc à l'autre n'est pas un résultat.
Série appariée	Quand tu lances une série A/B, un changement n'est rapporté que si un test exact des rangs signés et un intervalle bootstrap à 95 % de la différence médiane (10 000 rééchantillonnages) excluent tous les deux zéro, et si la médiane atteint au moins le plus petit effet qu'un pilote de 10 runs a montré que la configuration peut détecter. La série a besoin d'au moins 6 paires — avec 5, la plus petite valeur p possible est 0,0625 — et en suggère 8, lancées dans l'ordre ABBA.	Une seule paire avant-après ne peut pas distinguer un changement d'un GPU chaud ou d'un point d'apparition différent.

Vérifie toi-même : recalcule à partir du CSV

Enregistrer en CSV sur la page Benchmark écrit un tableau avec les colonnes side,kind,name,value. Les lignes où kind = metric sont les chiffres de synthèse ; les lignes où kind = frame sont les intervalles d'image, un par ligne, avec le temps d'image en millisecondes dans value. Les lignes d'image contiennent toute la série, blocages compris, précisément pour que tu puisses appliquer toi-même la règle des 200 ms et retomber sur les mêmes chiffres.

Deux choses avant de commencer :

Les nombres du fichier utilisent toujours un point comme séparateur décimal, quoi que dise ta région Windows. Dans les paramètres régionaux pour la France, le séparateur décimal est au contraire la virgule : indique à ton tableur que le fichier utilise un point quand tu l'importes, sinon 6.94 arrive comme du texte.
Les noms de colonnes sont des identifiants anglais fixes. Ils sont faits pour les scripts et sont les mêmes dans toutes les langues.

Dans un tableur : filtre sur un side et sur kind = frame, retire les lignes au-dessus de 200, trie value du plus grand au plus petit, fais la moyenne des N premières lignes, où N est le nombre de lignes divisé par 100 et arrondi au supérieur, puis divise 1000 par cette moyenne. Le résultat doit être égal à low_1pct_fps pour ce côté.

Dans PowerShell (remplace before par after pour l'autre côté) :

$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

Utilise 0.001 au lieu de 0.01 pour le 0.1% low. Deux contrôles rapides de cohérence avec le même fichier : le nombre de lignes d'image inférieures ou égales à 200 est égal à la métrique frames, et le nombre de lignes au-dessus de 200 est égal à excluded_over_stall_ms.

Deux choses qui ruinent discrètement un percentile

La génération d'images. Les images insérées ne portent aucun nouvel état de jeu. Un 1% low calculé en comptant les images produit toujours un chiffre, mais il a cessé de décrire la réactivité — la seule raison pour laquelle tu le regardais. Désactive la génération pendant que tu mesures. C'est une question de définition, pas une affirmation selon laquelle la génération d'images provoque des saccades.

Les écrans de chargement et les pauses. Une pause de chargement de trois secondes, c'est un unique « intervalle d'image » de trois mille millisecondes, et laissé dans les données il devient ton 0.1% low et enterre tout ce qui est réel. Les intervalles aussi longs sont exclus des percentiles pour cette raison et rapportés à part, pour qu'un chiffre ne soit jamais bâti en silence sur l'un d'eux.

Ce qui ne fait pas bouger le 1% low

Ça mérite d'être dit clairement, parce qu'il est facile de confondre les deux : les fonctions de latence et la stabilité des percentiles sont deux affirmations différentes. Les modes basse latence des fabricants réduisent la profondeur de la file de rendu, et cette réduction a été mesurée. Aucune mesure publiée ne montre qu'ils améliorent les percentiles de temps d'image. Les deux peuvent valoir le coup ; ce ne sont pas la même chose, et une page qui présente l'une pour l'autre est en train de te vendre quelque chose. Installation propre pour des 1% low stables reprend les preuves publiées avec leurs sources, et la latence d'entrée qu'aucun logiciel ne corrige fait le compte honnête de ce que le travail sur la latence peut atteindre et de ce qu'il ne peut pas.

La même prudence vaut pour les listes de registre qui promettent de meilleurs low. Les valeurs de gestion mémoire du noyau et les forçages de résolution du timer sont refusés net ici, non pas parce qu'ils sont exotiques, mais parce que personne n'en a publié une mesure qui survive au contact d'une méthode.

Ce que la page Benchmark n'affiche pas

Aucun chiffre de « FPS gagnés », pour aucun réglage, nulle part dans w0a. Un gain, c'est ce que montrent tes deux propres captures, ou rien.
Aucune cause, seulement le moment. Quand une saccade coïncide avec autre chose qui s'est passé, la carte dit que les deux sont tombés dans la même fenêtre de temps. Elle ne dit pas que l'un a causé l'autre.
Aucun écart à l'intérieur du plancher de bruit n'est affiché comme un changement, dans un sens ou dans l'autre.

Si tes low sont mauvais et que tu veux les causes plutôt que les chiffres, Pourquoi les jeux saccadent sous Windows 11 est la liste, et ce que cherche le scan des saccades est ce que w0a vérifie automatiquement. Pour CS2 en particulier, FPS bas et saccades dans CS2 applique tout cela à un seul jeu.