Motifs de rejet des shares : ce que le pool a répondu

Que vous dit une réponse de rejet d'un share ?

Quand le pool refuse un share, il ne se contente pas de dire non. Il renvoie une raison numérotée, et votre logiciel de minage l'affiche.

Cette seule ligne transforme une heure de changements de réglages au hasard en une correction d'une minute. Il vaut donc la peine de savoir ce que signifie chaque réponse.

Certaines réponses signifient que quelque chose ne va pas de votre côté. D'autres signifient que rien ne va mal du tout. Les lire toutes de la même façon, c'est comme ça qu'on finit par reflasher une carte qui allait très bien.

Les cinq réponses en bref

• 20, other : lisez le texte à côté du numéro.
• 21, job not found : un share périmé, et un petit nombre est normal.
• 22, duplicate : compté une fois et jamais retenu contre vous.
• 23, low difficulty : en général un problème de votre côté.
• 24, unauthorized : presque toujours l'adresse du portefeuille.

21, job not found

Le travail auquel votre share répondait avait déjà expiré. Le réseau est passé à la suite pendant que le share était en route. À son arrivée, sa question avait déjà un gagnant.

C'est le share périmé. Un petit nombre d'entre eux est le prix d'être sur Internet, car la lumière dans la fibre n'est pas instantanée.

N'agissez que lorsque ce nombre cesse d'être petit. Un taux qui monte semaine après semaine pointe vers la latence. Essayez d'abord la région la plus proche de vous et une connexion filaire.

Un taux qui bondit dès que vous ajoutez un rig pointe vers ce rig.

23, low difficulty

Votre share n'a pas atteint la cible qui lui avait été donnée. Cette réponse signifie en général que quelque chose cloche de votre côté. C'est le premier endroit où regarder quand des rejets apparaissent.

Vérifiez ces causes :

• Un overclock instable. Un travail qui échoue à la vérification seulement de temps en temps en est le signe classique : quelques pour cent des shares, pas tous. Ramenez les fréquences du cœur et de la mémoire à leurs valeurs d'origine et voyez si les rejets disparaissent aussi.
• Le mauvais algorithme. Un logiciel lancé sur le mauvais ne produit presque rien qui puisse passer. Cela se voit donc par des rejets partout, pas par quelques pour cent.
• Un logiciel de minage obsolète. Après une mise à niveau du réseau, une ancienne version continue de produire du travail selon les anciennes règles. Chacun de ses shares échoue.
• Une difficulté fixe réglée trop haut à la main. Si vous en avez fixé une, retirez-la et laissez le pool ajuster votre rythme.

22, duplicate, et pourquoi elle ne compte pas contre vous

Le même share est arrivé deux fois au pool. Il est compté une fois, ce qui est correct. Ensuite, il ne se passe rien : un doublon ne compte jamais comme un mauvais share et ne vous rapproche jamais d'un bannissement.

C'est un choix délibéré, pas un oubli. Les doublons viennent en général du matériel qui se comporte comme du matériel.

• Le firmware d'un ASIC (le logiciel à l'intérieur d'une machine dédiée au minage) renvoie une soumission qu'il croit perdue.
• Une couche de proxy renvoie un share.
• Un logiciel de minage qui trouve deux fois la même réponse pour le même travail l'envoie deux fois.

Rien de tout cela n'est une triche du mineur. Les pools qui traitent les doublons comme invalides punissent discrètement des rigs pour un comportement choisi par leur firmware.

Si les doublons sont constants plutôt qu'occasionnels, deux rigs partagent en général un même nom de worker. Donnez à chaque rig le sien.

24, unauthorized

La connexion n'a pas été acceptée, ou un share est arrivé avant elle. En pratique, c'est presque toujours l'adresse du portefeuille.

L'adresse peut contenir une faute de frappe, ou un espace venu avec un copier-coller. Ou elle peut appartenir à un autre réseau que celui vers lequel vous pointez.

Le pool essaie de dire lequel. Si une adresse est valide mais appartient à un autre réseau, la réponse le dit. Elle nomme aussi le réseau de ce pool.

Un mauvais réseau et une faute de frappe se ressemblent exactement dans un journal. Ils demandent des corrections totalement différentes.

20, other

Cette réponse couvre tout ce qui n'est pas l'un des quatre cas ci-dessus. Elle porte, à côté du numéro, un texte qui dit ce qui s'est passé. Celle-ci se lit donc, plutôt que de se chercher.

Deux de ces réponses méritent d'être connues, car elles relèvent d'une règle et non d'un défaut de votre travail. Les deux suivent un taux de périmés qui reste élevé longtemps :

• D'abord, les shares périmés sont rejetés directement.
• Ensuite vient un bannissement temporaire.

Les deux réponses disent clairement que les shares périmés en sont la raison. Ce n'est pas un verdict sur votre matériel. Le pool refuse de continuer à payer un travail qui ne peut rien rapporter.

Les deux se lèvent d'elles-mêmes dès que le taux redescend.

Combien de rejets, c'est trop ?

Pour job not found, moins de 1 pour cent est sain sur une région bien choisie. Rien n'atteint zéro, alors surveillez la tendance plutôt que le nombre.

Pour low difficulty, toute quantité régulière signifie que quelque chose ne va pas. Ce n'est pas un coût d'être en ligne. C'est du travail qui a échoué à la vérification, et il ne rapporte rien.

Un rig à quelques pour cent est un rig dont il faut réduire l'overclock.

L'onglet En direct de votre tableau de bord montre les deux en temps réel. Il liste chaque share tel que le pool le juge.

Et si la réponse ne vous en dit pas assez ?

Suivez la liste de vérification de l'article sur les shares rejetés. Elle classe les causes selon la fréquence à laquelle chacune s'avère coupable.

Si un rig a des rejets et que les autres sont propres, le problème vient de cette machine, pas du pool. Soupçonnez d'abord son profil d'overclock, puis la version de son pilote, puis ses câbles de riser.