iceriver oc
ver ASICs
Firmware modificado para todos os ASICs IceRiver, adicionando controle de relógio e tensão, gráficos de sensores, login devidamente protegido e acesso à API e outras vantagens.
OC/OV personalizável, pequena taxa beneficiando a comunidade, sem alterações desnecessárias no seu dispositivo.
Os arquivos de firmware podem ser baixados na seção Releases no lado direito desta página.
Se você tiver qualquer problema, encontrar-me (pbfarmer) no Kaspa Discord provavelmente resultará na resposta/resolução mais rápida.
Nenhum desses firmwares seria possível sem o esforço de várias pessoas em testes e feedback.
No entanto, uma pessoa em particular sacrificou as suas máquinas desde o início, concedendo-me acesso direto para desenvolvimento, permitindo-me arriscar as suas máquinas enquanto testava novas funcionalidades e sofrendo inúmeras interrupções de mineração durante as frequentes atualizações e reinicializações.
Essa pessoa atende pelo nome Onslivion do Discord - seria ótimo se você pudesse agradecer a ele no Kaspa Discord e talvez até enviar a ele uma dica ou parte do seu hashrate:
kaspa:qzh2xglq33clvzm8820xsj7nnvtudaulnewxwl2kn0ydw9epkqgs2cjw6dh3y
As configurações de relógio e voltagem foram adicionadas à página 'Miner'. O clock pode ser aumentado/diminuído para qualquer valor inteiro (dentro dos limites do hardware). As alterações entram em vigor imediatamente sem reinicialização, mas observe que os aumentos de clock são aplicados gradualmente em incrementos de 25 MHz a cada 30 segundos. Como resultado, pode levar algum tempo para atingir a velocidade máxima, possivelmente até cerca de 10 minutos, dependendo do tamanho do deslocamento escolhido.
A tensão também pode ser aumentada/diminuída para qualquer valor inteiro (dentro dos limites do hardware), com as alterações entrando em vigor imediatamente. As configurações serão arredondadas para o múltiplo mais próximo de 6,25mV internamente para tudo, exceto KS0 Pro. Um modelo simples a ter em mente é que para cada aumento de 25mv, os incrementos adequados são 7mv-6mv-6mv-6mv, ou por exemplo, 7, 13, 19, 25 para os primeiros 25mv.
Para KS0 Pro, a tensão pode ser ajustada em incrementos de 2mV.
O CONTROLE DE TENSÃO NÃO ESTÁ DISPONÍVEL PARA KS3/M/L NESTE MOMENTO.
IMPORTANTE: ATUALMENTE NÃO EXISTEM GUARDRAILS E NENHUM LIMITES APLICADOS POR ESTE SOFTWARE EM RELÓGIOS OU TENSÃO, PORTANTO USE COM CUIDADO.
Foi adicionado um novo modo de ventilador que ajusta automaticamente a velocidade do ventilador para manter as temperaturas máximas do chip hash e da placa. As temperaturas são lidas a cada 10 segundos e a velocidade do ventilador é ajustada conforme necessário.
Observe que esta configuração não garante a temperatura definida. Ela pode ser excedida em até ~5°C durante a inicialização ou outros períodos dinâmicos, mas deve estabilizar na temperatura solicitada ou próxima dela.
Se você descobrir que as temperaturas alvo foram excedidas além do seu conforto durante a inicialização ou outros períodos dinâmicos, você deve aumentar a velocidade mínima do ventilador.
As velocidades fixas do ventilador também serão reaplicadas na inicialização, após um atraso de aproximadamente 1-2 m, embora seja uma aplicação única. Isso significa que se o software IceRiver subjacente decidir alterar a velocidade do ventilador novamente por algum motivo, este modo não reaplicará sua configuração. Considere usar o modo 'Target Temp' com uma velocidade mínima apropriada do ventilador como alternativa.
Duas horas de gráficos foram adicionadas para todas as métricas de chip, com filtros para resumos (por placa mín/máx/média), placa ou todos os chips.
As temperaturas do chip de 80c parecem resultar em desempenho de hashrate ideal (embora isso possa ser difícil no KS0/Pro sem mods de resfriamento). Nenhuma orientação foi fornecida pela IceRiver quanto aos limites seguros de temperatura do chip, mas seu software de mineração parece restringir aumentos de clock acima de 95C , e irá realmente acelerar os relógios acima de 110C. Pelo menos seguir as orientações gerais dos G/CPUs é provavelmente prudente (por exemplo, >90C zona de alerta, >95C zona de perigo, >105C zona crítica).
Observe que a tensão em tempo real nunca corresponderá à sua configuração - os drivers sob carga experimentam queda de tensão, o que significa que a tensão de operação estará sempre abaixo da sua configuração de tensão, com mais carga causando uma queda maior. A tensão do chip será substituída pelo consumo de energia para KS5L/M, pois não há leitura de tensão do chip disponível. Um limite de software de 3350 W é aplicado nesses modelos, onde os núcleos serão desabilitados em grupos de 4 caso você exceda esse limite.
Gráficos de temperatura da placa foram adicionados para todos os modelos, o que inclui temperaturas dos sensores de admissão e exaustão, bem como temperaturas do estágio de potência (driver) para KS0/Pro/Ultra, KS1 e KS2. No modo de resumo, a temperatura máxima do estágio de potência é mostrada para cada placa, enquanto no modo placa, a temperatura máxima do estágio de potência é mostrada para cada grupo/controlador (PSG). A temperatura operacional máxima recomendada é de 125 ° C, de acordo com a documentação do chip, embora provavelmente seja aconselhável manter uma margem saudável abaixo dessa temperatura.
Esteja ciente de que a temperatura não é a única consideração para uma operação saudável. O consumo de energia/corrente também é uma preocupação, para a qual atualmente não temos visibilidade ou especificações.
Os gráficos de taxa de hash (assim como as estatísticas do título) agora incluem rastreamento de 30m e 2 horas e também incluem filtragem no nível do quadro.
As dicas de ferramentas ao passar o mouse foram sincronizadas em todos os gráficos, para ajudar no diagnóstico de problemas/anomalias.
Valores instantâneos são mostrados na legenda e linhas individuais podem ser desabilitadas/habilitadas clicando nos rótulos. As escalas gráficas não são mais baseadas em zero e se ajustam dependendo de quais linhas são exibidas, o que significa que elas não são mais achatadas artificialmente devido à baixa resolução, e você pode realmente ver a variabilidade em cada medição.
Esperamos que isso ajude a esclarecer como as leituras de 5m realmente são variáveis.
O tempo de atividade ininterrupto e a taxa de emissão de trabalhos são adicionados à seção de estatísticas do pool. A taxa de trabalho é simplesmente um indicador adicional de integridade de uma conexão de pool - atualmente as taxas de trabalho para a rede Kaspa devem ser em torno de 1 por segundo (em breve será 10/s com a implantação do Rust) com uma variação de aproximadamente +/- 15%. Embora as taxas de trabalho consistentemente mais altas ou mais baixas do que isso não devam tecnicamente afetar seus ganhos devido à política de aceitação de bloqueio da Kaspa (assumindo que o pool não está rejeitando desnecessariamente ações 'antigas'), é um sinal de que o pool pode não estar funcionando corretamente, e você pode querer alertar o operador do pool ou possivelmente encontrar outra opção.
Foi comunicado pelos operadores do kaspa-pool que eles reduzem intencionalmente a taxa de trabalho para limitar as despesas gerais e que isso não afeta as taxas de compartilhamento obsoletas no caso deles
Vários indicadores de status foram adicionados à seção de pool para ajudar a diagnosticar diferentes problemas de rede/pool. Um ícone cinza ocupado (girando) indica que o asic está tentando se conectar ao pool. Um ícone verde ocupado indica uma conexão de rede, mas ainda não há conexão de estrato. Um ícone de aviso amarelo indica uma conexão estrato bem-sucedida, mas nenhum trabalho foi recebido.
Embora a API anteriormente disponível na porta 4111 ainda esteja disponível, uma nova API racionalizada incluindo todos os recursos adicionais da UI agora está disponível em https (porta 443).
A documentação completa está disponível em formato json.
Vários recursos foram adicionados a uma versão 'comercial' separada, destinada à hospedagem ou outras implantações de grande porte. Essas compilações incluem um 'c' após o número da versão (por exemplo, pbv081c_ks5mupdate.bgz ) e atualmente têm uma taxa adicional de 0,33% (1,33% versus o padrão de 1%).
Além do usuário principal/administrador padrão, vários usuários com permissões de acesso diferentes podem ser adicionados. Isso permite configurações onde, por exemplo, o proprietário da máquina pode ter acesso direto à máquina, com permissões para visualizar a página principal de monitoramento e alterar configurações do pool, enquanto está impedido de alterar parâmetros de rede, ventilador ou relógio/tensão.
O hashpower do ASIC pode ser dividido em vários endpoints com base em uma porcentagem configurável, para permitir a configuração de taxas de hospedagem. O número de divisões não é limitado, mas lembre-se de que o firmware manterá uma conexão pool/estrato para cada divisão, o que multiplica o tráfego de entrada.
Este recurso também pode ser usado para dividir o hashrate entre múltiplas moedas KHeavyHash de uma só vez
O logotipo 'PbFarmer' pode ser substituído por uma imagem de marca de sua escolha. O formato da imagem deve ser PNG 112x60.
Loop de verificação de integridade executado na disponibilidade do pool primário. Se o minerador tiver mudado para um dos pools secundários por qualquer motivo, você retornará ao seu pool principal assim que ele estiver disponível novamente.
Servidor web de estoque substituído por uma versão atualizada e direcionada ao ambiente de produção, configuração de controle de cache/memória adicionada e vazamentos de memória corrigidos. Isso deve resolver os problemas observados pelos usuários do HiveOS e outras ferramentas de monitoramento externo que causaram a falha do servidor web após muitos carregamentos de páginas (resultando na indisponibilidade da UI ASIC).
Os controles de autenticação e autorização foram completamente substituídos e todo o tráfego redirecionado por https. Isso significa que encaminhar o tráfego http(s) através do seu firewall para monitoramento externo deve ser muito mais seguro (embora eu ainda não recomende isso necessariamente - simplesmente devido às melhores práticas de segurança...) O login não é mais transmitido por http inseguro, e as pessoas não podem mais sequestrar seu asic simplesmente definindo um cookie para pular o login. As mensagens aleatórias de 'login incorreto' devido à corrupção do sistema de arquivos também devem ser coisa do passado. Tenha em mente que isso significa que sua senha será redefinida para o padrão de estoque após a primeira instalação. Além disso, a primeira inicialização após a instalação levará mais de 2 minutos, pois a máquina gera os certificados TLS.
Além disso, a API redesenhada foi protegida com um token de acesso, por meio do qual permissões granulares podem ser atribuídas. Os tokens devem ser incluídos nas solicitações de API em um cabeçalho no formato 'Autorização: Portador <token>'.
Assim como você atualizaria a senha de login, EXCLUIR/SUBSTITUIR ESTE API TOKEN se você planeja expor sua máquina publicamente, pois ela é a mesma em todas as máquinas por padrão.
Os certificados TLS (e autoridade de certificação) para https são gerados automaticamente no ASIC, o que significa que causarão avisos de 'Não seguro' no seu navegador, uma vez que não são de uma autoridade bem conhecida. Embora inofensivos, esses avisos podem ser irritantes, portanto, o firmware oferece a capacidade de baixar o certificado CA para que ele possa ser carregado no armazenamento de certificados do seu navegador.
Para fazer isso no Chrome, por exemplo, acesse chrome://settings/security, clique em ‘Gerenciar certificados’, selecione a guia ‘Autoridades de certificação raiz confiáveis’ (ou apenas ‘Autoridades’ para Linux) e clique no botão importar botão. Depois de reiniciar seu navegador, você não deverá mais ver o aviso “Não seguro”.
Se você tiver vários ASICs, terá uma CA diferente para cada um por padrão. No entanto, em vez de adicionar cada um deles ao(s) seu(s) navegador(es) ou outros dispositivos, você pode propagar uma única CA em todos os ASICs baixando o certificado CA e a chave CA de um ASIC, carregando ambos os arquivos para todos os seus outros ASICs, em seguida, regenerando o certificado em cada um desses outros ASICs.
Se você acessar seu ASIC por meio de um nome de domínio ou vários IPs, também poderá adicioná-los ao certificado TLS listando-os no campo “Regenerar certificado” e clicando em “regenerar”.
Um loop de verificação de integridade foi adicionado, que reiniciará automaticamente o minerador ou o servidor web caso trave por qualquer motivo.
Além disso, o executável de 'redefinição' que desapareceu aleatoriamente das máquinas das pessoas (até mesmo das configurações de estoque), agora está empacotado com o firmware, e um loop de verificação de integridade foi adicionado para substituir/reiniciar o arquivo, se necessário. Isso deve resolver os loops de reinicialização de 30 milhões que muitas pessoas estão enfrentando.
NÃO instale sobre o firmware xyys (incluindo a marca tswift) nos modelos KS0 Ultras ou KS5*. Certifique-se de seguir as instruções de desinstalação antes de instalar este ou qualquer outro firmware!
Este é um pacote de atualização de firmware padrão, incluindo/melhorando o firmware IceRiver mais recente, e aplicado exatamente como seria o firmware oficial. A aplicação de quaisquer atualizações anteriores deve funcionar para os modelos KS0/Pro, KS1, KS2 e KS3*. A aplicação de versões anteriores ou de estoque deste firmware também deve funcionar para os modelos KS0 Ultra e KS5*.
No entanto, se você tiver problemas, tente o seguinte processo:
Além disso, certifique-se de refazer as configurações do pool, pois elas serão redefinidas para o endereço padrão do Kaspa Dev Fund.
As fontes de alimentação de laptop para modelos KS0/Pro/Ultra geralmente devem ser de 19,5 V com conectores de 5,5 mm x 2,5 mm, mas a classificação do amplificador pode variar dependendo de seus objetivos de OC. No entanto, conectores cilíndricos deste tamanho tendem a ser classificados para 5 ou 10a, e é improvável que o IceRiver tenha usado opções 5a, então seria uma suposição razoável que eles usassem 10a (7,5a é outra possibilidade). Isso significa que qualquer adaptador acima de 200 W provavelmente excede a classificação do soquete, de modo que o plugue pode derreter ou até pegar fogo, se não for resfriado ativamente (mesmo assim o risco permanece). Tenha muito cuidado se optar por usar uma das opções de carregador de laptop de maior potência.
É altamente recomendável que você tenha um medidor de energia conectado às suas máquinas, para garantir que esteja dentro dos limites da PSU. Isto é especialmente verdadeiro para os modelos KS3* e KS5*, que têm muito pouco espaço para PSU, mesmo em configurações padrão, bem como para os modelos KS0* devido à ampla gama de fontes de alimentação.
Os modelos KS0 Pro e Ultra precisam de atenção especial ao resfriamento. Os estágios de potência destes já esquentam muito, portanto, modificações de hardware para melhorar o resfriamento são altamente recomendadas - incluindo dissipadores de calor e melhor fluxo de ar.
Os chips hash em todos os modelos tendem a ter melhor desempenho na faixa de 75-80c, mas isso é especialmente verdadeiro para o KS0 Ultra, onde mesmo reduzindo de 80c para 75c, experimentei uma queda no hashrate de 2 horas de> 3%.
A PORCENTAGEM DE DESVIO DO RELÓGIO E A PORCENTAGEM DE AUMENTO DE HASHRATE DEVEM SER IGUAIS EM UMA MÁQUINA SAUDÁVEL.
Por exemplo, se o deslocamento do seu clock for de 30% em um KS1, então seu hashrate deverá ser 1,3TH/s, ou 30% a mais que o padrão de 1 TH/s. Se este não for o caso (em uma janela de medição apropriada), isso significa que seus chips estão sem tensão.
O ajuste adequado é um processo que leva tempo. Usar configurações de outras pessoas geralmente não é uma boa ideia, pois cada máquina é diferente. A melhor prática é começar com um deslocamento de clock conservador que resulte em um aumento de hashrate correspondente sem alterações de tensão. À medida que você aumenta ainda mais seus clocks em pequenos incrementos (por exemplo, 25 MHz ou menos), quando você não vê mais a taxa de hash responder 1:1 (ou talvez até começar a cair), é uma indicação de que mais voltagem é necessária.
Nesse ponto, aumente a tensão em um único passo (2mv para KS0 Pro, 7 ou 6mv dependendo do nível de corrente para todos os outros modelos) e veja se o hashrate responde. Se isso acontecer, e mais uma vez for igual ao deslocamento do relógio em uma base percentual, volte a aumentar o relógio. Continue indo e voltando entre as compensações de clock e de tensão até atingir o hashrate desejado, estando atento aos limites de temperatura e potência.
Embora os hashrates de 5m e 30m na GUI sejam ferramentas úteis para orientação direcional após a máquina ter tido tempo de acelerar, as medições finais do hashrate devem ser feitas durante um longo período de tempo. As leituras de hashrate de 5 minutos são bastante variáveis, e mesmo as leituras de hashrate de 30 minutos não são ótimas, pois você ainda pode ter alguns por cento de variabilidade. A leitura de 2 horas na IU deve ter menos de 1% de variabilidade da minha experiência (pode estar um pouco acima de 1% no KS5L/M e KS0Ultra), embora não leve em consideração erros de hardware/rejeições de pool.
E finalmente, se você estiver tentando replicar os resultados de OC de outro firmware...
Todos os firmwares OC, incluindo este, controlam apenas clocks e tensões. Pela minha experiência, dada a voltagem necessária, o hashrate responde linearmente na proporção de 1:1 à mudança do clock, em termos percentuais. Mas no final, tudo o que podemos fazer é mudar o relógio e esperar que o ASIC responda com a mudança esperada no hashrate.
As leituras de hashrate na UI ASIC não são como as da mineração de CPU/GPU. Os ASICs IceRiver não contam hashes reais - eles estão simplesmente estimando o hashrate com base no número de compartilhamentos produzidos * dificuldade. É exatamente assim que um pool mede seu hashrate, mas o problema é que a maioria dos pools decidiu usar uma dificuldade muito alta para ASICs IceRiver, o que impede medições confiáveis de hashrate de curto prazo - com um diff alto, a taxa de compartilhamento é baixa, o que significa oscilações selvagens no hashrate. Como resultado, o IceRiver lançou uma atualização de firmware que começou a usar uma dificuldade interna completamente diferente e menor para medições de hashrate em seu próprio painel.
Portanto, mesmo para o mesmo período exato, você não pode comparar de forma confiável uma medição de hashrate de pool com o hashrate da UI ASIC - eles não estão usando os mesmos dados. Para agravar ainda mais isso, uma vez que as máquinas IceRiver estavam gerando um grande número de compartilhamentos inválidos desde o início, vários pools decidiram parar de reportar compartilhamentos rejeitados de volta ao ASIC para que os usuários parassem de reclamar (ou trocar de pool) e, em vez disso, reportá-los como aceitos. , enquanto ainda os rejeita silenciosamente. Dependendo da verdadeira taxa de rejeição, isso pode significar uma divergência significativa entre o hashrate ASIC e o hashrate do pool, mesmo que tenham sido medidos usando o mesmo período de tempo e dificuldade.
Independentemente da diferença selecionada, as medições de hashrate baseadas na dificuldade de compartilhamentos estão sujeitas a oscilações com base na sorte. Quanto menor a contagem de compartilhamentos (maior a diferença), mais a sorte afeta o hashrate e mais violentas são as oscilações. Assim, para ter uma medição de hashrate estatisticamente significativa, você precisa de compartilhamentos suficientes para reduzir ao máximo o efeito da sorte. A leitura de 5m no ASIC não é adequada para isso, especialmente ao tentar verificar o resultado de alterações de OC de um dígito, e as leituras de pool de curto prazo são ainda piores.
Você precisa de 1.200 ações apenas para chegar a uma variação esperada de +/- 10% com 99% de confiança. Por exemplo, para um hashrate esperado de 1TH/s, em medições 99/100 após 1200 compartilhamentos, você terá uma leitura entre 0,9TH/s e 1,1TH/s. Você precisa de 4.800 ações para reduzir essa variação para +/- 5%. Muitos pools estão usando dificuldades que produzem taxas de ações na faixa de aproximadamente 5 ações/min. Portanto, apenas para obter uma leitura de hashrate com uma variação esperada de <= +/- 10%, você precisaria de uma leitura de 1200/5 = 240 minutos ou 4 horas. Se você quiser uma leitura com uma variação esperada de +/- 5%, precisará de mais de 16 horas de dados. Você nunca poderá confirmar os resultados de um nível de OC abaixo da variação esperada de um determinado período de tempo. Por exemplo, você não pode determinar se um OC de 5% está funcionando corretamente em uma janela de compartilhamento de 4 horas/1200 com 10% de variação esperada. Mesmo às 16 horas/4.800 ações, a variação esperada pode anular completamente um OC de 5%.
E isso leva ao cerne da questão: a maioria dos pools não fornece nada superior a uma medição de 24 horas, o que a aproximadamente 5 ações/minuto significa cerca de 7.200 ações, o que ainda representa uma variação esperada de 4%. Você precisa de 10 mil compartilhamentos apenas para uma variação de 3,3% e cerca de 100 mil compartilhamentos para uma variação de 1%. A leitura de 30m na UI ASIC deve ter uma variação de cerca de 2%, e a nova leitura de 2 horas deve ter uma variação inferior a 1%, mas nenhuma delas reflete as rejeições do pool. Portanto, a única solução é encontrar um pool que permita definir sua própria dificuldade, para que você possa gerar um número de compartilhamentos estatisticamente relevante para os prazos disponíveis. Herominers é um desses pools que permite isso.
A melhor opção para definir sua própria diferença e ver prazos de medição longos o suficiente é a mineração solo em seu próprio nó e na ponte kaspa-stratum. As configurações padrão do vardiff produzirão um mínimo de 20 compartilhamentos/min, o que é suficiente para ter <= +/- 5% de variação em 4 horas, e o painel (grafana) permite medições em qualquer intervalo de tempo/resolução que você desejar, incluindo intervalos de tempo significativamente mais longos do que 24 horas.
Como um exemplo concreto da diferença entre medições válidas e inválidas (bem como como o kaspa-stratum-bridge pode ajudar), aqui estão as leituras de hashrate de 3 máquinas usando diffs produzindo >= 30 compartilhamentos/min, um KS0 a 51% OC, um KS1 a 37% OC e um KS3M a 1% OC. As medições são, de cima para baixo, 24 horas (>= 43 mil compartilhamentos), 1 hora (>= 1.800 compartilhamentos) e 30m (> 900 compartilhamentos). Você pode ver o quão divergentes as medições podem ser do esperado para os prazos mais curtos:
Resumindo, se você estiver tentando confirmar os efeitos de um pequeno OC na UI ASIC, precisará usar a leitura de 2 horas, mas não saberá se está gerando compartilhamentos que seriam rejeitados. Para ter uma visão completa, você precisará de uma medição de longo prazo de um pool que permita altas taxas de compartilhamento - e não há opções que eu possa apontar que possam fazer isso neste momento, a não ser minerar para seu próprio nó + estrato kaspa -ponte.
