Mining Latency es el retraso en una parte concreta del proceso de minería, por ejemplo entre el envío de un encargo desde el pool y su activación en la máquina. No es una propiedad universal de la conexión. Transmitir, esperar en una cola, procesar y confirmar resultados son etapas distintas, que se miden de maneras diferentes.
El pool prepara un encargo para Petr y lo envía al software de minería. Este puede transmitirlo a través de un intermediario, un proxy, hasta el ASIC, un chip diseñado para minar. Lo importante es el cambio efectivo al nuevo trabajo, no solo que el mensaje llegue al ordenador. La máquina envía después shares, resultados parciales con los que demuestra su trabajo al pool. En Stratum V2, el protocolo que regula la comunicación entre equipos de minería, channel_id y job_id vinculan los mensajes con el canal y el encargo correctos. Sin esa relación podríamos medir el comienzo de un trabajo y el final de otro. [1]
Petr prueba ping siguiendo las instrucciones de diagnóstico de Braiins. Así comprueba si el servidor responde y cuánto tardan la solicitud y su respuesta en ir y volver: RTT, o round-trip time. Es un primer paso útil. Pero cada sentido puede seguir otra ruta y tener otras esperas, por lo que dividir entre dos no mide el retraso de un solo trayecto. Ping tampoco indica cuánto tarda el pool en preparar el trabajo ni el ASIC en iniciarlo. Un resultado bueno puede coexistir con cambios de encargo lentos. [2] [3]
En nuestro ejemplo, el emisor registra Tsend = 1000 ms y el receptor Trecv = 1040 ms. La diferencia es de 40 ms, pero el reloj receptor podría ir adelantado 30 ms. Restar sin más no daría entonces el tiempo real de transmisión. ms significa milisegundos, milésimas de segundo. Por eso la norma de medición de redes RFC7679 considera la incertidumbre de sincronización y el lugar donde se toman las marcas de tiempo. Sin esos datos, una diferencia entre servidores no demuestra una mejora de velocidad; quizá solo refleja relojes ajustados de manera distinta. [3]
Para no esperar el encargo completo tras un bloque nuevo, Stratum V2 permite enviar antes un Future Job. Es trabajo preparado para enlazar con un futuro estado de la cadena, no una orden de empezar inmediatamente. SetNewPrevHash lo activa con la referencia correcta al bloque anterior y el job_id correspondiente. Si contiene transacciones, el nuevo bloque puede hacer que algunas ya no sean utilizables, por ejemplo porque ya las contiene. Reducir la latencia no justifica ignorar ese conflicto. Empezar deprisa un trabajo incorrecto no ahorra tiempo útil. [1]
Petr ve salir una share, pero su confirmación llega después. En Stratum V2, SubmitShares.Success puede resumir varias shares aceptadas a la vez; agruparlas deliberadamente reduce el tráfico de mensajes. No podemos atribuir toda la espera a la transmisión ni afirmar que el pool desconoció el resultado durante ese tiempo. SubmitShares.Error también puede llegar después de una comprobación posterior. sequence_number ayuda a relacionar respuestas y resultados enviados. Al buscar un fallo, conviene separar recepción, comprobación y notificación. [1]
La minería también necesita enterarse pronto de que alguien publicó un bloque. Es otra etapa, distinta de la conexión entre máquina y pool. BIP152 reduce los datos que se transmiten entre nodos: en modo high-bandwidth, un nodo puede enviar directamente cmpctblock, una descripción compacta del bloque. El receptor completa la mayoría de las transacciones con sus propios datos. Pide las que le faltan mediante getblocktxn y las recibe en blocktxn, lo que puede añadir otro intercambio. Menos datos no significa ausencia de espera ni sustituye la validación completa de las reglas del bloque. [4]
A Petr le importa el funcionamiento habitual y también los momentos en que algo se atasca. p50/p95 son percentiles: muestran distintas zonas de la distribución de tiempos medidos, en lugar de una sola media. Al ordenar los tiempos de menor a mayor, p50 queda aproximadamente en el centro y p95 cerca del extremo más lento: alrededor del 50 % de los valores queda por debajo del primer umbral y el 95 % por debajo del segundo. Así se distingue la espera habitual de los retrasos largos. Pero hay que explicar qué ocurrió con los mensajes no entregados. RFC7679 utiliza un límite de espera, Tmax; superarlo no es una medición rápida normal. En su cálculo de percentiles, los retrasos indefinidos se ordenan como infinitos. Omitirlos sin avisar mejoraría la imagen solo sobre el papel. Una muestra vacía tampoco significa latencia cero, sino falta de datos para concluir. [3]
Petr compara las mismas etapas, con cargas similares y períodos de igual duración. Para cada medición en ms anota dónde se tomó la marca de tiempo, la incertidumbre de los relojes y el job_id correspondiente; mantiene ping y RTT aparte. Añade interrupciones y resultados rechazados para que una media rápida no oculte falta de fiabilidad. Así puede investigar si conviene cambiar de servidor, red o configuración. Se trata de perder menos tiempo en trabajo obsoleto, no de prometer encontrar un bloque. Una latencia baja no cambia el azar de la minería ni las reglas de validez. [1] [2] [3]
Para obtener la imagen más completa, lee esta entrada junto con Stale Rate, Block Propagation, Stratum V2, Mining Pool, Bitcoin. También enlazan con esta entrada Stratum V2, Stale Rate.