¿Cuánta velocidad de internet y datos necesita un minero ASIC?
2026-10-19 11:29

Un minero ASIC conectado a un pool de minería necesita relativamente poco ancho de banda y datos. La guía publicada por Bitmain para sus ANTMINER estima aproximadamente 500 MB de uso de datos por minero al mes y señala que una conexión de 1 Mbps puede soportar hasta 150 mineros. Se trata de referencias de planificación genéricas, no de un requisito mínimo de velocidad de internet para cada minero. El minero realiza sus cálculos de prueba de trabajo (proof-of-work) de forma local; su conexión con el pool transporta los trabajos de minería y los envíos de shares. Una vez que se dispone de ancho de banda suficiente, la estabilidad de la conexión y la comunicación oportuna con el pool importan más que una velocidad de internet anunciada más alta (Soporte de Bitmain).

Ancho de banda frente a latencia

El ancho de banda (medido habitualmente en Mbps) describe cuántos datos puede mover una conexión por segundo. La latencia describe cuánto tiempo tarda un paquete en llegar al servidor del pool y volver. Se trata de propiedades distintas, y un minero ASIC es mucho más sensible a la segunda que a la primera.

En la minería ordinaria en pool, el tráfico de red del minero consiste en: establecer una conexión Stratum, recibir nuevos trabajos de minería, recibir un objetivo de dificultad de share actualizado cuando el pool utiliza dificultad variable, enviar shares que cumplan dicho objetivo, y reconectar si la conexión configurada se interrumpe. Nada de esto requiere transferir todos los hashes calculados por el minero, solo las shares que encuentra. Por ello, una máquina con mayor hashrate no genera un tráfico de red proporcionalmente mayor; los pools generalmente regulan la frecuencia de envío de shares mediante la dificultad variable, en lugar de permitir que el hardware más rápido sature la conexión. Braiins Academy, al documentar la implementación de su propio pool, apunta a aproximadamente 12 envíos de shares por minuto por worker, un ejemplo de configuración específico de ese pool y no una tasa universal, pero ilustra por qué es la frecuencia de envío, y no el hashrate, lo que determina el volumen de tráfico (Braiins Academy).

La guía publicada por Bitmain para sus ANTMINER ofrece dos referencias de planificación: una estimación de 500 MB de uso de datos por minero al mes, y una regla de dimensionamiento de ancho de banda de 1 Mbps por cada 150 mineros. Estas cifras provienen del mismo documento del fabricante y no son resultados medidos de forma independiente; no especifican un modelo concreto, una versión de firmware ni un pool determinado. Promediado a lo largo de un mes de 30 días, 500 MB equivalen aproximadamente a 1,54 Kbps de rendimiento continuo, mientras que la regla de 1 Mbps por cada 150 mineros implica unos 6,67 Kbps asignados por minero. Estas cifras miden cosas distintas: la estimación mensual describe la transferencia de datos acumulada, mientras que la regla de dimensionamiento de ancho de banda describe la capacidad de la conexión. Bitmain no explica la diferencia entre ambos valores. Los operadores deberían tratar ambas cifras como estimaciones de planificación y no como requisitos fijos (Soporte de Bitmain).

Medir el tráfico real

Dado que las estimaciones del fabricante son genéricas, la forma más fiable de dimensionar una conexión es observar el tráfico real del equipo en uso. La mayoría de los routers domésticos y para pequeñas empresas informan de la transferencia de datos por dispositivo o por puerto; los switches gestionados utilizados en implementaciones más grandes suelen mostrar el rendimiento por puerto y contadores de errores. Revisar estas cifras durante varios días proporciona una referencia realista, ya que el tráfico de minería se produce en ráfagas en torno a los cambios de trabajo y los envíos de shares, en lugar de ser constante.

Al escalar linealmente la estimación de Bitmain de 500 MB por minero al mes se obtiene un rango aproximado de planificación: un solo minero usaría aproximadamente 500 MB al mes; diez mineros, aproximadamente 5 GB; cien mineros, aproximadamente 50 GB; tres mil mineros, aproximadamente 1,5 TB. Se trata de simples proyecciones lineales a partir de una estimación del fabricante, no de un resultado medido en una implementación real, y excluyen cualquier otro tráfico que comparta la misma conexión: descargas de firmware, paneles de monitorización remota, cámaras de seguridad u otros dispositivos que compartan la red.

A escala de instalación, la guía de infraestructura de Bitmain, actualizada por última vez en julio de 2019, utiliza la fórmula ancho de banda (Mbps) = número de máquinas ÷ 150. Su ejemplo de 3.000 máquinas especifica al menos 20 Mbps de subida y 20 Mbps de bajada en cada conexión de banda ancha empresarial, dentro de un diseño que utiliza al menos dos proveedores de servicios de internet. Se trata de una referencia de planificación publicada por el fabricante para grandes centros de minería, no de un resultado medido de forma independiente ni de un requisito universal para toda operación minera. Los operadores también deberían prever un margen para la monitorización, la administración remota y otro tráfico que comparta sus conexiones (Soporte de Bitmain).

Comparar conexiones cableadas y enlaces de respaldo

La documentación de Bitmain indica que las unidades ANTMINER se conectan mediante Ethernet y no admiten Wi-Fi. Se trata de una afirmación sobre el hardware ANTMINER en particular, y no de una afirmación aplicable a todas las marcas de ASIC, pero las conexiones cableadas son generalmente preferibles en las implementaciones de minería porque ofrecen una latencia más consistente y menos paquetes perdidos que los enlaces inalámbricos, especialmente en instalaciones con muchos dispositivos y posible interferencia.

Más allá del tipo de conexión física, configurar un puerto de conexión alternativo —cuando el firmware del minero admite varias direcciones Stratum— puede ayudar si no se puede alcanzar el puerto principal. La documentación actual de ViaBTC para la minería de BTC enumera los siguientes endpoints en el mismo dominio y recomienda configurar varios puertos:

stratum+tcp://btc.viabtc.io:3333
stratum+tcp://btc.viabtc.io:443

Según la guía de ViaBTC, si el minero no puede conectarse utilizando la primera entrada configurada, puede cambiar al siguiente puerto configurado y continuar minando (ViaBTC Support). Esto no aumenta el hashrate de un minero ni reduce su consumo de datos; es una medida de continuidad de conexión, y el comportamiento real de conmutación por error depende de cómo el firmware específico del minero gestione las múltiples entradas de pool configuradas. Dado que estas entradas utilizan el mismo dominio y la misma conexión a internet, cambiar de puerto no ofrece protección frente a un corte del ISP ni frente a un fallo de DNS que afecte a ese dominio, y no sustituye una conexión a internet de respaldo.

Verifique los límites de datos y los cortes de servicio

Para los operadores que usan conexiones móviles, satelitales u otras conexiones con medición de datos, la asignación mensual de datos importa más que la velocidad máxima. La estimación de Bitmain de 500 MB por minero al mes es un punto de partida razonable para presupuestar frente a un límite de datos, aunque el consumo real puede ser mayor si el despliegue también incluye software de monitoreo remoto, actualizaciones de firmware o un nodo de Bitcoin ejecutado localmente.

La minería con ASIC conectada a un pool no requiere que el minero descargue la blockchain completa de Bitcoin. Si usted ejecuta por separado un nodo completo de Bitcoin, presupueste su sincronización y su tráfico de red continuo además del tráfico del minero hacia el pool (Bitcoin.org).

Los cortes de servicio generalmente son más perjudiciales para la minería que una conexión temporalmente más lenta, ya que un minero desconectado deja de enviar shares hasta que se reconecta. Al evaluar una conexión para minería, es razonable considerar la fiabilidad documentada del proveedor, si el servicio tiene antecedentes de cortes prolongados, y si una fuente de internet de respaldo —como un ISP secundario o una conmutación por error celular— se justifica por la escala de la operación. Esto es una compensación entre costo y riesgo que depende del tamaño del despliegue, más que un requisito fijo.

Valide los shares aceptados

Un share rechazado es la categoría general que normalmente reporta el panel de control de un pool; los shares obsoletos (stale), inválidos y duplicados son motivos específicos de rechazo dentro de esa categoría, no categorías separadas al mismo nivel. Un share obsoleto (stale) es, en general, aquel que se envía después de que el trabajo correspondiente ha quedado desactualizado; por ejemplo, después de que la red haya avanzado a un nuevo bloque y el pool haya distribuido un nuevo trabajo. La latencia de red y la pérdida de paquetes pueden contribuir a que se generen shares obsoletos o rechazados al retrasar tanto la entrega de nuevos trabajos al minero como el envío de un share encontrado de vuelta al pool.

Sin embargo, las condiciones de red no son la única causa posible. Los shares rechazados también pueden ser resultado de problemas del lado del minero, como errores de firmware, una configuración incorrecta del pool o del worker, o fallos de hardware, así como de las reglas de validación del lado del pool. Antes de atribuir un patrón de rechazos a la conexión a internet, conviene revisar los propios registros (logs) del minero y los códigos de motivo de rechazo del pool, cuando el panel los proporciona, en lugar de asumir una única causa.

También ayuda mantener separadas las distintas mediciones al diagnosticar un problema. El hashrate reportado localmente por un minero es una lectura del lado del dispositivo; el hashrate mostrado por el pool es una estimación separada, del lado del pool, derivada de los shares enviados durante una ventana de tiempo determinada. Debido a que el envío de shares es probabilístico, es de esperar que existan diferencias a corto plazo entre estas dos lecturas, y esto no indica necesariamente un problema de hardware o de red; comparar ventanas de tiempo más largas y equivalentes ofrece una imagen más fiable que reaccionar ante una caída puntual de corto plazo.

Preguntas frecuentes

¿Una internet más rápida aumenta el hashrate?

No. El hashrate es una función de los chips ASIC y sus condiciones de funcionamiento; se calcula localmente y no aumenta por tener una conexión a internet más rápida. Una conexión estable ayuda al minero a enviar shares y recibir nuevos trabajos con prontitud, pero no cambia el rendimiento computacional del dispositivo.

¿Puede un ASIC minar con internet móvil o satelital?

En principio puede funcionar, ya que los volúmenes de datos involucrados son generalmente modestos, pero las conexiones móviles y satelitales suelen presentar mayor latencia, pérdida de paquetes variable y límites de datos estrictos. Revisar la asignación de datos del plan específico frente a una estimación como la de Bitmain de 500 MB por minero al mes, y probar la estabilidad de la conexión durante varios días, es una forma razonable de evaluar su idoneidad antes de comprometerse.

¿Cuántos datos consume una granja de minería?

Usando la estimación publicada por Bitmain de aproximadamente 500 MB por minero al mes como cifra de planificación lineal, un sitio con 100 mineros consumiría del orden de 50 GB al mes, y un sitio con 3.000 mineros, del orden de 1,5 TB al mes, sin incluir los sistemas de monitoreo, las actualizaciones de firmware ni ninguna otra infraestructura que comparta la misma conexión.

¿Por qué el pool muestra un hashrate menor que la interfaz del minero?

La cifra mostrada por el pool es una estimación basada en shares durante una ventana de tiempo definida, mientras que la pantalla local del minero refleja la medición propia del dispositivo. Las diferencias a corto plazo son normales porque el descubrimiento de shares es probabilístico; si la diferencia persiste durante una ventana más larga, conviene verificar si existen problemas de conectividad o una tasa elevada de shares rechazados, en lugar de asumir un fallo de hardware a partir de una sola lectura.

Referencias