Mining Latency es la demora de una etapa concreta de minería: distribución o activación del trabajo, entrega de una share encontrada o propagación de un bloque candidato. El valor debe indicar los eventos extremos medidos y las condiciones de observación.
Stratum V2 distingue la distribución del trabajo del envío de resultados. El tiempo entre enviar y recibir una tarea no es el tiempo entre recibirla y el cambio efectivo del ASIC; devolver una share al pool es otro trayecto. Defina ambos extremos y correlacione los registros mediante channel_id y job_id. [Stratum V2 — Mining Protocol]
Braiins describe ping como prueba de accesibilidad. Su RTT incluye ida y vuelta; dividirlo automáticamente por dos no mide la latencia unidireccional, pues las direcciones pueden ser asimétricas. Ping tampoco mide la construcción de tareas, la cola del proxy ni la activación del dispositivo. Compare el mismo tipo de tráfico y extremos. [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
RFC7679 exige considerar la sincronización de relojes y dónde se registra la marca temporal. Ejemplo: Tsend = 1000 ms y Trecv = 1040 ms dan 40 ms solo con relojes comparables. Un desfase de 30 ms en el receptor cambia la interpretación. Sin estimar la incertidumbre, una diferencia entre servidores no demuestra aceleración. [RFC7679 — One-Way Delay Metric]
En Stratum V2, una Future Job puede llegar antes; la activa el SetNewPrevHash correspondiente con job_id. Mida también la demora de activación, no solo la descarga de la plantilla. Una tarea anticipada no vacía puede contener una transacción ya incluida en el nuevo bloque; distribuir más rápido no justifica ignorar el conflicto ni minar un bloque inválido. [Stratum V2 — Mining Protocol]
Stratum V2 permite SubmitShares.Success por lotes. Esperar la respuesta puede incluir agrupación intencionada; no es tiempo puramente de red ni prueba de que la share esperase aceptación todo ese tiempo. SubmitShares.Error puede llegar tras una validación demorada. Correlacione sequence_number y distinga envío, recepción, validación y confirmación. [Stratum V2 — Mining Protocol]
En modo high-bandwidth, BIP152 envía cmpctblock sin solicitud previa. Si al receptor le faltan transacciones, getblocktxn y blocktxn añaden otro intercambio. Es transmisión de bloques entre nodos, no medición del envío de shares. Transferir menos datos no garantiza demora nula ni sustituye la validación completa. [BIP152 — Compact Block Relay]
RFC7679 define el límite Tmax y trata un paquete no entregado como demora indefinida; para su percentil, estos valores se ordenan como infinitamente grandes. En sus p50/p95, indique método, número de muestras y pérdidas. Excluir todos los tiempos agotados puede mejorar la apariencia del resultado; una muestra vacía no es latencia cero. [RFC7679 — One-Way Delay Metric]
Al cambiar ruta o configuración, mantenga dispositivos, ventanas temporales y definiciones comparables. Observe por separado activación de job_id, confirmaciones, motivos de rechazo y cortes; no confunda menor ping RTT con una reducción demostrada de cada demora. Es un método de comparación, no promesa de encontrar un bloque ni límite seguro universal en ms. [Stratum V2 — Mining Protocol] [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
Para obtener la imagen más completa, lee esta entrada junto con Stale Rate, Propagación de bloques, Stratum V2, Mining Pool. También enlazan con esta entrada Stale Rate.