Qué mide el tiempo de actividad ponderado por potencia de cómputo

El tiempo de actividad ponderado por potencia de cómputo (hashrate-weighted uptime) es un cálculo de disponibilidad de flota que pondera el tiempo en línea de cada ASIC según su potencia de cómputo, en lugar de tratar cada máquina como una unidad intercambiable idéntica. Mide la disponibilidad en línea ponderada por la potencia de cómputo de referencia: la proporción del tiempo de hash de referencia de la flota asociado con el estado en línea durante un período determinado. No tiene en cuenta el rendimiento reducido mientras un minero está en línea.

Para calcularlo, se multiplica la potencia de cómputo de referencia de cada ASIC por su tiempo en línea, se suman los resultados, se divide entre la suma de la potencia de cómputo de referencia de cada ASIC multiplicada por el período de medición completo, y se multiplica por 100.

Este artículo utiliza el tiempo de actividad ponderado por potencia de cómputo como un cálculo de disponibilidad de flota explícitamente definido. Los operadores deben indicar la fórmula, las potencias de cómputo de referencia y la regla de estado en línea al reportarlo, junto con medidas como la potencia de cómputo local, la potencia de cómputo estimada por el pool y la tasa de rechazo.

Por qué el tiempo de actividad basado en el número de dispositivos induce a error en una flota mixta

Una tasa de tiempo de actividad simple basada en el número de dispositivos —por ejemplo, "18 de 20 mineros en línea"— trata cada ASIC como igualmente importante. En una flota homogénea de máquinas idénticas, esa aproximación es razonable. En una flota mixta que contiene, por ejemplo, unidades de 250 TH/s y 50 TH/s, no lo es: una máquina de alta potencia de cómputo fuera de línea elimina mucha más capacidad de hash de la flota que una máquina de baja potencia de cómputo fuera de línea, aunque ambas cuenten como "una unidad caída".

Considere dos escenarios de interrupción con la misma exposición de duración total. Si un único ASIC de 250 TH/s está fuera de línea durante cuatro horas, el tiempo de hash perdido es 250 × 4 = 1.000 (TH/s)·h. Cinco ASIC de 50 TH/s necesitarían estar fuera de línea durante cuatro horas cada uno para perder el mismo 1.000 (TH/s)·h (5 × 50 × 4 = 1.000). Una cifra de tiempo de actividad basada en el número de dispositivos reportaría estos dos escenarios de manera muy diferente —una unidad caída frente a cinco unidades caídas— aunque la capacidad de hash perdida por la flota sea idéntica. La ponderación por potencia de cómputo resuelve esto al expresar la disponibilidad en tiempo de hash en lugar de tiempo de dispositivo.

La fórmula

Para una flota de n ASIC observados durante el mismo período T, el tiempo de actividad ponderado por potencia de cómputo es:

Tiempo de actividad ponderado por potencia de cómputo (%) = [ Σ ( Href,i × t_en_línea,i ) ] ÷ [ Σ ( Href,i × T ) ] × 100

Donde:

• Href,i = la potencia de cómputo de referencia asignada al ASIC i, en TH/s
• t_en_línea,i = el tiempo que el ASIC i estuvo en línea durante el período
• T = el período de medición total, consistente para cada ASIC
• n = el número de ASIC incluidos

Tanto el numerador como el denominador multiplican la potencia de cómputo por el tiempo. Con la potencia de cómputo en TH/s y el tiempo en horas, las unidades son (TH/s)·h; se cancelan en la razón, que luego se multiplica por 100 para dar un porcentaje.

Una forma equivalente utiliza la fracción de tiempo de actividad individual de cada máquina, Ui = t_en_línea,i ÷ T. Introduzca Ui como un valor de 0 a 1 —por ejemplo, 23/24 ≈ 0,9583, no 95,83:

Tiempo de actividad ponderado por potencia de cómputo (%) = [ Σ ( Href,i × Ui ) ] ÷ [ Σ Href,i ] × 100

Esto es un promedio ponderado en el que las máquinas con mayor potencia de cómputo contribuyen más al resultado a nivel de flota que las máquinas con menor potencia de cómputo.

Ejemplo resuelto

Suponga un período de medición de 24 horas y tres ASIC:

El tiempo de hash máximo posible para el período es (200 + 100 + 50) × 24 = 8.400 (TH/s)·h. El tiempo de actividad ponderado por potencia de cómputo es, por tanto, 7.200 ÷ 8.400 × 100% = 85,71%.

Para comparar, un promedio simple de las tres cifras de tiempo de actividad individuales es (95,83% + 83,33% + 50,00%) ÷ 3 = 76,39%. Esa cifra otorga al Minero C —una unidad de 50 TH/s— la misma influencia en el resultado que al Minero A, una unidad de 200 TH/s. Para una flota mixta, no representa la disponibilidad en línea ponderada por la potencia de cómputo de referencia, que es lo que la cifra ponderada por potencia de cómputo está diseñada para mostrar.

Elegir una potencia de cómputo de referencia

El cálculo requiere una base consistente para Href en todo el período de reporte. En la práctica son comunes tres enfoques.

La potencia de cómputo nominal del fabricante utiliza la especificación de placa de cada modelo. Esto es apropiado para estimar la disponibilidad planificada o comparar con un plan de flota instalada, particularmente cuando las máquinas funcionan cerca de los ajustes de fábrica. Su principal limitación es que la potencia de cómputo nominal no necesariamente refleja el firmware real, el modo de energía o la reducción ambiental de rendimiento de una unidad determinada.

Una línea base medida localmente y documentada utiliza una cifra específica del sitio registrada para cada dispositivo o modelo bajo su configuración de funcionamiento prevista. Este enfoque es más apropiado cuando los mineros funcionan con subreloj (underclocked), sobrereloj (overclocked), o en múltiples modos de energía, o cuando el objetivo es medir la disponibilidad respecto al funcionamiento normal del sitio en lugar de la capacidad nominal. La línea base debe mantenerse constante durante todo el período de reporte; cambiarla a mitad de período sin separar los períodos hace que las comparaciones de mes a mes no sean fiables.

Una potencia de cómputo de referencia variable en el tiempo es apropiada cuando los modos de funcionamiento cambian intencionalmente durante el período de reporte. En ese caso, el cálculo debe realizarse por intervalo:

Tiempo de actividad ponderado por potencia de cómputo (%) = [ Σi Σk ( Hi,k,ref × si,k × Δtk ) ] ÷ [ Σi Σk ( Hi,k,ref × Δtk ) ] × 100

Donde Hi,k,ref es la potencia de cómputo de referencia seleccionada para el ASIC i durante el intervalo k, si,k es igual a 1 cuando el ASIC está en línea y 0 cuando está fuera de línea, y Δtk es la duración del intervalo. Esto evita que la potencia de cómputo configurada actualmente para una unidad se aplique incorrectamente a un período en el que estuvo vigente un ajuste diferente.

Definiendo "en línea": fuentes de datos y sus límites

El cálculo necesita una regla explícita y documentada de qué cuenta como "en línea" antes de aplicarse. Varias fuentes de datos pueden informar esa regla, y cada una observa algo diferente.

La telemetría de ASIC o de un sistema de gestión de granjas muestra el estado de conexión del dispositivo, el hashrate local, la temperatura y datos a nivel de placa, pero una máquina conectada puede seguir teniendo un rendimiento inferior en lugar de ser plenamente productiva. Los datos de monitorización de energía muestran si un minero o un circuito está consumiendo electricidad, pero el consumo de energía por sí solo no confirma un hashing productivo. Los paneles de los pools muestran shares recibidos, el hashrate estimado por el pool y datos de rechazo, pero estas cifras se basan en shares y están sujetas a la propia ventana de promediado del pool. Las alertas de worker fuera de línea (worker-offline) señalan la pérdida de actividad normal según la lógica de alertas del pool, pero el momento de la alerta no es necesariamente el inicio exacto de la interrupción.

Como práctica general, la telemetría del minero o del sistema de gestión es la fuente más directa para calcular el tiempo de actividad basado en estado, ya que refleja el estado del dispositivo en lugar de una estimación promediada derivada de la llegada de shares. Los datos del pool se utilizan mejor como verificación cruzada de si el trabajo enviado está llegando al pool, una distinción que se explica con más detalle a continuación.

El uptime no es lo mismo que el rendimiento del hashrate

Un minero puede estar en línea durante todo un periodo y, aun así, tener un rendimiento inferior debido a la limitación térmica (thermal throttling), una placa de hash degradada o un perfil de ajuste (tuning) inestable. Por ejemplo, un ASIC de 200 TH/s que permanece conectado las 24 horas pero promedia solo 160 TH/s localmente tiene un uptime basado en estado del 100%, aunque su hashrate local sea solo el 80% de su referencia seleccionada de 200 TH/s.

Por esta razón, el hashrate local medido realmente no debe sustituirse en el numerador de la fórmula del uptime, ya que hacerlo cambia lo que representa la métrica. Una comparación separada —el hashrate local medido frente a la línea base de referencia— puede ser útil para capturar conjuntamente tanto el tiempo de inactividad como la reducción de rendimiento (derating), pero debe etiquetarse como tal en lugar de reportarse como uptime.

El hashrate del pool como verificación cruzada, no como sustituto

En la minería en pool, un pool estima el hashrate de un worker o cuenta a partir de los shares que recibe, utilizando un objetivo de share que es más fácil de alcanzar que el objetivo de bloque de la red de Bitcoin, lo cual es lo que permite a los mineros enviar shares con la frecuencia suficiente para poder medirse (Guía para desarrolladores de Bitcoin). Esa estimación refleja el trabajo que llega al pool durante su ventana declarada; no es una medición directa y continua del estado del dispositivo.

El Centro de Ayuda de ViaBTC documenta que su cifra de hashrate en tiempo real se calcula a partir de los 10 minutos anteriores, mientras que su cifra de hashrate diario se calcula a partir de las 24 horas anteriores (Centro de Ayuda de ViaBTC). Para una verificación cruzada útil, utilice datos del pool que cubran la misma flota y exactamente las mismas horas de inicio y fin que el cálculo del uptime, con la zona horaria indicada explícitamente. Un informe de uptime por día calendario no necesariamente coincide con una lectura móvil del pool de las 24 horas anteriores; utilice datos históricos del pool alineados cuando estén disponibles. Incluso con ventanas coincidentes, las mediciones deben interpretarse conjuntamente con fines de diagnóstico en lugar de comparar directamente sus valores numéricos: el uptime es un porcentaje de disponibilidad basado en estado, mientras que el hashrate del pool es una estimación basada en shares expresada en unidades de hashrate. La misma documentación señala que la latencia de red, la tasa de rechazo, la configuración del hardware y la compatibilidad del firmware pueden contribuir todas ellas a una diferencia entre las lecturas de hashrate reportadas por el pool y las locales, lo cual es una cuestión de diagnóstico independiente del propio uptime.

Los shares rechazados deben revisarse junto con el uptime, pero no deben restarse de una cifra de uptime basada en estado, ya que los rechazos conciernen al trabajo enviado al pool y no a si el minero estuvo en línea según la definición operativa elegida. Cuando se utilizan notificaciones del lado del pool —ViaBTC documenta alertas configurables de hashrate y de tasa de rechazo, entregadas por correo electrónico, notificación push de la app y Telegram, junto con alertas de worker fuera de línea (Centro de Ayuda de ViaBTC)—, estas se tratan mejor como señales de monitorización que motivan una investigación, no como sustituto de la telemetría de flota con marcas de tiempo.

Errores comunes de cálculo

Varios errores se repiten al aplicar este cálculo en la práctica:

• Asignar a cada ASIC el mismo peso independientemente de su hashrate, lo cual reintroduce el problema del conteo de dispositivos que el cálculo pretende evitar.
• Mezclar hashrate nominal y hashrate local medido entre diferentes máquinas sin indicar qué línea base se utilizó en cada caso.
• Utilizar datos del pool correspondientes a una flota o ventana temporal distinta, incluyendo una lectura móvil de 24 horas que no coincide con las horas de inicio y fin del informe de uptime.
• Tratar una fluctuación de hashrate a corto plazo del lado del pool como prueba de inactividad del dispositivo sin comprobar la telemetría local.
• Contabilizar un ASIC conectado pero claramente con rendimiento reducido como fuera de línea, o viceversa, sin una regla documentada de lo que significa "en línea".
• Restar los shares rechazados de la cifra de uptime y luego, por separado, tratar un hashrate bajo del pool como una deducción adicional por tiempo de inactividad, lo cual cuenta doblemente el mismo problema subyacente.
• Combinar workers que cambiaron de modo de operación o de hashrate de referencia a mitad de periodo sin calcular por intervalos.

Preguntas frecuentes

¿Es el uptime ponderado por hashrate una métrica oficial de un pool de minería?

Aquí, el término se refiere al cálculo de disponibilidad de flota definido en este artículo, en lugar de a una métrica oficial atribuida a un pool en particular. Cualquier informe que lo utilice debe indicar explícitamente su fórmula, los hashrates de referencia y la regla de estado en línea.

¿Puede utilizarse el hashrate estimado por el pool en lugar de la telemetría del ASIC para calcular el uptime?

El hashrate estimado por el pool refleja los shares recibidos durante la ventana declarada por el pool y resulta útil como verificación cruzada, pero no equivale al estado del dispositivo y no debe reetiquetarse como uptime.

¿Debe utilizarse como valor de referencia el hashrate nominal o el hashrate local medido?

Se puede usar cualquiera de las dos opciones, siempre que la elección quede documentada y se mantenga constante durante el período de reporte; las líneas base locales medidas suelen ser más representativas cuando los mineros funcionan fuera de la configuración de fábrica.

¿Qué ocurre si el modo de funcionamiento de un ASIC cambia durante el período de reporte?

Debe utilizarse la versión de la fórmula basada en intervalos, de modo que cada valor de potencia de cómputo configurado se aplique únicamente al tiempo durante el cual estuvo realmente vigente.

¿Una tasa de rechazo alta significa que la flota tiene un uptime bajo?

No directamente. La tasa de rechazo concierne al resultado de las shares enviadas, mientras que el uptime concierne al estado de conexión de los dispositivos; ambos deben revisarse, pero uno no debe derivarse del otro.

Referencias

• Bitcoin Developer Guide, "Mining," developer.bitcoin.org — https://developer.bitcoin.org/devguide/mining.html
• ViaBTC Help Center, "Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine?" — https://support.viabtc.com/hc/en-us/articles/7574354263183-Why-is-the-Hashrate-Shown-in-the-Mining-Pool-Lower-than-that-of-the-Mining-Machine
• ViaBTC Help Center, "How to Set Hashrate or Rejection Rate Notification" — https://support.viabtc.com/hc/en-us/articles/7207414336143-How-to-Set-Hashrate-or-Rejection-Rate-Notification