Por qué baja el hashrate en el pool y cómo reducir las shares rechazadas
A muchos mineros les pasa: el equipo parece funcionar bien, pero el panel del pool muestra menos hashrate, más errores y un porcentaje creciente de shares rechazadas, y los ingresos bajan. Esto no siempre significa que el ASIC esté fallando. Muchas veces la causa está en la red, la configuración o la distancia hasta el servidor.
En esta guía te explicamos cómo calcula el pool tu hashrate, qué son las shares rechazadas y stale, qué porcentaje es normal y cómo encontrar y resolver la causa paso a paso.
Puntos clave
- El hashrate del pool y el del ASIC nunca coinciden exactamente: el equipo muestra un valor instantáneo y el pool, un promedio calculado a partir de las shares aceptadas.
- Ni las shares rechazadas ni las stale se pagan.
- Las stale shares suelen deberse a la latencia de la red; los rechazos por dificultad baja y los errores de hardware apuntan al equipo.
- Una diferencia constante de más del 10–15 % entre el ASIC y el pool merece una revisión, incluida la posibilidad de un robo de hashrate.
- Una red estable, el servidor más cercano y un equipo bien refrigerado mantienen los rechazos por debajo del 1 %.
Por qué el pool muestra menos hashrate que el ASIC
El ASIC muestra su hashrate local: el rendimiento instantáneo del equipo, que cambia de un segundo a otro. Después de un reinicio, puede tardar entre 10 y 30 minutos en estabilizarse.
El pool lo calcula de otra forma:
- promedia los datos de un período, normalmente de 10 a 60 minutos;
- solo cuenta las shares aceptadas, sin las rechazadas ni las stale.
Por eso es normal que el hashrate local sea algo mayor que el del pool. Pero si la diferencia supera de forma constante el 10–15 %, hay que investigar. Empieza por lo más simple: comprueba que todos tus equipos estén en línea. En el panel del pool de minería de EMCD puedes ver el hashrate y el estado de cada worker en tiempo real.
Cómo calcula el pool tu hashrate
El pool no mide tu hashrate directamente: lo estima a partir de las shares que recibe y de su dificultad. Como referencia, una share de dificultad 1 requiere en promedio unos 4.295 millones de cálculos de hash.
Encontrar una share es un proceso aleatorio: en ventanas cortas llegan a veces más y a veces menos de las esperadas. Por eso el hashrate del pool fluctúa aunque tu equipo funcione sin interrupciones, y cuanto más larga es la ventana de cálculo, más estable es la cifra. Te explicamos esta métrica en qué es el hashrate.
Muchos pools ajustan además la dificultad de las shares según el hashrate de cada equipo, un sistema llamado vardiff. Cambia la cantidad de shares por minuto, pero no el hashrate estimado.
La tasa efectiva: la métrica que define tus pagos
La tasa efectiva (effective rate) es el trabajo que el pool te reconoce, y sobre ella se calculan tus pagos, no sobre el hashrate local. Aun así, la rentabilidad final depende también de las comisiones, la eficiencia del equipo y el costo de la electricidad.
Shares rechazadas y stale: qué son
Cada resultado que tu equipo envía al pool es una share. El pool la valida y la acepta o la rechaza.
Shares rechazadas: resultados no válidos. Sus causas más comunes son:
- errores de cálculo por overclocking excesivo, sobrecalentamiento o fallas de hardware;
- valores incorrectos en el trabajo enviado;
- errores en la comunicación con el pool;
- cortes de conexión.
Stale shares: resultados correctos que llegan tarde. Cuando la red encuentra un bloque nuevo, el pool envía a los equipos un trabajo nuevo. Las shares del trabajo anterior que llegan después ya no sirven. Se deben sobre todo a la latencia, a un ping alto, a la inestabilidad de la conexión (jitter) o a demoras de procesamiento.
| Shares rechazadas | Stale shares | |
| Qué son | Resultados no válidos | Resultados válidos que llegan tarde |
| Causa principal | Hardware o configuración | Latencia y calidad de la conexión |
| ¿Se pagan? | No | No |
| Nivel saludable | Menos del 0,5 % | Menos del 1 % |
Tipos de rechazo más comunes
El pool devuelve un código de error que aparece en los registros del equipo:
| Error | Qué significa | Dónde buscar |
| Job not found | La share es de un trabajo que el pool ya reemplazó (stale) | Latencia y conexión |
| Duplicate share | El equipo envió la misma share más de una vez | Firmware, proxy o reconexiones |
| Low difficulty share | El resultado no alcanza la dificultad asignada | Configuración o firmware |
| Unauthorized worker | El pool no reconoce al worker | Nombre del worker, cuenta o URL |
Algunos paneles agrupan las stale shares dentro de las rechazadas. Antes de sacar conclusiones, revisa qué tipo predomina.
Cómo calcular tu tasa de rechazo
Divide las shares rechazadas entre el total enviado y multiplica por 100. Por ejemplo, si tu equipo envió 10.000 shares y el pool rechazó 80, tu tasa es del 0,8 %. Si el pool asigna distintas dificultades, el porcentaje real puede variar un poco.
Por encima del 1 % conviene hacer un diagnóstico, y en el rango del 1–2 % el impacto en los ingresos ya es notable.
La latencia: la causa más frecuente
- El ASIC encuentra una share válida.
- La envía al servidor.
- La latencia retrasa la llegada.
- Mientras tanto, el pool ya pasó a un trabajo nuevo.
- La share llega tarde y se convierte en stale.
En minería suele considerarse aceptable una latencia de hasta 50–100 ms. Si te conectas a un servidor lejano, en otro país, el ping puede llegar a 150–300 ms, y las stale shares aumentan mucho. Influyen la distancia, la calidad de la conexión, la congestión de la red y la ruta del tráfico.
Cómo medir la latencia
Desde una computadora conectada a la misma red que tus equipos, abre la terminal y escribe ping seguido de la dirección del servidor, sin el prefijo stratum+tcp:// ni el puerto. Prueba todos los servidores regionales disponibles y quédate con el de menor latencia. Algunos servidores no responden al ping estándar aunque funcionen; en ese caso, usa una herramienta que mida la latencia sobre el puerto TCP del pool.
La conexión por cable Ethernet es más estable y tiene menos latencia que el wifi.
Cómo afectan los rechazos según el modelo de pago
En EMCD, el modelo de pago depende de la moneda. Te explicamos los modelos en cómo funciona un pool de minería.
- PPS+ y FPPS: el pool paga por cada share aceptada, así que cada share rechazada o stale es una pérdida directa y visible.
- PPLNS: la recompensa se reparte cuando el pool encuentra un bloque. Aquí las pérdidas son menos visibles y es fácil confundirlas con una mala racha del pool, así que conviene revisar los rechazos aunque los pagos parezcan normales.
Errores de hardware (HW errors)
Son cálculos incorrectos de los chips del ASIC, y una causa frecuente de rechazos. Pueden deberse a:
- overclocking excesivo;
- sobrecalentamiento;
- una fuente de alimentación inestable;
- desgaste del equipo;
- un firmware dañado.
Algunos síntomas son claros: si la temperatura sube demasiado, el equipo puede reiniciarse solo; un cable suelto puede dejar en cero el hashrate de una placa entera.
Si el contador de HW errors sube, el problema está en el equipo, no en la red. Te explicamos cómo cuidar la temperatura, los ventiladores y la pasta térmica en mantenimiento de ASIC.
Cuando la diferencia es constante: descarta un robo de hashrate
Si tus equipos reportan un hashrate normal, la red funciona bien y los rechazos son bajos, pero el pool recibe de forma constante un 5–10 % menos, puede haber otra causa: un firmware no oficial o un programa malicioso que desvía parte del trabajo de tus equipos a otro pool. Revisa la configuración de todos los pools, incluidos los de respaldo, y reinstala el firmware oficial si encuentras algo extraño. Te lo explicamos en cómo proteger tu granja de minería.
Diagnóstico paso a paso
- Compara tendencias, no lecturas sueltas. Revisa el historial de varias horas: una caída puntual no suele significar nada.
- Verifica que todos tus equipos estén en línea. Uno desconectado reduce el total.
- Mira qué tipo de rechazo predomina. Stale shares: red. Dificultad baja o HW errors: equipo.
- Mide la latencia hacia todos los servidores disponibles.
- Busca patrones entre equipos. Si varios muestran stale shares o reconexiones a la vez, la causa está en la red, no en un ASIC concreto.
- Revisa el hardware: temperatura, contador de HW errors, fuente de alimentación y cables de las placas.
- Revisa la configuración: URL, puerto, nombres de worker duplicados y pools de respaldo.
- Compara el hashrate del equipo con el del pool durante 24 horas para descartar un desvío.
Hacerlo a mano con muchos equipos es lento. EMCD Monitoring reúne el hashrate, la temperatura y el estado de todos tus ASIC en un solo lugar, para que veas de inmediato qué equipo rinde menos y por qué. Si un técnico o tu proveedor de hosting necesita revisar tus estadísticas, puedes compartirlas sin dar acceso a tu cuenta con un watcher link.
Si el problema sigue, contacta al soporte del pool y comparte capturas de tus estadísticas de rechazo.
Cómo reducir las shares rechazadas y stale
En la red:
- conéctate al servidor más cercano y prueba alternativas;
- usa una conexión estable, con poca variación de latencia;
- conecta los equipos por cable, no por wifi;
- si pruebas una VPN o un proxy para mejorar la ruta, mide su latencia antes de usarlo de forma permanente, porque a menudo la empeoran.
En el equipo:
- controla la temperatura y la ventilación. Te mostramos las opciones en refrigeración para minería;
- reduce el overclocking agresivo;
- revisa los cables de las placas y la estabilidad de la alimentación;
- usa firmware oficial y actualizado, como el firmware de EMCD para Antminer.
En la configuración:
- evita nombres de worker duplicados;
- configura servidores de respaldo.
Configura servidores de respaldo
Si el servidor principal deja de responder, el equipo pierde tiempo de trabajo. Los Antminer permiten configurar tres pools (Pool 1, Pool 2 y Pool 3), cada uno con su URL, worker y contraseña. El equipo usa el de mayor prioridad que esté disponible y, si falla, pasa al siguiente.
Una buena práctica es poner en los pools 2 y 3 otros servidores regionales del mismo pool, con los mismos datos de acceso. Así, si falla un servidor, sigues minando en tu cuenta y vuelves al principal cuando se recupera. Te mostramos cómo configurarlo en cómo conectar un ASIC a un pool.
En resumen
Si el hashrate del pool baja, no culpes de inmediato al equipo: muchas veces la causa es la red, la configuración o el servidor elegido. Pero el hardware también importa: más errores de hardware significan más rechazos y menos ingresos.
El hashrate local no muestra por sí solo tu rendimiento real. Sigue de cerca las shares rechazadas, las stale shares, la tasa efectiva y la estabilidad de la conexión, y compara siempre lo que reporta el equipo con lo que recibe el pool.
FAQ
¿Por qué el hashrate del ASIC es mayor que el del pool?
Porque el pool promedia los datos de un período y solo cuenta las shares aceptadas. Una diferencia pequeña es normal. Si supera de forma constante el 10–15 %, conviene investigar.
¿Qué porcentaje de shares rechazadas es aceptable?
Menos del 1 % se considera aceptable, y lo ideal es mantenerlo por debajo del 0,5 %. Para las stale shares, menos del 1 %.
¿Las stale shares cuentan como rechazadas?
Depende del pool: algunos las muestran por separado y otros las incluyen en las rechazadas. En ningún caso se pagan.
¿Un hashrate bajo en el pool significa que mi ASIC está dañado?
No necesariamente. Muchas veces la causa es la latencia, la conexión o la configuración. Si suben los HW errors o los rechazos por dificultad baja, entonces sí apunta al equipo.
¿Por qué cayeron de repente mis ingresos?
Las causas más comunes son más stale shares, más rechazos o más errores de hardware, un equipo desconectado o una latencia alta. Si la caída es constante y no encuentras otra causa, revisa la configuración por un posible robo de hashrate.
¿Se pueden eliminar del todo las stale shares?
No, siempre habrá una pequeña parte. Pero con el servidor más cercano y una conexión estable puedes llevarlas a un nivel muy bajo.
¿Qué latencia es aceptable?
Hasta 50–100 ms. Con 150–300 ms, las stale shares aumentan mucho.
¿El wifi aumenta las stale shares?
Puede hacerlo, porque suele tener más latencia y menos estabilidad. Para minar, lo recomendable es el cable.
¿Qué importa más, el hashrate o la tasa efectiva?
La tasa efectiva, porque es el trabajo que el pool te reconoce y sobre el que se calculan tus pagos.
Aviso: este artículo tiene fines informativos y educativos. No constituye asesoría técnica ni financiera. Los valores de referencia son orientativos y pueden variar según el pool, el equipo y la moneda.
