Auto-bench — Auto-bench

Cette page décrit ce qui se passe sur votre serveur et ce dont il a besoin. Tout ce qui relève du site (cibles d'auto-bench, calendriers, historique des runs) se gère depuis votre tableau de bord voxelbench.com.

Fonctionnement

À l'heure d'un run, un robot VoxelBench (un client Minecraft: Java Edition sans écran) se connecte à votre serveur comme n'importe quel joueur.
Il tape /vbautobot <code> <mode>. Le code est un code à usage unique que voxelbench.com a généré pour ce run.
VoxelBench demande à voxelbench.com si ce code est valable pour ce serveur. Tant que la réponse n'est pas oui, rien ne se passe sur le serveur. La réponse indique aussi ce qu'il faut lancer (mode, test ou profil, chauffe, nombre de runs), et VoxelBench n'utilise que cela, jamais ce que le robot a tapé.
VoxelBench passe le robot en mode spectateur et lance le benchmark comme il le ferait pour un joueur, sans l'écran de vérifications préalables. Il rend compte de sa progression au robot dans le chat, sur des lignes qui commencent par [AutoBench].
Les résultats partent sur voxelbench.com, et le robot se déconnecte.

Prérequis

Sur voxelbench.com

Le serveur est ajouté à votre compte et vérifié (voir Vérification du serveur). On ne peut pas créer de cible pour un serveur non vérifié.
Une cible d'auto-bench est configurée pour lui sur le tableau de bord, avec son mode et son calendrier.

Sur votre serveur

VoxelBench, officiel et à jour, sur le serveur que rejoint le robot. voxelbench.com n'accepte que les jars VoxelBench qu'il connaît : un jar recompilé ou modifié est refusé (unauthorized_plugin). Téléchargez-le sur voxelbench.com ou dans les releases GitHub.
Des connexions HTTPS sortantes vers voxelbench.com. VoxelBench vérifie lui-même chaque code et envoie lui-même les résultats. /bench ping diagnostique la connexion.
La même identité de serveur qu'au moment de la vérification. Un code ne fonctionne que sur le serveur pour lequel il a été émis, reconnu à l'identité enregistrée dans plugins/VoxelBench/identity.yml (voir Confidentialité). Conservez ce fichier si vous déplacez ou réinstallez le serveur.
Un serveur lié pour les jobs test (voir Liaison de compte) : le résultat d'un test isolé est rangé sur votre compte, ce qui demande le jeton du serveur. Les autres modes n'en ont pas besoin.
Pour les jobs custom_profile, le profil présent sur ce serveur (voir Modes).
Un monde de benchmark épinglé, vivement conseillé (voir Où tournent les runs).

Un run d'auto-bench charge le serveur autant qu'un benchmark lancé à la main : les joueurs connectés le sentiront. Programmez-le aux heures creuses.

Laisser entrer le robot

Le robot se connecte depuis Internet, comme un joueur. Tout ce qui empêche un joueur d'entrer l'en empêche aussi, et le run échoue alors avant même que VoxelBench n'intervienne :

Whitelist : si elle est active, autorisez le compte avec lequel le robot se connecte.
Mode en ligne : un serveur en online-mode=true n'admet que de vrais comptes Minecraft, et le robot doit donc se connecter avec l'un d'eux. Sa façon de s'authentifier se règle sur voxelbench.com.
Plugins anti-bot, de captcha ou de connexion, filtres de commandes : ils doivent laisser le robot entrer et exécuter /vbautobot, et ne pas lui masquer les messages de VoxelBench.
Serveur plein, pare-feu, blocage géographique : laissez une place au robot et laissez passer sa connexion.
Proxy (BungeeCord, Velocity) : le robot passe par le proxy comme n'importe quel joueur. Il doit arriver sur le serveur backend où VoxelBench est installé et que vous avez vérifié, pas dans un lobby.

Modes

Le mode se choisit sur voxelbench.com, pour chaque cible.

Mode	Ce qui tourne	Ce qui est envoyé
`standard`	Le benchmark complet, comme avec `/bench start`	Un rapport de benchmark pour chaque run mesuré
`custom_profile`	Un profil de benchmark de `plugins/VoxelBench/custom_benchmarks/`, désigné dans les arguments de la cible par son nom de fichier sans `.yml`	Un rapport de profil personnalisé, même si le profil indique `submit: false`
`stresslimit`	Le stress limit complet, tous types de stress confondus, comme avec `/bench stresslimit`	Un rapport de stress limit
`test`	Un seul test, donné dans les arguments de la cible comme pour `/bench test` : l'identifiant du test, puis ses paramètres dans l'ordre, par exemple `disk 4 8 512M 3`	Le résultat du test, sur le compte lié

Un job custom_profile n'accepte qu'un profil de benchmark, pas un profil de stress (voir Profils personnalisés). Un job test accepte les paramètres listés dans Commandes.

Chauffe et runs multiples

En standard et en custom_profile, la cible peut demander :

une chauffe : d'abord un benchmark standard complet, dans les mêmes zones, dont les résultats sont écartés et ne sont pas envoyés. Le premier run mesuré démarre 3 secondes après sa fin.
plusieurs runs, en standard seulement : voxelbench.com refuse une cible d'un autre mode avec plus d'un run (jusqu'à 10 runs avec Pro, 20 avec Enterprise ou un compte d'hébergeur). Chaque run mesuré est envoyé comme un rapport à part. Les runs réutilisent le même monde et les mêmes zones, à 10 secondes d'intervalle. Entre deux runs, dans un monde voxelbench_* seulement, VoxelBench supprime les fichiers de région autour des zones de test, pour que chaque run reparte d'un terrain fraîchement généré (voir Où tournent les runs). Si un run échoue, y compris quand son rapport est refusé, les runs restants sont annulés, et voxelbench.com compte le job comme un échec de votre serveur (contrairement à un run arrêté par /bench stop, voir Arrêter un run).

stresslimit accepte une chauffe (un benchmark standard dans le même monde) mais ne fait toujours qu'un seul run. test ignore les deux.

Où tournent les runs

L'auto-bench suit les mêmes règles de monde que les commandes :

standard, custom_profile et stresslimit tournent dans le monde épinglé. Sans lui, ils créent un monde plat temporaire quand benchmark.auto-temp-world le permet (l'option auto-temp-world propre à un profil personnalisé peut le désactiver, pas l'activer), et le suppriment à la fin. Si cette option est désactivée, ou si le monde ne peut pas être créé, ils tournent dans le monde principal du serveur.
test lance un test qui écrit dans le monde (tous les tests de gameplay sauf worldSave) dans le monde épinglé, sinon dans un monde temporaire, jamais dans le monde du robot ni dans le monde principal. Sans l'un ni l'autre, le job échoue avec benchmark_world_unavailable. Les tests matériels et CPU et worldSave ne sont pas concernés (voir Benchmarks).
Sur Folia, aucun monde ne peut être créé pendant que le serveur tourne : épinglez un monde que le serveur charge au démarrage.

Un job à plusieurs runs ne réinitialise les régions autour de ses zones de test entre deux runs que dans un monde voxelbench_*. S'il tourne ailleurs (un monde épinglé d'un autre nom, ou le monde principal sur lequel il s'est rabattu), il ne supprime rien et les runs réutilisent les chunks déjà générés. VoxelBench 2.0.2 et les versions antérieures les supprimaient dans le monde où tournait le job, monde principal compris : mettez à jour avant de laisser voxelbench.com lancer des jobs à plusieurs runs sur votre serveur.

Pour tenir l'auto-bench à l'écart de votre monde principal, épinglez un monde :

/bench world create bench
/bench world set voxelbench_bench

Le monde épinglé doit être chargé au moment du run ; s'il ne l'est pas, VoxelBench avertit et ignore l'épinglage. Les mondes créés avec /bench world create sont rechargés à chaque démarrage. Voir Mondes de benchmark et Configuration.

Ce que le robot peut faire, et ce qu'il ne peut pas

Le robot est un compte joueur ordinaire. VoxelBench ne lui donne aucune permission et aucun statut d'opérateur : il n'a que ce que votre serveur accorde à tout joueur.

Il peut :

taper /vbautobot, qui ne demande aucune permission ;
une fois son code confirmé par voxelbench.com, faire lancer par VoxelBench ce que demande le job. VoxelBench le passe en mode spectateur et le déplace vers les zones de test, comme il le fait pour un joueur qui lance /bench start. Le run passe outre l'écran de vérifications préalables et le délai de récupération local, et ne déclenche pas de délai pour vos propres runs. Un job test n'exige pas le nœud de permission du test.

Il ne peut pas :

lancer quoi que ce soit sans un code que voxelbench.com confirme pour ce serveur ;
choisir ce qui tourne : le mode, le test, le profil, la chauffe et le nombre de runs viennent de voxelbench.com, pas de ce que tape le robot ;
réutiliser un code : chaque code sert à un run d'un seul job ;
démarrer pendant qu'un autre benchmark, un stress run ou un test est en cours (test_already_running) ;
arrêter un run qu'il n'a pas lancé : /vbautobot stop n'accepte qu'un code du job en cours.

Pendant un run d'auto-bench, VoxelBench n'affiche pas de tableau de score des tests : il ne s'impose donc pas à un autre joueur connecté.

La commande `/vbautobot`

/vbautobot est le point d'entrée du robot. Elle n'a pas de nœud de permission : n'importe quel joueur peut donc la taper, et elle peut apparaître dans les suggestions de commandes. Sans code valable, elle se contente de répondre par une ligne de refus [AutoBench], comme usage-error ou validate-fail | code=invalid_nonce. /vbautobot stop <code> permet au robot d'annuler son propre run. Avec tout autre code, elle est ignorée sans réponse, et la console note le refus si un job est en cours.

Vous n'avez jamais à la taper. /bench autobot est le même point d'entrée, réservé aux essais manuels, et exige voxelbench.use. Voir Commandes.

Arrêter un run

Depuis voxelbench.com : annuler un run fait envoyer /vbautobot stop <code> au robot, qui se déconnecte ensuite. VoxelBench arrête aussitôt le run (Auto-bench stop accepted for job … dans la console).
Depuis le serveur : /bench stop (permission voxelbench.stop) arrête un run d'auto-bench comme n'importe quel autre, quel que soit son mode, et prévient immédiatement le robot. voxelbench.com l'enregistre comme un arrêt sur le serveur, pas comme une défaillance de votre serveur.
Si le robot part (expulsion, coupure réseau), VoxelBench s'en aperçoit au prochain test qui demande un joueur, attend 30 secondes qu'il revienne, puis abandonne le run.
Si le serveur s'arrête, le run est perdu : VoxelBench ne garde rien du job d'un démarrage à l'autre. Un monde temporaire laissé derrière lui est supprimé au démarrage suivant.

Un run arrêté ou abandonné n'envoie aucun rapport, et les runs restants du job ne démarrent pas.

Où vont les résultats

standard, custom_profile, stresslimit : chaque run mesuré est envoyé à voxelbench.com sous forme de rapport rattaché au job, vers lequel pointe le tableau de bord. La chauffe n'envoie rien.
test : le résultat est rangé en privé sur le compte auquel le serveur est lié, rattaché au job. reports.backend.unit-tests n'a pas d'effet ici.
En local : comme pour les runs que vous lancez vous-même, une copie est écrite sous plugins/VoxelBench/reports/ selon reports.storage (voir Configuration et Rapports).

Les rapports suivent votre niveau d'anonymisation. Comme tout run noté, un run d'auto-bench met en pause le profileur et l'inspection mémoire (voir Profilage).

Dépannage

voxelbench.com indique pourquoi chaque run a échoué. Les échecs de connexion (connexion refusée, expulsion à l'arrivée, version de Minecraft inconnue) surviennent avant que VoxelBench n'intervienne : voir Laisser entrer le robot. Si le robot est entré mais que VoxelBench n'a jamais répondu, VoxelBench n'est pas installé sur le serveur où le robot est arrivé, ou un autre plugin a bloqué /vbautobot.

Codes d'erreur

Ces codes viennent de VoxelBench. Le tableau de bord affiche la plupart d'entre eux sous un code qui lui est propre, préfixé par plugin_ : par exemple, unknown_test et test_build_failed y apparaissent comme plugin_unknown_test, et network comme plugin_network_error. Son message brut nomme le code de VoxelBench.

Code	Signification	Que faire
`benchmark_world_unavailable`	Un job `test` sur un test qui écrit dans le monde, sans monde épinglé ni monde temporaire possible (`auto-temp-world: false`, création échouée, ou Folia). Rien n'a tourné.	Épinglez un monde chargé au démarrage avec `/bench world set <monde>`, ou réactivez `benchmark.auto-temp-world` (insuffisant sur Folia).
`unauthorized_plugin`	voxelbench.com ne reconnaît pas ce jar de VoxelBench. Avec `stage=challenge`, il a été refusé dès la première requête.	Installez la dernière release officielle, non modifiée, et redémarrez.
`server_mismatch`	Le code a été émis pour une autre identité de serveur.	Assurez-vous que le robot arrive sur le serveur que vous avez vérifié. Si l'identité de ce serveur a changé, vérifiez-le de nouveau et mettez la cible à jour.
`network`	VoxelBench n'a pas pu joindre voxelbench.com, même après de nouvelles tentatives.	Lancez `/bench ping` et autorisez les connexions HTTPS sortantes.
`rate_limited`	voxelbench.com a refusé le challenge par lequel commence chaque requête signée : il n'en délivre pas plus de 150 par heure à une même adresse IP, partagés par tous les serveurs qui sortent par cette adresse. Rien n'a tourné.	Patientez, puis relancez. Si cela se répète, cherchez d'autres serveurs ou des benchmarks répétés qui envoient depuis la même adresse.
`invalid_nonce`, `nonce_expired`, `nonce_consumed`, `target_missing`	Le code est inconnu, expiré ou déjà utilisé, ou la cible a été supprimée.	Rien à corriger sur le serveur : lancez un nouveau run. Si `invalid_nonce` revient sans cesse, vérifiez qu'aucun plugin ne réécrit les commandes du robot.
`test_already_running`	Un benchmark, un stress run ou un test tournait déjà.	Évitez de lancer vos propres benchmarks à l'heure d'un auto-bench ; `/bench status` montre ce qui tourne.
`missing_profile_name`, `unknown_profile`	Job `custom_profile` sans nom de profil, ou sans profil de benchmark de ce nom sur ce serveur (la ligne liste ceux qu'il connaît).	Vérifiez le nom du fichier dans `plugins/VoxelBench/custom_benchmarks/` avec `/bench custom list` ; lancez `/bench custom reload` après avoir ajouté un fichier.
`test_no_longer_known`	Un test du profil n'est plus enregistré, le plus souvent parce que son extension a été retirée.	Réinstallez l'extension, ou modifiez le profil.
`missing_test_args`, `unknown_test`, `invalid_test_args`	Job `test` sans test, avec un identifiant de test inconnu, ou avec un paramètre hors bornes ou non numérique.	Corrigez les arguments de la cible : l'identifiant du test, puis les paramètres dans l'ordre où `/bench test` les attend.
`test_build_failed`	Le test est enregistré, mais son extension n'a pas pu le créer.	Consultez la console et l'extension.
`unknown_mode`	Cette version de VoxelBench ne connaît pas le mode.	Mettez VoxelBench à jour.
`exception`	VoxelBench a rencontré une erreur en préparant le run.	Cherchez l'erreur dans la console et signalez-la.
`invalid_json`, `validation_error`, `invalid_response_body`, `http_<statut>`, `nonces_mismatch`, `nonces_size_mismatch`	VoxelBench et voxelbench.com ne se sont pas compris, ou voxelbench.com a répondu par une erreur à chaque tentative.	Mettez VoxelBench à jour et relancez ; signalez-le si le problème persiste.
`report-fail` avec `requires a linked account`	Un job `test` sur un serveur non lié.	Liez le serveur avec `/bench link`.
`run-fail`, puis `multi-aborted` avec `reason=run_failed`	Un run d'un job à plusieurs runs s'est terminé sans son rapport : refusé par voxelbench.com ou pas envoyé. Les runs restants sont annulés, et le tableau de bord enregistre un échec (`agent_crash`, dont le message brut commence par `run-fail` suivi du motif).	Lisez le motif sur la ligne `run-fail` ; mettez VoxelBench à jour et vérifiez la connexion avec `/bench ping`.

Dans la console

Sur un build de release, les lignes [AutoBench] ne vont que dans le chat du robot. La console, elle, note les principales étapes :

Auto-bench job <id> validated for mode=standard warmup=false runs=1
Auto-bench validate-nonce rejected: <code>
Auto-bench validate-nonce transient failure (<reason>), retrying in <ms>ms (attempt <n>/<max>)
Auto-bench stop accepted for job <id> (mode <mode>) — aborting run <k>/<n>
Auto-bench stop REFUSED for job <id>: nonce mismatch (from <player>)
Report submission failed: <reason>

Suivent les lignes habituelles d'un run de benchmark, comme la création et la suppression d'un monde temporaire.