VNISH Ninja Académie

VNISH Ninja · Académie

Le mineur a démarré : que vérifier avant de déclarer l’installation réussie

Une interface accessible prouve seulement un démarrage partiel. Vérifier build, inventaire, refroidissement, pool et travail accepté avant de conclure.

Révisé: Auteur: VNISH Ninja Rédaction de l’AcadémieRévision: Auto-vérification technique

Méthode de travail

  1. Comparer le build lu à la cible prévue.
  2. Comparer hashboards et puces à l’inventaire initial.
  3. Contrôler refroidissement, températures, PSU et électricité de la variante exacte.
  4. Confirmer pool, worker et accepted work ; séparer métriques locales et pool.

Examinons une situation

Scénario pédagogique, et non résultat rapporté par un client.

Imaginez un premier démarrage hypothétique qui affiche le logo attendu et un tableau de bord lisible. L’action utile suivante est une comparaison avec le relevé d’avant changement, pas une déclaration immédiate de réussite. Confirmez que le build indiqué est bien celui prévu pour cet appareil. Comparez les cartes détectées à l’inventaire précédent, puis examinez les observations de refroidissement et les nouvelles erreurs.

Identifiez ensuite le worker prévu et vérifiez si son relevé côté pool montre du travail accepté sur la période d’observation choisie. Si une carte est absente alors que le taux de hachage total semble encore élevé, cette absence reste une condition non résolue ; le total ne peut pas l’annuler. À l’inverse, un bref écart entre deux tableaux de bord ne constitue pas un diagnostic tant que leurs sources et leurs fenêtres temporelles ne sont pas comprises. Horodatez chaque observation en distinguant « non vérifié » de « vérifié et conforme ».

La décision finale peut être GO, HOLD ou STOP selon les conditions préalablement convenues pour le site. Aucun nombre universel de minutes ne remplace ces preuves. Un premier écran qui fonctionne est le point de départ de la lecture de l’état réel, pas une garantie de minage stable.

Limites et conditions d’arrêt

  • Bootloop, carte absente, température incontrôlée, rejets répétés ou mauvais build imposent STOP.
  • Un écran vert n’est pas un test de bout en bout.
  • Aucune durée universelle ne garantit la stabilisation.

Support réutilisable

#ChampVérifiéPreuve / note
1build prévu / observé□
2cartes / puces avant et après□
3refroidissement / température / PSU□
4pool / worker / accepted work□
5statut Dev Fee visible dans le dashboard□
6méthode de mesure de la puissance à la prise□
7erreurs / fenêtre / GO-HOLD-STOP□

Copiez cette structure dans le journal du changement ; n’y placez jamais de mots de passe, clés ou accès privés.

Termes utilisés dans ce guide

Lecture de l’état réel
Observation de l’état réel de l’appareil comparé au résultat prévu.
Écart d’inventaire
Différence entre les composants attendus de l’appareil et ceux observés.
HOLD
Décision de ne pas poursuivre tant qu’une preuve requise ou une question opérationnelle reste non résolue.

Vérifiez votre compréhension

Ces questions vérifient la compréhension. Elles n’autorisent pas une installation et ne certifient pas un résultat.

  1. Un taux de hachage total élevé peut-il annuler le constat d’une carte manquante ?

    Afficher la réponse

    Non. L’écart d’inventaire reste non résolu.

  2. « Non vérifié » signifie-t-il « conforme » ?

    Afficher la réponse

    Non. Ces états doivent rester distincts dans le relevé.

  3. Un délai d’attente fixe peut-il établir la stabilité de tous les appareils ?

    Afficher la réponse

    Non. La période d’observation et les conditions d’acceptation dépendent du test et du site précis.

Sources primaires