Shares et latence : comprendre la communication ASIC-pool

Un share est une preuve de travail soumise au pool : un hash d'en-tête qui bat la cible de share assignée, plus facile à atteindre que la cible du réseau. Le pool s'en sert pour compter votre travail. La latence est le temps d'aller-retour et de traitement entre votre machine et le serveur de jobs. Les deux se rejoignent sur un point : un job devenu trop vieux au moment où votre share arrive ne rapporte rien.

Jobs, invalidation, et les deux horloges qui comptent

Le pool envoie un job, c'est-à-dire un template contenant transactions, extra-nonce, nBits et le reste. Quand le réseau ou le pool avance, par un nouveau bloc ou un nouveau template, les jobs précédents deviennent obsolètes. Un share calculé sur un job périmé ne contribue plus au comptage, ou y contribue moins selon les règles du pool.

Deux horloges déterminent cette perte :

• le RTT, aller-retour réseau, auquel s'ajoutent les files d'attente du contrôleur ;
• la durée de vie du job, dictée par le rythme des blocs, dix minutes en moyenne mais avec une forte variance, et par la politique de clean job du pool.

L'arrivée des blocs vous échappe complètement. Le chemin réseau, le choix du point de présence et, dans une moindre mesure, le firmware et sa stratégie de soumission, vous appartiennent.

Accepted, stale, rejected

Les tableaux de bord distinguent en général trois états :

• accepted : share valide sur un job encore courant, compté ;
• stale, parfois late : preuve correcte mais calculée sur un job trop vieux ;
• rejected : share mal formée, cible non atteinte, worker inconnu, duplicata, ou règle propre au pool.

Ces étiquettes ne sont pas normalisées, et ce qu'un pool appelle reject, un autre l'appellera stale. Lisez la légende de votre pool avant toute comparaison. Un taux de stale non nul est attendu, puisque les blocs arrivent en permanence ; ce qui doit alerter, c'est un écart net avec les autres machines du même site sur le même pool.

Méfiez-vous des taux de référence donnés sans mesure : les valeurs dépendent du RTT, du pool, du firmware et de la variance courte. Un « taux normal » avancé sans mesurer votre lien ne vous apprend rien sur votre parc.

Pourquoi la latence coûte de l'argent

Tant que la machine travaille sur un job déjà remplacé, ses hashes ne produisent plus de shares utiles. La fraction de temps passée hors template croît avec le délai nécessaire pour recevoir le nouveau job et abandonner l'ancien. La relation n'est pas linéaire, les blocs étant un processus aléatoire, mais le sens est constant : plus le RTT et la gigue sont élevés, plus la part de travail mort augmente.

La latence pèse aussi sur la chance apparente à court terme et, pour un parc assez gros pour trouver des blocs, sur le risque d'orphelin lié à la propagation. Pour un petit hashrate en pool, l'effet dominant reste largement le stale et le reject.

Ce qui fait monter la latence

• Un serveur de pool distant, sur un autre continent ou derrière un peering médiocre.
• Un VPN, un proxy, un NAT saturé, du Wi-Fi ou du CPL sur le plan de contrôle.
• Un CPU de contrôleur saturé par une interface lourde, des logs, ou plusieurs pools mal gérés.
• De la perte de paquets, qui déclenche des retransmissions.
• Une horloge système fortement dérivée, qui produit des rejets portant un motif de type « time ».

Un failover mal réglé, trop nerveux ou trop lent, génère lui aussi des rafales de stales au moment des bascules.

Ce qu'un share n'est pas

Un share n'est pas un satoshi. Le passage du share au paiement dépend du schéma de rémunération, FPPS, PPLNS ou autre, et des frais du pool. Un pic de shares ne prouve pas que la machine mine mieux si la difficulté de share a baissé au même moment.

La comparaison qui a du sens est celle entre le hashrate effectif, calculé à partir des shares et de la difficulté de share, et le hashrate affiché par le firmware. Un écart persistant entre les deux se diagnostique ; il ne se compense pas.

Les cinq mesures à prendre ensemble

Sur une même fenêtre de temps, relevez : le RTT vers le serveur stratum réellement utilisé, les taux accepted, stale et rejected, la hauteur de job, le hashrate côté pool, et le hashrate côté machine. Ces cinq valeurs prises ensemble identifient la cause ; prises isolément, elles orientent presque toujours vers la mauvaise.

Ensuite, ne changez qu'une variable à la fois : URL géographique du pool, câble, ou pool de secours. Et gardez toujours un failover configuré, sur un seul agent, pour qu'une coupure côté pool ne se transforme pas en heures de hashrate perdues.