Mining Latency

Le pool prépare un travail pour Petr et l’envoie au logiciel de minage. Celui-ci peut transmettre le message par un intermédiaire, un proxy, jusqu’à l’ASIC, une puce conçue pour miner. Ce qui compte, c’est le passage effectif au nouveau travail, pas seulement l’arrivée du message sur un ordinateur. La machine envoie ensuite des shares, des résultats partiels qui attestent son travail auprès du pool. Dans Stratum V2, le protocole qui organise la communication entre équipements de minage, channel_id et job_id relient les messages au bon canal et à la bonne tâche. Sans ce lien, on pourrait mesurer le début d’un travail et la fin d’un autre. [1]

Petr essaie ping en suivant le diagnostic de Braiins. Il vérifie ainsi que le serveur répond et mesure le trajet aller de la demande et retour de la réponse : le RTT, ou round-trip time. C’est une première étape utile. Mais les deux sens peuvent suivre des routes et des files d’attente différentes ; diviser par deux ne mesure donc pas le délai à sens unique. Ping n’indique pas non plus le temps de préparation du pool ni celui nécessaire à l’ASIC pour commencer. Un bon résultat peut ainsi coexister avec un changement de tâche lent. [2] [3]

Dans notre exemple, l’émetteur note Tsend = 1000 ms et le récepteur Trecv = 1040 ms. La différence vaut 40 ms, mais l’horloge du récepteur pourrait avancer de 30 ms. Une simple soustraction ne donnerait alors pas la durée réelle de transmission. ms signifie millisecondes, des millièmes de seconde. La norme de mesure des réseaux RFC7679 prend donc en compte l’incertitude de synchronisation et l’endroit où les horodatages sont pris. Sans ces informations, une différence entre serveurs ne prouve pas un gain de vitesse ; elle peut simplement refléter un réglage différent des horloges. [3]

Pour éviter d’attendre un travail complet après un nouveau bloc, Stratum V2 permet d’envoyer un Future Job à l’avance. Il est préparé pour un futur rattachement à la chaîne, mais ce n’est pas une instruction de démarrage immédiat. SetNewPrevHash l’active avec la bonne référence au bloc précédent et le job_id correspondant. S’il contient des transactions, le nouveau bloc peut rendre certaines inutilisables dans le travail suivant, par exemple parce qu’il les contient déjà. Réduire la latence n’autorise pas à ignorer ce conflit. Démarrer vite un travail incorrect n’est pas une économie utile. [1]

Petr voit partir une share, puis attend sa confirmation. Dans Stratum V2, SubmitShares.Success peut récapituler plusieurs shares acceptées ; ce regroupement volontaire limite le trafic de messages. Toute l’attente ne peut donc pas être attribuée au transport, ni servir à affirmer que le pool ignorait le résultat pendant ce temps. SubmitShares.Error peut aussi suivre une vérification ultérieure. sequence_number aide à rattacher les réponses aux résultats envoyés. Pour diagnostiquer un problème, distinguons réception, vérification et notification. [1]

Le minage doit aussi apprendre rapidement qu’un bloc a été publié. Cette étape est distincte de la liaison entre machine et pool. BIP152 réduit les données échangées entre nœuds : en mode high-bandwidth, un nœud peut envoyer directement cmpctblock, une description compacte du bloc. Le destinataire retrouve la plupart des transactions dans ses propres données. Il demande les manquantes avec getblocktxn et les reçoit dans blocktxn, ce qui peut ajouter un échange. Moins de données ne signifie donc pas aucune attente et ne remplace pas la validation complète des règles du bloc. [4]

Petr s’intéresse au fonctionnement ordinaire, mais aussi aux moments où quelque chose se bloque. p50/p95 sont des percentiles : ils décrivent différentes parties de la distribution des temps mesurés, plutôt qu’une seule moyenne. En classant les temps du plus court au plus long, p50 se situe à peu près au milieu et p95 vers l’extrémité la plus lente : environ 50 % des valeurs sont sous le premier seuil et 95 % sous le second. On distingue ainsi l’attente habituelle des longs retards. Encore faut-il préciser le traitement des messages non livrés. RFC7679 utilise un seuil d’attente, Tmax ; le dépasser ne constitue pas une mesure rapide ordinaire. Dans son calcul de percentiles, les délais indéfinis sont classés comme infinis. Les supprimer sans le dire ne ferait qu’embellir les chiffres. Un échantillon vide ne signifie pas non plus une latence nulle, mais une absence de données pour conclure. [3]

Petr compare les mêmes étapes, à charge comparable et sur des périodes de même durée. Pour chaque mesure en ms, il note le lieu de l’horodatage, l’incertitude des horloges et le job_id concerné ; ping et RTT restent séparés. Il ajoute les interruptions et les résultats rejetés afin qu’une moyenne rapide ne cache pas un manque de fiabilité. Il peut alors chercher si un autre serveur, réseau ou réglage aiderait. Le but est de passer moins de temps sur un travail dépassé, pas de promettre la découverte d’un bloc. Une faible latence ne change ni le hasard du minage ni les règles de validité. [1] [2] [3]