iceriver oc
ver ASICs
Firmware modificado para todos los ASIC de IceRiver, agregando control de reloj y voltaje, gráficos de sensores, inicio de sesión y acceso API debidamente protegidos, y otras ventajas.
OC/OV personalizable, pequeña tarifa que beneficia a la comunidad, sin cambios innecesarios en su dispositivo.
Los archivos de firmware se pueden descargar desde la sección Versiones en el lado derecho de esta página.
Si tiene algún problema, encontrarme (pbfarmer) en Kaspa Discord probablemente dará como resultado la respuesta/resolución más rápida.
Ninguno de estos firmwares sería posible sin los esfuerzos de varias personas en pruebas y comentarios.
Sin embargo, una persona en particular ha sacrificado sus máquinas desde el principio, otorgándome acceso directo para el desarrollo, permitiéndome arriesgar sus máquinas mientras probaba características nuevas y sufriendo numerosas interrupciones en la minería durante las frecuentes actualizaciones y reinicios.
Esta persona se conoce con el nombre de usuario de Discord, Onslivion; sería fantástico si pudieras enviarle un agradecimiento en Kaspa Discord y tal vez incluso enviarle una propina o algo de tu hashrate:
kaspa:qzh2xglq33clvzm8820xsj7nnvtudaulnewxwl2kn0ydw9epkqgs2cjw6dh3y
Se agregaron configuraciones de reloj y voltaje a la página 'Minero'. El reloj se puede aumentar o disminuir a cualquier valor entero (dentro de los límites del hardware). Los cambios entran en vigor inmediatamente sin necesidad de reiniciar, pero tenga en cuenta que los aumentos de reloj se aplican gradualmente en incrementos de 25 Mhz cada 30 s. Como resultado, puede tomar algún tiempo alcanzar la velocidad máxima, posiblemente incluso ~10 minutos, dependiendo de qué tan grande sea el desplazamiento que elija.
El voltaje también se puede aumentar o disminuir a cualquier valor entero (dentro de los límites del hardware), y los cambios surten efecto inmediatamente. Las configuraciones se redondearán hacia abajo al múltiplo más cercano de 6,25 mV internamente para todo menos KS0 Pro. Un modelo sencillo a tener en cuenta es que por cada aumento de 25mv, los incrementos adecuados son 7mv-6mv-6mv-6mv, o por ejemplo, 7, 13, 19, 25 para los primeros 25mv.
Para KS0 Pro, el voltaje se puede ajustar en incrementos de 2 mV.
EL CONTROL DE VOLTAJE NO ESTÁ DISPONIBLE PARA KS3/M/L EN ESTE MOMENTO.
IMPORTANTE: ACTUALMENTE NO EXISTEN BARANDILLAS NI LÍMITES ESTE SOFTWARE YA SEA EN LOS RELOJES NI EN EL VOLTAJE, POR LO QUE ÚSELO CON CUIDADO.
Se ha agregado un nuevo modo de ventilador que ajusta automáticamente la velocidad del ventilador para mantener las temperaturas máximas del chip hash y de la placa. Las temperaturas se leen cada 10 segundos y la velocidad del ventilador se ajusta según sea necesario.
Tenga en cuenta que esta configuración no garantiza la temperatura establecida. Puede excederse hasta ~5 °C durante el inicio u otros períodos dinámicos, pero debe estabilizarse en la temperatura solicitada o cerca de ella.
Si descubre que las temperaturas objetivo se exceden más allá de su comodidad durante el inicio u otros períodos dinámicos, debe aumentar la velocidad mínima del ventilador.
Las velocidades fijas del ventilador ahora también se volverán a aplicar al inicio, después de un retraso de aproximadamente 1 a 2 m, aunque es una aplicación única. Esto significa que si el software IceRiver subyacente decide cambiar la velocidad del ventilador nuevamente por algún motivo, este modo no volverá a aplicar su configuración. Considere utilizar el modo 'Temperatura objetivo' con una velocidad mínima de ventilador adecuada como alternativa.
Se agregaron dos horas de gráficos para todas las métricas de chip, con filtros para resúmenes (por tablero mínimo/máximo/promedio), tablero o todos los chips.
Las temperaturas del chip de 80c parecen dar como resultado un rendimiento de hashrate ideal (aunque esto puede ser difícil en KS0/Pro sin mods de enfriamiento). IceRiver no ha proporcionado orientación sobre los límites seguros de temperatura del chip, pero su software de minería parece restringir los aumentos del reloj por encima de 95C , y de hecho acelerará los relojes por encima de 110 ° C. Probablemente sea prudente seguir al menos la orientación general de las G/CPU (por ejemplo, zona de advertencia >90 °C, zona de peligro >95 °C, zona crítica >105 °C).
Tenga en cuenta que el voltaje en tiempo real nunca coincidirá con su configuración: los controladores bajo carga experimentan una caída de voltaje, lo que significa que el voltaje de funcionamiento siempre estará por debajo de su configuración de voltaje, y una mayor carga provocará una caída mayor. El voltaje del chip será reemplazado por el consumo de energía para KS5L/M, ya que no hay lecturas de voltaje del chip disponibles. En estos modelos se aplica un límite de software de 3350 W, donde los núcleos se desactivarán en grupos de 4 si se excede este límite.
Se han agregado gráficos de temperatura de la placa para todos los modelos, que incluyen temperaturas de los sensores de admisión y escape, así como temperaturas de la etapa de potencia (conductor) para KS0/Pro/Ultra, KS1 y KS2. En modo resumen, se muestra la temperatura máxima de la etapa de potencia para cada placa, mientras que en modo placa, se muestra la temperatura máxima de la etapa de potencia para cada grupo/controlador (PSG). La temperatura de funcionamiento máxima recomendada es 125 °C según la documentación del chip, aunque probablemente sea aconsejable mantener un margen saludable por debajo de esta temperatura.
Tenga en cuenta que la temperatura no es la única consideración para un funcionamiento saludable. El consumo de energía/corriente también es una preocupación, para la cual actualmente no tenemos visibilidad ni especificaciones.
Los gráficos de hashrate (así como las estadísticas de titulares) ahora incluyen seguimiento de 30 my 2 horas, y también incluyen filtrado a nivel de tablero.
La información sobre herramientas al pasar el mouse se ha sincronizado en todos los gráficos para ayudar a diagnosticar problemas o anomalías.
Los valores instantáneos se muestran en la leyenda y las líneas individuales se pueden habilitar/deshabilitar haciendo clic en las etiquetas. Las escalas de los gráficos ya no se basan en cero y se ajustan según las líneas que se muestran, lo que significa que ya no se aplanan artificialmente debido a una mala resolución y, de hecho, se puede ver la variabilidad en cada medición.
Con suerte, esto ayudará a aclarar cuán variables son realmente las lecturas de 5 m.
El tiempo de actividad ininterrumpido y la tasa de emisión de trabajos se agregan a la sección de estadísticas del grupo. La tasa de trabajo es simplemente un indicador de estado adicional de una conexión de grupo: actualmente, las tasas de trabajo para la red Kaspa deberían ser de alrededor de 1 por segundo (pronto serán 10/s con la implementación de Rust) con una variación de aproximadamente +/- 15%. Si bien las tasas de empleo consistentemente superiores o inferiores a esto no deberían afectar técnicamente sus ganancias debido a la política de aceptación de bloques de Kaspa (suponiendo que el grupo no rechace innecesariamente acciones "antiguas"), es una señal de que es posible que el grupo no esté funcionando correctamente y usted Es posible que desee alertar al operador de la piscina o posiblemente encontrar otra opción.
Los operadores de kaspa-pool han comunicado que reducen intencionalmente la tasa de trabajo para limitar los gastos generales y que, en su caso, eso no afecta las tasas de participación obsoletas.
Se han agregado varios indicadores de estado a la sección del grupo para ayudar a diagnosticar diferentes problemas de red/grupo. Un icono gris de ocupado (girando) indica que el asic está intentando conectarse al grupo. Un ícono verde de ocupado indica una conexión de red, pero aún no hay conexión de estrato. Un icono de advertencia amarillo indica una conexión de estrato exitosa, pero no se han recibido trabajos.
Si bien la API anteriormente disponible en el puerto 4111 todavía está disponible, una nueva API racionalizada que incluye todas las funciones adicionales de la interfaz de usuario ahora está disponible a través de https (puerto 443).
La documentación completa está disponible en formato json.
Se han agregado una serie de funciones a una compilación 'comercial' separada destinada al alojamiento u otras implementaciones grandes. Estas compilaciones incluyen una 'c' después del número de versión (por ejemplo , pbv081c_ks5mupdate.bgz ) y actualmente tienen una tarifa adicional del 0,33 % (1,33 % frente al 1 % estándar).
Además del usuario principal/administrador estándar, se pueden agregar varios usuarios con diferentes permisos de acceso. Esto permite configuraciones en las que, por ejemplo, al propietario de la máquina se le puede otorgar acceso directo a la máquina, con permisos para ver la página de monitoreo principal y cambiar las configuraciones del grupo, mientras se le restringe el cambio de los parámetros de red, ventilador o reloj/voltaje.
El poder hash del ASIC se puede dividir en múltiples puntos finales en función de un porcentaje configurable, para permitir configurar tarifas de alojamiento. El número de divisiones no está limitado, pero tenga en cuenta que el firmware mantendrá una conexión de grupo/estrato para cada división, lo que multiplica el tráfico entrante.
Esta función también se puede utilizar para dividir el hashrate en varias monedas KHeavyHash a la vez.
El logotipo 'PbFarmer' se puede reemplazar con una imagen de marca de su elección. El formato de la imagen debe ser PNG de 112x60.
El bucle de verificación de estado se ejecuta según la disponibilidad del grupo principal. Si el minero ha cambiado a uno de los grupos secundarios por algún motivo, volverá a su grupo principal tan pronto como vuelva a estar disponible.
Se reemplazó el servidor web estándar con una versión actualizada y dirigida al entorno de producción, se agregó configuración de control de memoria/caché y se corrigieron las pérdidas de memoria. Esto debería solucionar los problemas observados por los usuarios de HiveOS y otras herramientas de monitoreo externas que causaron que el servidor web fallara después de demasiadas cargas de páginas (lo que provocó que la interfaz de usuario de ASIC no estuviera disponible).
Los controles de autenticación y autorización se reemplazaron por completo y todo el tráfico se redirigió a través de https. Esto significa que reenviar el tráfico http(s) a través de su firewall para monitoreo externo debería ser mucho más seguro (aunque todavía no lo recomendaría necesariamente, simplemente debido a las mejores prácticas de seguridad...) El inicio de sesión ya no se transmite a través de http no seguro. y la gente ya no puede secuestrar su asic simplemente configurando una cookie para omitir el inicio de sesión. Los mensajes aleatorios de "inicio de sesión incorrecto" debido a daños en el sistema de archivos también deberían ser cosa del pasado. Tenga en cuenta que esto significará que su contraseña se restablecerá a la configuración predeterminada después de la primera instalación. Además, el primer arranque después de la instalación tardará más de 2 minutos, ya que la máquina genera los certificados TLS.
Además, la API rediseñada se ha protegido con un token de acceso, a través del cual se pueden asignar permisos granulares. Los tokens deben incluirse con las solicitudes de API en un encabezado del formato 'Autorización: Portador <token>'.
Del mismo modo que actualizaría la contraseña de inicio de sesión, ELIMINAR/REEMPLAZAR ESTE TOKEN API si planea exponer su máquina públicamente, ya que es la misma en todas las máquinas de forma predeterminada.
Los certificados TLS (y la autoridad de certificación) para https se generan automáticamente en el ASIC, lo que significa que provocarán advertencias de "No seguro" en su navegador, ya que no provienen de una autoridad conocida. Si bien son inofensivas, estas advertencias pueden resultar molestas, por lo que el firmware brinda la posibilidad de descargar el certificado de CA para poder cargarlo en el almacén de certificados de su navegador.
Para hacerlo en Chrome, por ejemplo, vaya a chrome://settings/security, haga clic en 'Administrar certificados', seleccione la pestaña 'Autoridades de certificación raíz de confianza' (o simplemente 'Autoridades' para Linux) y haga clic en importar botón. Después de reiniciar su navegador, ya no debería ver la advertencia "No seguro".
Si tiene varios ASIC, tendrá una CA diferente para cada uno de forma predeterminada. Sin embargo, en lugar de agregar cada uno de estos a su(s) navegador(es) u otros dispositivos, puede propagar una única CA en todos los ASIC descargando tanto el certificado de CA como la clave de CA de un ASIC, cargando ambos archivos en todos los demás ASIC. luego regenerar el certificado en cada uno de esos otros ASIC.
Si accede a su ASIC a través de un nombre de dominio o varias IP, también puede agregarlas al certificado TLS enumerándolas en el campo "Regenerar certificado" y haciendo clic en "regenerar".
Se ha agregado un bucle de verificación de estado, que reiniciará automáticamente el minero o el servidor web en caso de que falle por cualquier motivo.
Además, el ejecutable de 'reinicio' que desaparece aleatoriamente de las máquinas de las personas (incluso de las configuraciones estándar), ahora está empaquetado con el firmware y se ha agregado un bucle de verificación de estado para reemplazar/reiniciar el archivo si es necesario. Esto debería solucionar los bucles de reinicio de 30 minutos que muchas personas están experimentando.
NO instale sobre el firmware xyys (incluido el de la marca tswift) en los modelos KS0 Ultras o KS5*. ¡Asegúrese de seguir sus instrucciones de desinstalación antes de instalar este o cualquier otro firmware!
Este es un paquete de actualización de firmware estándar, que incluye/mejora el firmware más reciente de IceRiver y se aplica tal como lo haría el firmware oficial. La aplicación sobre cualquier actualización anterior debería funcionar para los modelos KS0/Pro, KS1, KS2 y KS3*. La aplicación de versiones anteriores o de stock de este firmware también debería funcionar para los modelos KS0 Ultra y KS5*.
Sin embargo, si tiene problemas, pruebe el siguiente proceso:
Además, asegúrese de rehacer la configuración de su grupo, ya que se habrán restablecido a la dirección predeterminada de Kaspa Dev Fund.
Las fuentes de alimentación de portátiles para los modelos KS0/Pro/Ultra generalmente deben ser de 19,5 V con conectores de 5,5 mm x 2,5 mm, pero el amperaje puede variar según sus objetivos de OC. Sin embargo, los conectores cilíndricos de este tamaño tienden a tener una clasificación de 5 o 10a, y es poco probable que IceRiver haya usado opciones de 5a, por lo que sería razonable suponer que usaron 10a (7,5a es otra posibilidad). Esto significa que cualquier adaptador de más de 200 W probablemente exceda la clasificación del enchufe, de modo que el enchufe podría derretirse o incluso incendiarse, si no se enfría activamente (aun así, el riesgo persiste). Tenga mucho cuidado si decide utilizar una de las opciones de cargador de computadora portátil de mayor potencia.
Se recomienda encarecidamente tener un medidor de potencia conectado a sus máquinas para asegurarse de que se encuentre dentro de los límites de su fuente de alimentación. Esto es especialmente cierto para los modelos KS3* y KS5*, que tienen muy poco margen de fuente de alimentación incluso en la configuración original, así como para los modelos KS0* debido a la amplia gama de fuentes de alimentación.
Los modelos KS0 Pro y Ultra necesitan especial atención a la refrigeración. Las etapas de potencia de estos ya funcionan muy calientes, por lo que se recomiendan modificaciones de hardware para mejorar la refrigeración, incluidos disipadores de calor y un mejor flujo de aire.
Los chips hash en todos los modelos tienden a funcionar mejor en el rango de 75-80c, pero esto es especialmente cierto para el KS0 Ultra, donde incluso reduciendo de 80c a 75c, he experimentado una caída en el hashrate de 2 horas de > 3%.
EL PORCENTAJE DE COMPENSACIÓN DEL RELOJ Y EL PORCENTAJE DE AUMENTO DE HASHRATE DEBEN SER IGUAL EN UNA MÁQUINA EN SALUD.
Por ejemplo, si su compensación de reloj es del 30% en un KS1, entonces su hashrate debería ser 1.3TH/s, o 30% más que el valor predeterminado de 1 TH/s. Si este no es el caso (en una ventana de medición adecuada), entonces significa que sus chips carecen de voltaje.
La sintonización adecuada es un proceso que lleva tiempo. Usar la configuración de otras personas generalmente no es una buena idea, ya que cada máquina es diferente. La mejor práctica es comenzar con una compensación de reloj conservadora que resulte en un aumento de hashrate coincidente sin cambios de voltaje. A medida que aumentas aún más tus relojes en pequeños incrementos (por ejemplo, 25 mhz o menos), una vez que ya no ves que el hashrate responde 1:1 (o tal vez incluso comienza a caer), es una indicación de que se necesita más voltaje.
En ese punto, aumente el voltaje en un solo paso (2 mv para KS0 Pro, 7 o 6 mv según el nivel de corriente para todos los demás modelos), luego vea si el hashrate responde. Si es así, y una vez más iguala el desplazamiento del reloj en forma porcentual, vuelva a aumentar el reloj. Continúe esto de un lado a otro entre las compensaciones de reloj y voltaje hasta alcanzar el hashrate deseado, teniendo en cuenta los límites de temperatura y potencia.
Si bien los hashrates de 5 my 30 m en la GUI son herramientas útiles para la orientación direccional después de que la máquina haya tenido tiempo de acelerar, las mediciones finales del hashrate deben realizarse durante un período de tiempo prolongado. Las lecturas de hashrate de 5 minutos son bastante variables, e incluso las lecturas de hashrate de 30 minutos no son excelentes, ya que aún puede haber un par de porcentajes de variabilidad. Según mi experiencia, la lectura de 2 horas en la interfaz de usuario debería tener menos del 1 % de variabilidad (puede ser ligeramente superior al 1 % en KS5L/M y KS0Ultra), aunque no tiene en cuenta los errores de hardware ni los rechazos de grupos.
Y finalmente, si estás intentando replicar los resultados de OC de otro firmware...
Todo el firmware OC, incluido este, solo controla relojes y voltajes. Según mi experiencia, dado el voltaje necesario, el hashrate responde linealmente en proporción 1:1 al cambio de reloj, en porcentaje. Pero al final, todo lo que podemos hacer es cambiar el reloj y esperar que el ASIC responda con el cambio de hashrate esperado.
Las lecturas de hashrate en la interfaz de usuario de ASIC no son como las de la minería de CPU/GPU. Los ASIC de IceRiver no cuentan los hashes reales; simplemente estiman el hashrate en función del número de acciones producidas * dificultad. Así es exactamente como un grupo mide su tasa de hash, pero el problema es que la mayoría de los grupos decidieron usar una dificultad demasiado alta para los ASIC de IceRiver, lo que impide mediciones confiables de tasa de hash a corto plazo: con una diferencia alta, la tasa de participación es baja, lo que significa cambios bruscos en el hashrate. Como resultado, IceRiver lanzó una actualización de firmware que comenzó a usar una dificultad interna completamente diferente y menor para las mediciones de hashrate en su propio panel.
Por lo tanto, incluso para el mismo período de tiempo exacto, no se puede comparar de manera confiable la medición de la tasa de hash de un grupo con la tasa de hash de la interfaz de usuario de ASIC: no utilizan los mismos datos. Para exacerbar aún más esto, dado que las máquinas IceRiver generaban una gran cantidad de acciones no válidas desde el principio, varios grupos decidieron dejar de informar las acciones rechazadas al ASIC para que los usuarios dejaran de quejarse (o cambiar de grupo) y, en su lugar, informarlas como aceptadas. , sin dejar de rechazarlos silenciosamente por su parte. Dependiendo de la verdadera tasa de rechazo, esto puede significar una divergencia significativa entre el hashrate de ASIC y el hashrate del grupo, incluso si se midieron utilizando el mismo período de tiempo y dificultad.
Independientemente de la diferencia seleccionada, las mediciones de hashrate basadas en acciones * dificultad están sujetas a cambios según la suerte. Cuanto menor sea el recuento de acciones (mayor la diferencia), más afectará la suerte al hashrate y más salvajes serán las oscilaciones. Por lo tanto, para tener una medición de hashrate estadísticamente significativa, necesitas suficientes acciones para reducir el efecto de la suerte tanto como sea posible. Las lecturas de 5 m en el ASIC no son adecuadas para esto, especialmente cuando se intenta verificar el resultado de cambios de OC de un solo dígito, y las lecturas del grupo a corto plazo son aún peores.
Necesita 1200 acciones sólo para llegar a una variación esperada de +/- 10% con un 99% de confianza. Por ejemplo, para un hashrate esperado de 1TH/s, en mediciones 99/100 después de 1200 acciones, tendrá una lectura entre 0,9TH/s y 1,1TH/s. Necesita 4800 acciones para reducir esa variación a +/- 5%. Muchos pools están utilizando dificultades que producen tasas de acciones en el rango de ~5 acciones/min. Por lo tanto, sólo para obtener una lectura de hashrate con una variación esperada de <= +/- 10%, necesitaría una lectura de 1200/5 = 240 minutos o 4 horas. Si desea una lectura con una variación esperada de +/- 5 %, necesitará más de 16 horas de datos. Nunca podrá confirmar los resultados de un nivel de OC por debajo de la variación esperada de un período de tiempo determinado. Por ejemplo, no es posible determinar si un 5 % de OC está funcionando correctamente en una ventana de 4 horas/1200 acciones con una variación esperada del 10 %. Incluso a las 16 horas / 4800 acciones, la variación esperada puede anular por completo un 5% de OC.
Y esto lleva al quid de la cuestión: la mayoría de los pools no proporcionan nada superior a una medición de 24 horas, lo que a ~5 acciones/minuto significa aproximadamente 7200 acciones, lo que sigue siendo una variación esperada del 4%. Necesita 10.000 acciones solo para una variación del 3,3% y alrededor de 100.000 acciones para una variación del 1%. La lectura de 30 m en la interfaz de usuario de ASIC debería tener una variación de alrededor del 2 %, y la nueva lectura de 2 horas debería tener una variación de menos del 1 %, pero ninguna refleja los rechazos del grupo. Por lo tanto, la única solución es encontrar un grupo que le permita establecer su propia dificultad, de modo que pueda generar una cantidad estadísticamente relevante de acciones para sus períodos de tiempo disponibles. Herominers es uno de esos grupos que permite esto.
La mejor opción para establecer su propia diferencia y ver períodos de tiempo de medición suficientemente largos es minar en solitario su propio nodo y el puente-estrato-kaspa. La configuración predeterminada de vardiff producirá un mínimo de 20 acciones por minuto, lo que es suficiente para tener <= +/- 5 % de variación en 4 horas, y el panel (grafana) permite mediciones en cualquier marco de tiempo/resolución que desee, incluidos períodos de tiempo significativamente más largos que 24 horas.
Como ejemplo concreto de la diferencia entre mediciones válidas e inválidas (así como de cómo puede ayudar kaspa-stratum-bridge), aquí están las lecturas de hashrate de 3 máquinas que utilizan diferencias que producen >= 30 acciones/min, un KS0 al 51% OC, un KS1 al 37% OC y un KS3M al 1% OC. Las medidas son, de arriba a abajo, 24 horas (>= 43K acciones), 1 hora (>= 1800 acciones) y 30 m (>900 acciones). Puede ver cuán divergentes pueden ser las mediciones de las esperadas para períodos de tiempo más cortos:
En resumen, si está intentando confirmar los efectos de un pequeño OC en la interfaz de usuario de ASIC, necesitará usar la lectura de 2 horas, pero no sabrá si está generando acciones que serían rechazadas. Para obtener una imagen completa, necesitará una medición a largo plazo de un grupo que permita altas tasas de participación, y no hay opciones que pueda señalar que puedan hacer esto en este momento, aparte de minar en su propio nodo + estrato kaspa. -puente.
