En esta página
Compara el mismo período primero
El dispositivo estima el trabajo local, mientras que un grupo estima el trabajo aportado a partir de los envíos. Las ventanas cortas fluctúan. Guarde el promedio del minero, el promedio del grupo, el trabajo aceptado y el tiempo de reinicio durante un período coincidente. Un trabajador que se unió recientemente no debe compararse con el promedio de un dispositivo de un día completo. f2pool recomienda promedios más largos al comprobar estas diferencias.
Registre el motivo real del rechazo
Las etiquetas del grupo y del firmware difieren. Conserve el mensaje sin formato en lugar de agrupar todo en un único recuento de errores. Un resultado tardío, una presentación duplicada y un error de cálculo dan lugar a investigaciones diferentes. Cuando cambia la dificultad de las participaciones, el simple recuento de participaciones también puede inducir a error; Utilice el trabajo ponderado por dificultad informado del grupo cuando esté disponible.
| Observación | Próximo cheque |
|---|---|
| rancio/tarde | Latencia, reconexiones y estabilidad de rutas. |
| Duplicar | Envíos repetidos, registros de conexión y proxy |
| Trabajo inválido | Registros de firmware, modo de funcionamiento y hardware |
| No autorizado | Reglas de nomenclatura de cuentas y trabajadores |
Pruebe la ruta, no solo la región anunciada
Confirme el punto final configurado con las instrucciones oficiales del grupo, luego inspeccione la frecuencia de desconexión y los tiempos de respuesta durante el período del problema. Un nombre de servidor cercano no garantiza una ruta estable. Si prueba otro punto final compatible, mantenga la misma configuración del dispositivo y registre la hora del cambio. Evite cambiar el grupo, el firmware y la frecuencia simultáneamente.
Verifique la estabilidad local cuando los errores persistan
Si varios trabajadores de una red fallan juntos, investigue la infraestructura compartida. Si solo una máquina se ve afectada, compare sus registros, enfriamiento y modo con una máquina del mismo modelo en buen estado. Devuelva el ajuste experimental a una configuración validada antes de juzgar el hardware. Utilice pasos de soporte específicos del modelo; una discrepancia en la pool por sí sola no establece una tabla dañada.
Cerrar el caso con un registro del antes y el después
En un caso hipotético, el hashrate local se mantiene estable mientras que las repetidas reconexiones de WAN coinciden con un trabajo obsoleto. Después de arreglar la conexión, compare períodos equivalentes y registre el trabajo aceptado, la tasa de rechazo y el recuento de reconexión. La mejoría después de un cambio respalda el diagnóstico, pero un intervalo de tranquilidad muy corto es una evidencia débil. Adjunte ambos períodos al escalar al grupo o al proveedor.
Referencias
Documentos originales y lecturas adicionales. Consulte el manual de su equipo exacto.
