Mining Latency est le délai d’une étape précise du minage : distribution ou activation du travail, transmission d’une share trouvée ou propagation d’un bloc candidat. Une valeur doit préciser les événements mesurés aux deux extrémités et les conditions d’observation.
Stratum V2 distingue distribution du travail et envoi des résultats. Le temps entre envoi et réception d’une tâche n’est pas celui entre réception et basculement effectif de l’ASIC ; le retour d’une share au pool est un autre trajet. Définissez les deux extrémités et reliez les relevés avec channel_id et job_id. [Stratum V2 — Mining Protocol]
Braiins présente ping comme un test d’accessibilité. Son RTT inclut l’aller et le retour ; le diviser automatiquement par deux ne mesure pas un délai unidirectionnel, car les directions peuvent être asymétriques. Ping ne mesure pas non plus création de tâche, file du proxy ou activation matérielle. Comparez le même trafic et les mêmes extrémités. [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
RFC7679 exige de tenir compte de la synchronisation des horloges et du point d’horodatage. Exemple : Tsend = 1000 ms et Trecv = 1040 ms donnent 40 ms seulement avec des horloges comparables. Un décalage de 30 ms chez le destinataire change l’interprétation. Sans estimation d’incertitude, une différence entre serveurs ne prouve pas une accélération. [RFC7679 — One-Way Delay Metric]
Dans Stratum V2, une Future Job peut arriver à l’avance ; le SetNewPrevHash correspondant avec job_id l’active. Mesurez donc aussi le délai d’activation, pas seulement le téléchargement du modèle. Une tâche anticipée non vide peut contenir une transaction déjà incluse dans le nouveau bloc ; distribuer plus vite ne permet pas d’ignorer ce conflit ni de miner un bloc invalide. [Stratum V2 — Mining Protocol]
Stratum V2 autorise SubmitShares.Success par lots. L’attente de réponse peut inclure un regroupement volontaire ; ce n’est ni un pur délai réseau ni la preuve que la share attendait son acceptation pendant tout ce temps. SubmitShares.Error peut arriver après une validation différée. Associez sequence_number et distinguez envoi, réception, validation et accusé. [Stratum V2 — Mining Protocol]
En mode high-bandwidth, BIP152 envoie cmpctblock sans demande préalable. Si des transactions manquent au destinataire, getblocktxn et blocktxn ajoutent un échange. Il s’agit du relais de blocs entre nœuds, pas d’une mesure d’envoi de shares. Moins de données ne garantit pas un délai nul et ne remplace pas la validation complète. [BIP152 — Compact Block Relay]
RFC7679 définit une limite Tmax et traite un paquet non livré comme un délai indéfini ; son percentile classe ces valeurs comme infiniment grandes. Pour vos p50/p95, précisez méthode, nombre d’échantillons et pertes. Exclure toutes les expirations peut embellir le résultat ; un échantillon vide n’est pas une latence nulle. [RFC7679 — One-Way Delay Metric]
Lors d’un changement de trajet ou de réglage, gardez du matériel, des fenêtres temporelles et des définitions comparables. Suivez séparément activation de job_id, accusés du travail, motifs de rejet et coupures ; une baisse du ping RTT ne prouve pas la réduction de chaque délai. C’est une méthode comparative, ni promesse de trouver un bloc ni limite sûre universelle en ms. [Stratum V2 — Mining Protocol] [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
Pour une vision complète, lisez aussi Stale Rate, Block propagation, Stratum V2, Mining Pool. Cette entrée est également citée par Stale Rate.