Comment fonctionne le scoring

D'où vient le score

Le plugin lance les tests et envoie leurs résultats bruts ; voxelbench.com calcule le score, et le plugin ne fait qu'afficher ce que le site renvoie (voir Benchmarks). Les règles ont une version, affichée sur chaque rapport : Barème standard 8.0.0. Quand les règles changent, un rapport noté avec une version antérieure est marqué barème antérieur : deux versions ne se comparent pas directement.

Les runs de stress limit utilisent un barème à part, Barème stress-limit, avec sa propre version et un total qui plafonne vers 25 000 : ne le comparez jamais à un score standard. Les runs de profils personnalisés sont conservés sans score.

Quels tests comptent

Un benchmark complet (/bench start) lance 16 tests. 14 d'entre eux forment le score, en trois catégories :

• network doit figurer dans le rapport, mais ne pèse rien.
• singleCoreBenchmark, lancé à la fin du benchmark, est conservé dans le rapport mais pas noté.
• Les autres tests du catalogue (mobSpawn, villagerTrading, liquidPhysics…) ne tournent qu'avec /bench test ou les profils personnalisés, et ne comptent jamais.

Le catalogue du plugin range redstone et blockPhysics parmi les tests de gameplay : pour le score, ils forment la catégorie mono-cœur, parce que tous deux font porter toute leur charge sur le fil principal du serveur.

Le mono-cœur et le gameplay pèsent ensemble 80 % du score, parce que Minecraft fait tourner sa boucle de jeu sur un seul fil. Le disque le plus rapide du monde n'aide pas si le CPU ne suit pas le traitement des ticks.

Un test manquant, échoué ou ignoré

Un rapport n'est noté que si chaque test requis (les 14 ci-dessus, plus network) est présent, a réussi et n'a pas été ignoré. Un test ignoré — par exemple un test que le plugin a refusé de lancer parce que la mémoire du serveur était trop juste — n'est pas une faute du serveur, mais ce n'est pas non plus une mesure : le rapport est conservé, sans score ni rang, et reste hors du classement. Voir Tests unitaires pour les raisons pour lesquelles un test peut être ignoré ou échouer.

Un test qui a tourné mais produit des données inutilisables (aucun échantillon, aucun travail effectué, des entités qui n'ont jamais tiqué, des zones qui n'ont pas pu tiquer…) coûte 8 % du total, cumulés test par test, jusqu'à −40 %.

Score de base

Chaque catégorie reçoit son propre score, puis les trois sont combinées selon leurs poids (40 / 40 / 20). La combinaison est surtout une moyenne pondérée (85 %), avec une part de moyenne géométrique (15 %) : une catégorie très faible tire le total vers le bas plus qu'une simple moyenne ne le ferait.

Performance mono-cœur (40 %)

redstone (53 %) actionne des pistons par des circuits de redstone et blockPhysics (47 %) fait tomber des blocs : tous deux mesurent à quel point le fil principal tient ses 20 ticks par seconde.

Ce qui compte le plus

• Le MSPT (millisecondes par tick) compte pour 75 % du score de tick d'un test, le TPS pour 25 %. Contrairement au TPS, plafonné à 20, le MSPT montre la marge restante : 20 TPS à 10 ms laissent 40 ms de réserve, 20 TPS à 48 ms sont à la limite.
• Les pires ticks pèsent le plus. La part MSPT se compose à 40 % du 95e centile, à 40 % du 99e et à 20 % seulement de la moyenne ; la part TPS mêle la médiane (35 %), le 5e centile (30 %), le 1er centile (15 %) et la moyenne (20 %).
• La courbe. Sous 20 ms par tick, un test obtient la meilleure valeur ; entre 20 et 50 ms, elle décroît selon une courbe en S centrée sur 35 ms ; au-delà du budget de 50 ms, elle chute fortement, avec une pénalité supplémentaire après 100 ms. Côté TPS, une moyenne de 19,8 ou plus obtient la pleine valeur, et un TPS minimal sous 18 coûte davantage.
• La stabilité est récompensée : une faible variation du TPS et du MSPT et des pires ticks proches de la moyenne ajoutent chacun un bonus, de même qu'un MSPT moyen bas.

Les deux tests gagnent aussi un bonus ensemble : quand leurs scores concordent (jusqu'à +8 %), et quand tous deux tiennent en moyenne au moins 19,0, 19,5 ou 19,8 TPS (+5, +10 ou +15 %). Des scores très différents entre eux coûtent 5 %.

Score gameplay (40 %)

De vraies charges Minecraft, construites par le plugin dans le monde de benchmark.

Sous-catégories

Exploration (30 % du gameplay)

• chunkLoading (43 %) : chunks générés et chargés par seconde, temps de chargement, et performance des ticks pendant ce temps
• chunkTicking (33 %) : ticks aléatoires à vitesse de tick relevée, notés sur la performance des ticks
• lightingUpdate (24 %) : mises à jour du moteur d'éclairage, notées sur la performance des ticks

Entités (25 % du gameplay)

• mobAI seul : un village de 2 400 villageois qui commercent, puis une invasion de 1 200 monstres, noté sur la performance des ticks et sur l'écart entre les deux phases

Mécaniques (45 % du gameplay) — la sous-catégorie de gameplay la plus lourde

• hopper (21 %) : objets transférés par seconde (85 %) et performance des ticks (15 %)
• explosion (23 %) : blocs détruits par seconde, avec une pénalité quand le TPS minimal tombe sous 15
• tickingTileEntity (19 %) : fours, hoppers et spawners qui tiquent, notés sur la performance des ticks
• worldSave (17 %) : l'impact d'une sauvegarde complète du monde sur le tick. Son débit d'écriture ne compte plus : ce test pèse peu et obtient presque le même score partout
• boneMealGrowth (20 %) : la vitesse de pousse des pousses d'arbres et des cultures (75 %) et la performance des ticks (25 %)

Un test de mécanique dont le plugin a signalé la mesure comme moins fiable ne peut pas dépasser la moyenne des autres tests de mécanique.

Pourquoi les mécaniques pèsent le plus

Les interactions mécaniques sont ce que les joueurs construisent réellement sur les serveurs survie et techniques. Un serveur qui gère bien le chargement de chunks mais s'étouffe sur des chaînes de hoppers n'est pas utile pour un SMP classique ou un serveur technique.

Équilibre

Quand les trois sous-scores restent à moins de 25 % les uns des autres, le gameplay gagne +3 % ; quand le plus faible descend sous 40 % du plus fort, −2 %.

Score matériel (20 %)

Les capacités brutes du système, indépendamment de la charge Minecraft :

Mémoire (50 % du matériel) — la mesure matérielle la plus déterminante pour Minecraft

• Débits en lecture et écriture séquentielles, en accès aléatoire et en copie, et latence mémoire
• L'accès aléatoire pèse le plus, parce que Minecraft lit ses données de monde surtout dans le désordre ; la latence module en plus tout le score mémoire

Disque (25 %)

• Débit séquentiel, et débit aléatoire en blocs de 4 Ko mesuré en accès direct (sans le cache du système) ; l'aléatoire pèse davantage
• Une pénalité quand la latence au 99e centile dépasse 1 ms, et un bonus allant jusqu'à +10 % pour un grand nombre d'opérations par seconde
• Compte pour les sauvegardes du monde et le chargement des chunks depuis le disque

Multi-cœur (25 %)

• Débit parallèle sur les cœurs que le serveur peut utiliser, et qualité de la montée en charge
• Un bonus à partir de 4, 8 et 16 cœurs (+3, +7 et +13 %) : utile pour le travail asynchrone de Paper, le garbage collector et les plugins

Pourquoi le matériel ne pèse que 20 %

Parce que Minecraft tique sur un seul fil. Un serveur avec un NVMe ultra-rapide et 128 Go de RAM mais un CPU faible en mono-cœur aura quand même un mauvais TPS. Le matériel compte, mais la performance mono-cœur domine.

Multiplicateurs

Après le score de base, plusieurs multiplicateurs l'ajustent. La page du rapport en affiche quatre : Synergie, Stabilité, Durée et GC.

Synergie

Ne dépend que de la plus faible des trois catégories : plus votre catégorie la plus faible est forte, plus le bonus est élevé, de ×0,90 à ×1,15. Améliorer une catégorie, quelle qu'elle soit, ne peut donc jamais faire baisser le score.

Durée

La durée totale du run, chauffe de la JVM comprise. Un serveur plus rapide termine plus tôt, ce qui est en soi un indicateur de performance :

Stabilité

La régularité sur tout le benchmark : la variation moyenne du TPS et du MSPT sur six tests (redstone, blockPhysics, chunkLoading, chunkTicking, mobAI, hopper), d'environ ×0,87 à ×1,065. Des résultats irréguliers trahissent une interférence extérieure : d'autres processus, un bridage du CPU, des voisins bruyants sur un hébergement mutualisé.

Garbage collection

Les règles prévoient un multiplicateur de garbage collection (surcoût, longues pauses, fréquence des pauses), mais le plugin n'envoie pas aujourd'hui la mesure qu'il lit : il reste donc à ×1,00. Les pauses du GC comptent tout de même : elles apparaissent comme des ticks lents dans les centiles de MSPT de chaque test.

Données inutilisables

Les −8 % par test inutilisable décrits plus haut, jusqu'à ×0,60.

Le produit passe ensuite par une courbe douce centrée sur 250 000, le score médian attendu : elle comprime légèrement les scores au-dessus et étire ceux en dessous. Un facteur fixe de ×0,98, hérité d'une ancienne étape de validation croisée, s'applique aussi. Il n'y a pas de score maximal.

Badges de rang

Le rang compare votre score aux autres rapports : les rapports standard publics et certifiés des 6 derniers mois, les certifiés comptant quatre fois.

Les seuils sont recalculés toutes les 6 heures, et tous les rangs avec eux : le rang d'un rapport peut changer avec le temps alors que son score ne bouge pas. Tant que l'ensemble compte moins de 10 rapports, des seuils fixes s'appliquent (SS à partir de 450 000, puis 400 000, 350 000, 300 000, 250 000, 200 000 et 150 000 pour E).

Les runs de stress limit ont des seuils fixes : SS à partir de 25 000, S de 20 000, A de 16 000, B de 12 000, C de 9 000, D de 6 000, E de 3 000.

Points clés à retenir

1. Le MSPT compte plus que le TPS — le TPS plafonne à 20, le MSPT montre la vraie marge, et il pèse trois fois plus
2. Le pire cas compte plus que la moyenne — les 95e et 99e centiles font l'essentiel du score de tick
3. Un run complet est exigé — un seul test requis ignoré ou échoué, et le rapport n'a pas de score
4. La stabilité est récompensée — 18 TPS réguliers valent mieux que 20 puis 12 en alternance
5. Le vrai gameplay domine — 80 % du score dépend du fil principal et des charges Minecraft
6. La catégorie la plus faible fixe la synergie — un serveur équilibré dépasse celui qui n'a qu'un point fort
7. Le rang est relatif — il place votre score parmi les rapports publics récents