Dos señales procedentes de dos capas diferentes

Cuando una operación de minería presenta un comportamiento irregular, a menudo se mezclan dos tipos de información distintos: un contador de errores de hardware que aumenta en la placa de control de un minero, y un número de shares rechazados que crece en el panel del pool. Son fenómenos relacionados, pero se generan en capas diferentes del proceso de minería y no miden lo mismo.

Un error de hardware es telemetría del lado del minero: una condición reportada por el ASIC, su placa de control o el firmware. Un share rechazado es un resultado de validación del lado del pool: una decisión que toma el pool sobre una pieza concreta de trabajo enviada. Tratar uno como prueba del otro puede llevar a un operador a reemplazar una hashboard cuando el problema real es una ruta de red congestionada, o a descartar un fallo de chip genuino porque el panel del pool parece normal.

Este artículo separa ambas señales, explica qué indica de forma fiable cada una, y describe un orden práctico de investigación cuando solo una de las dos aparece anómala.

Qué reportan realmente los errores de hardware del ASIC

En la mayoría de los mineros ASIC, la interfaz de estado muestra un contador de errores de hardware (comúnmente etiquetado como HW o HW errors) junto con campos como el estado del ASIC, el recuento de chips detectados por hashboard y el hashrate reportado. La propia documentación de Bitmain para su página de estado define estos campos por separado: HW refleja errores de hardware o de cálculo reportados por el minero, un estado de ASIC de "0" indica un chip normal, y un valor distinto de cero o "X" puede indicar un chip que no funciona, mientras que un campo separado reporta el número de chips en funcionamiento detectados en una hashboard (Bitmain Support).

Un aumento en el contador de errores HW no es, por sí solo, una prueba concluyente de fallo de hardware. Bitmain señala que algunos errores de hardware pueden ocurrir durante el funcionamiento normal a plena capacidad de cómputo y pueden corregirse internamente sin interrumpir el hashing. Un contador que aumenta lentamente frente a un hashrate local estable, un recuento completo de chips y temperaturas normales es, en general, una señal más débil que un patrón que combina varios indicadores a la vez: caída del hashrate local, una hashboard que reporta menos chips de los esperados, eventos repetidos de protección térmica, fallos en el ventilador o en la fuente de alimentación, o un registro del dispositivo que muestra que no puede detectar los chips de una placa. Esa combinación apunta a una condición a nivel de dispositivo que vale la pena aislar mediante los registros de diagnóstico propios del minero, en lugar de a través de los datos del pool.

Dado que los contadores de errores HW, su comportamiento de reinicio y su significado exacto están definidos por el firmware de cada fabricante, no deben compararse entre distintos modelos de ASIC como si fueran una métrica única y estandarizada.

Qué reportan realmente los shares rechazados

En la minería en pool, un minero no envía bloques completados al pool; envía shares — resultados de prueba de trabajo (proof-of-work) que cumplen el objetivo de share del pool. El objetivo de share de un pool se fija numéricamente más alto que el objetivo de bloque de la red de Bitcoin, lo que lo hace más fácil de satisfacer y corresponde a una dificultad menor que encontrar un bloque real; los shares permiten al pool medir cuánto trabajo está aportando cada minero entre bloques (Bitcoin Developer Guide).

Un share rechazado es el término general para cualquier share enviado que el pool no acepta. El motivo específico suele ser una de varias subcategorías, no un sinónimo del propio "share rechazado":

• Share obsoleto (stale share) — trabajo que era válido para un trabajo de minería anterior, pero que llegó después de que ese trabajo dejara de estar vigente.
• Share inválido (invalid share) — un envío que no supera las comprobaciones de validación del pool.
• Share duplicado (duplicate share) — el mismo share enviado más de una vez.

Bitmain describe la tasa de rechazo de un pool de minería como la proporción de datos rechazados por el pool respecto al total de datos enviados por el minero, e identifica la inestabilidad de la red como una causa principal de una tasa elevada (Bitmain Support). Esto es relevante para el diagnóstico: un grupo de shares obsoletas (stale shares) suele reflejar condiciones de tiempo o conectividad entre el minero y el endpoint del pool, no un fallo a nivel de chip. Las shares inválidas, en cambio, a veces pueden derivarse de ajustes de minería inestables, problemas de firmware o un suministro eléctrico irregular — condiciones que también afectan al comportamiento del hardware —, por lo que un aumento en las shares inválidas es un indicio más razonable (aunque aún no concluyente) para revisar el propio dispositivo.

Cuando un pool informa los recuentos de aceptadas y rechazadas para el mismo periodo, se puede calcular un porcentaje de rechazo bruto de la siguiente manera:

Rejected share count ÷ (Accepted share count + Rejected share count) × 100

Esta cifra solo es significativa cuando los recuentos de aceptadas y rechazadas cubren la misma ventana temporal y la misma configuración de dificultad de share; si la dificultad de share cambió durante el periodo, los recuentos brutos ya no representan cantidades de trabajo comparables. El resultado tampoco debe interpretarse como un porcentaje directo de ingresos en BTC perdidos, ya que los ingresos dependen del trabajo realmente aceptado, del cálculo de pago del pool y del momento en que se encuentran los bloques, no de una simple proporción de shares.

Por qué se confunden ambas señales

La confusión entre errores de hardware y shares rechazadas suele surgir de dos hábitos: asumir que cualquier indicador en rojo en cualquier pantalla significa el mismo tipo de problema, y comparar cifras que se midieron en ventanas distintas o mediante sistemas distintos. La pantalla local de un minero informa lo que el propio dispositivo observó: el estado de sus propios chips, sus propios contadores de errores, su propia tasa de hash calculada. Un panel de control del pool informa lo que el pool observó a partir de las shares que recibió, lo cual depende de la salida del minero, pero también de la ruta de red, el intervalo de reporte y la propia lógica de validación del pool.

Ambas señales pueden moverse juntas cuando un problema real de hardware hace que el minero produzca trabajo inestable o inválido que el pool luego rechaza. Pero también pueden moverse de forma independiente: un ASIC perfectamente sano puede mostrar una alta tasa de shares obsoletas debido a un endpoint de pool congestionado o distante, y un minero con una inestabilidad de hardware incipiente puede seguir mostrando una tasa de rechazo poco llamativa si el pool aún no ha recibido suficientes envíos afectados como para que el patrón sea visible.

Un enfoque práctico de diagnóstico

En lugar de reaccionar a cualquiera de las dos cifras de forma aislada, resulta útil leer la señal específica y contrastarla con un breve conjunto de preguntas antes de concluir cuál es el problema.

Si el contador de errores de hardware está aumentando, verifique si la tasa de hash local, el número de chips y las temperaturas se mantienen estables. Si es así, el contador por sí solo constituye una evidencia más débil de un fallo. Si la tasa de hash local está cayendo, faltan chips, o también se registran fallos térmicos o de ventilador, el propio dispositivo merece una inspección más detallada, empezando por los propios registros del minero.

Si las shares rechazadas están aumentando, verifique qué subcategoría predomina. Un patrón concentrado en shares obsoletas apunta primero hacia la ruta de conexión —el endpoint de pool elegido, el enrutamiento o el comportamiento de reconexión— en lugar de hacia las placas de hash. Un patrón concentrado en shares inválidas es un indicio más razonable para revisar cambios recientes de firmware o de ajuste, la estabilidad eléctrica y la refrigeración, junto con los propios registros de errores del dispositivo.

En cualquiera de los dos casos, confirme si el patrón afecta a un solo worker o a muchos workers conectados por la misma ruta. Un problema aislado en un solo dispositivo apunta hacia ese dispositivo; un problema que afecta simultáneamente a varios mineros por lo demás independientes apunta hacia un elemento compartido, como la conexión de red o el endpoint del pool.

Por qué las cifras de hashrate local y del pool pueden no coincidir

Otra fuente de confusión relacionada es el desajuste entre el hashrate mostrado en la pantalla propia del minero y el hashrate mostrado en el panel del pool. No son cifras intercambiables: el hashrate local es una estimación reportada por el dispositivo utilizando el método de actualización y promediado propio del fabricante, mientras que el hashrate de un pool es una estimación derivada de las shares que realmente recibió durante una ventana determinada.

El panel de ViaBTC, por ejemplo, calcula el hashrate en tiempo real como un promedio móvil de los 10 minutos anteriores y el hashrate diario como un promedio móvil de las 24 horas anteriores (ViaBTC). Tras un reinicio o una breve desconexión, el hashrate local de un minero puede volver a la normalidad en cuestión de minutos, mientras que la cifra de 24 horas del pool puede permanecer más baja durante más tiempo simplemente porque el tiempo de inactividad anterior todavía está dentro de esa ventana móvil. Esto es un efecto de la ventana de medición, no evidencia independiente de un error de hardware o un problema del lado del pool, y debe comprobarse comparando las cifras en períodos de tiempo equivalentes antes de considerar que cualquiera de las dos señales confirma un fallo.

Conclusión

Un contador de errores de hardware y un recuento de shares rechazadas responden a preguntas diferentes: uno describe lo que el propio ASIC reportó, el otro describe lo que el pool decidió sobre el trabajo enviado. Leer el motivo específico de rechazo, comprobar si una señal de hardware va acompañada de otros síntomas a nivel de dispositivo, y alinear las ventanas de medición antes de comparar cifras generalmente conducirá a un diagnóstico más preciso que tratar cada indicador rojo como el mismo tipo de fallo.

Preguntas frecuentes

¿Un aumento en el contador de errores de hardware (HW-error) siempre significa que una placa de hash está fallando?

No necesariamente. Algunos errores de hardware pueden ocurrir durante el funcionamiento normal y corregirse sin interrumpir el hashing. Un aumento persistente acompañado de una caída del hashrate local, chips faltantes, o fallos térmicos y de ventilador es una evidencia más sólida de un problema real del dispositivo que el contador por sí solo.

¿Son las shares obsoletas (stale), inválidas y duplicadas tres tipos de problemas equivalentes?

Todas son subcategorías del resultado más amplio de "share rechazada", no métricas paralelas independientes. Cada una apunta a una causa probable diferente: las shares obsoletas apuntan a problemas de sincronización o conectividad, las shares inválidas apuntan a una posible inestabilidad de hardware o configuración, y las shares duplicadas apuntan a envíos repetidos debido al comportamiento del software o la conexión.

¿Puedo usar un porcentaje de rechazo para estimar los ingresos de minería perdidos?

Un porcentaje de rechazo bruto, calculado a partir de los recuentos de shares aceptadas y rechazadas correspondientes durante el mismo período, describe la proporción de trabajo enviado que el pool no aceptó. No es una métrica estandarizada de pérdida de ingresos, ya que los pagos reales dependen de la contabilidad del pool, la dificultad de las shares y el momento de encontrar bloques, y no únicamente de la relación bruta.

¿Por qué la pantalla de mi minero muestra un hashrate diferente al del panel del pool?

Ambos utilizan métodos de medición y ventanas de tiempo distintos. La pantalla local de un minero es una estimación reportada por el dispositivo, mientras que el panel del pool refleja las shares realmente recibidas durante un período móvil determinado. Es más probable que las diferencias sean un efecto de la ventana de reporte que evidencia de un fallo de hardware o del pool, particularmente después de un reinicio reciente.

Referencias

• Bitcoin Developer Guide, "Mining" — https://developer.bitcoin.org/devguide/mining.html
• Bitmain Support, "Miner Status Page Explained" — https://support.bitmain.com/hc/en-us/articles/360013577314-Miner-Status-Page-Explained
• Bitmain Support, "The Rejection Rate of Mining Pools" — https://support.bitmain.com/hc/en-us/articles/5220664696473-The-rejection-rate-of-mining-pools
• ViaBTC, "Mining Pool with Real-Time Hashrate Monitoring: Understanding Measurement Windows and Latency Effects" — https://www.viabtc.com/en/blog/Mining-mining-pool-with-real-time-hashrate-monitoring-understanding-measurement-windows-and-latency-effects-941