TeamRedMiner — Guia completo
Opções:
-a, --algo=ALGORITHM Seleciona o algoritmo de mineração. Disponíveis atualmente:
ethash (eth, etp, outros)
etchash (etc, alias para -a ethash --eth_variant_mode=etchash)
kawpow (ravencoin)
firopow (firo)
mtp_firopow (escolhe firopow ou mtp e encerra o minerador no fork de 26 de outubro de 2021)
autolykos2 (ergo)
verthash (vtc)
ton (ton)
kas (kaspa)
nimiq (nimiq)
lyra2z
phi2 (lux, argoneum)
lyra2rev3
x16r
x16rv2
x16s (pgn, xsh)
x16rt (gin)
mtp (zcoin/firo antes do fork firopow)
cuckatoo31_grin (grin)
cuckarood29_grin (grin)
cnv8
cnr (monero antigo)
cnv8_half (stellite, masari)
cnv8_dbl (x-cash)
cnv8_rwz (graft)
cnv8_trtl (turtlecoin antigo, loki)
cnv8_upx2 (uplexa)
cn_heavy (CN heavy clássico)
cn_haven (haven)
cn_saber (bittube)
cn_conceal (conceal)
trtl_chukwa (turtlecoin)
trtl_chukwa2 (turtlecoin)
-h, --help Exibe esta mensagem de ajuda e sai.
--debug Ativa a saída de log de depuração.
--hardware=HW_LIST Especifica quais tipos de hardware o minerador deve tentar usar, em uma lista separada por vírgulas.
Os valores suportados atualmente são 'gpu' e 'fpga'. Por exemplo:
--hardware=gpu,fpga
--benchmark Ativa o modo de benchmark. Todos os pools definidos serão ignorados e um único pool falso interno
será adicionado automaticamente. Para fazer benchmark de algoritmos como eth e kawpow em épocas e
alturas de bloco específicas, você também precisa adicionar argumentos específicos do algoritmo, como --eth_epoch=456 e --prog_height=123456.
--disable_colors Desativa as cores na saída do console.
--force_colors Força a saída colorida no console, mesmo que o terminal pareça não suportar cores.
--api_listen=IP:PORT Ativa a API compatível com o sgminer. IP:PORT é opcional. Se presente, a combinação IP:PORT
define a(s) interface(s) e a porta a escutar. O padrão é 127.0.0.1:4028. Para
acesso externo, use por exemplo 0.0.0.0:4028. Também é válido especificar apenas a
porta, por exemplo 4029. Agora é possível usar várias instâncias deste argumento para endpoints separados.
--api2_listen=IP:PORT Ativa uma segunda porta de API para configurações de mineração dual. Este endpoint da API fornece dados do
algoritmo dual, como se duas instâncias separadas do minerador estivessem rodando em paralelo. A
configuração padrão é 127.0.0.1:4029, ou seja, a porta é 4029 e não 4028. Para especificar sua
própria escolha, o argumento usa o mesmo formato de --api_listen. Agora é possível usar várias instâncias deste argumento
para endpoints separados.
--cm_api_listen=IP:PORT Ativa a API compatível com o Claymore. IP:PORT é opcional. Se presente, a combinação IP:PORT
define a(s) interface(s) e a porta a escutar. O padrão é 127.0.0.1:3333. Para
acesso externo, use por exemplo 0.0.0.0:3333. Também é válido especificar apenas a
porta, por exemplo 3334.
--cm_api_password=PSW Define a senha obrigatória para a interface da API compatível com o CM.
--log_file(=FILENAME) Ativa o registro da saída do minerador no arquivo especificado por FILENAME. Se nenhum nome de arquivo
for informado, o minerador gravará o log em trm_<algo>_<yyyymmdd_hhmmss>.log no diretório
de trabalho atual. Se o arquivo de log já existir, o minerador acrescentará ao final dele.
-l, --log_interval=SEC Define o intervalo de tempo em segundos para calcular a média e exibir os hashrates das GPUs.
SEC define o intervalo em segundos e deve ser > 0.
--log_rotate=SZ[,CNT] Ativa a rotação de logs. O valor SZ define o tamanho do log a partir do qual um novo arquivo de log será
criado. O valor SZ suporta os sufixos 'k', 'M' e 'G', que multiplicam o
valor por 1024, 1048576 e 1073741824, respectivamente. O valor opcional CNT define o
número máximo de arquivos de log antigos a manter. Por exemplo, a opção '--log_rotate=4M,16'
fará o minerador passar para um novo arquivo de log assim que o arquivo atual ultrapassar
4194304 bytes, e o minerador manterá os últimos 16 arquivos desse tipo, apagando
os mais antigos.
--short_stats Desativa a saída completa do estado das GPUs em cada exibição de hashrate, como era antes da 0.7.10.
--dev_location=LOC Seleciona uma localização específica para a conexão da taxa do desenvolvedor (dev fee). Use isto somente se você vir
problemas contínuos de conexão da dev fee relatados pelo minerador. O gerenciamento
de conexões normalmente funciona bem em todas as localizações. As opções disponíveis são:
world - Qualquer lugar do mundo, exceto a China continental.
non-gcp - Países com acesso bloqueado aos serviços do Google (por exemplo, Irã, Cuba).
cn - China continental.
eu - UE, Rússia, Ucrânia e arredores.
us - EUA, Canadá, América Central/do Sul.
asia - Ásia, exceto China.
--enable_compute (Somente Windows) Ativa o modo compute e desativa o crossfire nas GPUs necessárias.
--long_timestamps Ativa carimbos de data/hora com microssegundos nos logs, em vez de apenas segundos.
--restart_gpus (Somente Windows) Reinicia todas as GPUs configuradas antes de minerar, ou seja, desativa+ativa o dispositivo PCI.
--uac (Somente Windows) Ativa a elevação de privilégios quando o minerador executa tarefas como reiniciar GPUs.
Você sempre pode evitar isso executando o minerador diretamente como Administrador. Isso
acionará o aviso padrão de elevação do Windows, então você precisa estar presente para clicar em 'Sim'.
Se isto não estiver ativado, as tarefas que exigem privilégios de Administrador falharão quando o
minerador estiver rodando em uma conta de usuário comum.
--high_score Ativa a exibição dos 15 melhores shares encontrados desde o início do minerador na saída de estatísticas.
Observação: isto pode não estar disponível para todos os algoritmos.
--allow_dup_bus_ids Permite que várias GPUs usem o mesmo pci bus id. Isto só deve ser usado para placas Radeon Pro Duo
e hardware semelhante; normalmente é um sinal de um ambiente OpenCL com defeito.
--dns_https=URL Ativa a resolução DNS do pool usando DNS-over-HTTPS. Este é um recurso experimental. O TRM só
suporta a variante baseada em JSON, e não o mecanismo definido posteriormente na RFC8484. Você deve
informar a URL https completa, incluindo o nome do método. É permitido passar nomes de host
em vez de endereços IP brutos, mas esses nomes de host serão resolvidos usando o DNS do sistema.
A seguir estão alguns exemplos que foram verificados e funcionam:
--dns_https=https://8.8.8.8/resolve (Google DNS)
--dns_https=https://9.9.9.9:5053/dns-query (Quad9)
--dns_https=https://1.1.1.1/dns-query (serviço de DNS da Cloudflare)
--dns_https_sni=HOST Quando o argumento --dns_https é usado, o comportamento padrão é não enviar SNI na
conexão SSL/TLS. Com este argumento, você pode forçar o envio de qualquer SNI. Observe
que este é um argumento de rede avançado e a maioria dos usuários não precisa usá-lo.
--kernel_vm_mode=X (Somente Linux). Automatiza a configuração dos parâmetros de kernel necessários em /etc/default/grub em sistemas Linux
baseados em Debian/Ubuntu. Isso abrange a maioria das distros de mineração. O sistema pode ser reiniciado
automaticamente usando /sbin/reboot quando os parâmetros do kernel forem modificados. Se os
parâmetros corretos já estiverem configurados, o minerador e o script auxiliar não farão nada. Isso significa que
este argumento pode estar sempre presente na linha de comando. Os valores válidos são:
N - nenhum modo configurado, remove parâmetros existentes do modo C ou R. Sem reinicialização ao alterar.
C - antigo modo C da Radeon VII. Sem reinicialização ao alterar.
R - novo modo R para todas as GPUs, exceto Polaris. Sem reinicialização ao alterar.
RN - nenhum modo configurado, remove parâmetros existentes do modo C ou R. Reinicia ao alterar.
RC - antigo modo C da Radeon VII. Reinicia ao alterar.
RR - novo modo R para todas as GPUs, exceto Polaris. Reinicia ao alterar.
--kernel_vm_mode_script=X (Somente Linux). Especifica o script a ser chamado para definir novos parâmetros de modo do kernel.
O script deve se comportar como o script padrão do TRM incluído no pacote de distribuição do minerador,
chamado ubuntu_mode_script.sh. Normalmente este argumento não deve ser necessário.
--gpu_sdma=on|off Controla se operações sdma diretas são usadas pelo driver para copiar memória de/para
a GPU. Este argumento só é necessário em situações muito especiais. Por exemplo, a AMD BC-250
não suporta sdma e precisa de --gpu_sdma=off. Se você tiver travamentos logo na inicialização
da GPU, mas outros mineradores ou versões mais antigas do TRM funcionarem bem, tente --gpu_sdma=off.
Esta configuração é uma configuração de ambiente e controla todas as GPUs.
Opções de configuração do pool:
-o, --url=URL Define a URL do pool. Atualmente são suportadas URLs stratum+tcp e stratum+ssl.
Cada vez adicional que esta opção é especificada inicia uma nova configuração de pool.
As opções por pool (como -u, -p) precisam ser especificadas explicitamente
novamente para cada novo pool. (Veja o arquivo de exemplo start_multipool.sh/bat)
A estratégia de múltiplos pools do minerador é definida com a opção --pool_strategy.
Também há suporte especial para configurações SSL/TLS avançadas, em que você precisa
passar um nome de host SNI para o endpoint SSL. Por exemplo, isso é necessário para endpoints
SSL que funcionam como frontends para vários hosts e precisam saber para qual deles
fornecer o certificado. Nesses casos, use o seguinte formato:
-o stratum+ssl://pool.tunnel.com/pool.realhostname.com:3333
Isso conectará a pool.tunnel.com:3333, mas passará pool.realhostname.com como nome de host
SNI na fase de handshake SSL. Os dois nomes de host também podem, é claro, ser idênticos.
-u, --user=USERNAME Define o nome de usuário para autorização no pool.
-p, --pass=PASSWORD Define a senha para autorização no pool.
--pool_force_ensub Força uma solicitação de extranonce subscribe para pools suportados que o minerador não conhece.
--pool_no_ensub Impede que o minerador envie a solicitação de extranonce subscribe ao pool.
--pool_broken_rpc Faz o minerador permitir apenas uma única solicitação rpc pendente na conexão
com o pool. É uma solução alternativa para pools que violam a especificação json rpc
em relação aos IDs de rpc.
--pool_ratio=RATIO Define a proporção de hashrate entre os pools ao usar vários pools com as estratégias
'load_balance' ou 'quota' (veja --pool_strategy). Por padrão, todos os
pools usam o valor de proporção 1. Por exemplo, usar esta opção com valor 2 em
apenas um pool fará esse pool receber o dobro do hashrate dos outros pools,
já que a proporção deles continuará com o valor padrão 1.
--pool_debug Registra todo o tráfego do pool.
Opções globais de pool:
--pool_connect_TO=SEC Define o tempo limite para tentar conectar a um pool. SEC é o tempo de espera em
segundos. O padrão é 10.
--pool_rpc_TO=SEC Define quanto tempo o minerador esperará por um RPC sem resposta ao pool. Após esse
tempo, o minerador reconectará ao pool. SEC é o tempo de espera em segundos.
O padrão é 60.
--pool_max_rejects=N Se um pool rejeitar N shares seguidos, a conexão com o pool é reiniciada. Isso protege
contra pools que invalidam sessões de mineração sem desconectar o usuário.
O valor padrão é 5.
--pool_share_limit_ms=N Se um pool levar mais de N ms para aceitar ou rejeitar um share, encerra a conexão
atual e reconecta. Destina-se a pools que frequentemente têm problemas com
alguns de seus servidores; reconectar significa ser balanceado para um servidor diferente e,
com sorte, melhor. O valor padrão é sem tempo limite.
--pool_strategy=STRAT Define a estratégia de seleção de pools ao rodar com vários pools. Os valores
disponíveis são: priority, load_balance, quota e min_epoch. O padrão é priority.
priority: O minerador usará os pools na ordem em que estão listados, passando
para o próximo pool somente se o anterior não conseguir estabelecer conexão.
load_balance: O minerador distribuirá o hashrate igualmente entre todos os pools
conectados no momento. A proporção de hashrate entre os pools pode ser definida com --pool_ratio.
quota: O minerador distribuirá igualmente o total de hashes concluídos entre
todos os pools. Se um pool desconectar e depois reconectar, o minerador moverá
hashrate para esse pool até que o total de hashes de cada pool esteja equilibrado.
A proporção de hashrate entre os pools pode ser definida com --pool_ratio.
min_epoch: Estratégia de alternância ETH + ZIL. O minerador sempre minerará a menor época
entre todos os pools conectados e, em caso de empate, o primeiro pool conectado.
Portanto, especifique seu pool de mineração de ETH como o primeiro/principal pool e depois o pool de ZIL
como o segundo pool. Você também pode usar 'eth_zil' como nome desta estratégia.
--no_ntime_roll Impede que o minerador altere (roll) o ntime no cabeçalho do bloco, usando apenas o valor
fornecido pelo pool. Isto precisa ser ativado em alguns pools ao minerar x16rt.
--no_stale_submit Impede que o minerador envie shares que não sejam do job mais recente do pool.
Opções de GPU:
--platform=INDEX Define o índice da plataforma OpenCL a ser usada. Se não for especificado, a plataforma será
detectada automaticamente. No Linux, várias plataformas só são suportadas sem o argumento
--platform, adicionando --bus_reorder em vez disso.
-d, --devices=DEVLIST Define quais GPUs da lista detectada serão usadas. DEVLIST deve ser uma lista de índices de
dispositivos separados por vírgula, por exemplo -d 0,1,2,4. Se não for especificado, todos os
dispositivos da(s) plataforma(s) serão usados. OBSERVAÇÃO: por padrão, os dispositivos são ordenados
pela ordem do barramento pcie. Use --list_devices para ver os índices.
--init_style=1/2/3 Especifica o estilo de inicialização (1 é o padrão):
1: Uma GPU por vez, conclui todas antes de minerar.
2: Três GPUs por vez, conclui todas antes de minerar.
3: Todas as GPUs em paralelo, começa a minerar imediatamente.
--pcie_fmt=FORMAT Define o formato de exibição dos números do barramento pcie. Os valores aceitos para FORMAT são
'hex' ou 'dec'. O padrão é dec no windows e hex no linux.
--bus_reorder Reordena os dispositivos detectados ou especificados pelo pcie bus id. Se nenhuma
plataforma for especificada, os dispositivos serão coletados de todas as plataformas AMD OpenCL
detectadas. Observação: a partir da versão v0.7.0, este é o comportamento padrão.
--opencl_order Ordena os dispositivos detectados ou especificados na ordem em que o OpenCL os apresenta.
--list_devices Lista os dispositivos disponíveis para a plataforma detectada ou especificada e sai
imediatamente. A reordenação por barramento será aplicada na ordem exibida.
--nr_cu_override=X,Y,... Substitui o número de unidades de computação (CU) por GPU informado pela API OpenCL. Isto
é útil principalmente para Vega 64 com BIOS de 56 gravada, em que o driver
informa 56 CU em vez da quantidade real. Informe como valor do argumento uma lista separada por vírgulas
com a quantidade de CU substituída por GPU. Você pode pular GPUs e não
precisa informar valores para todas as GPUs do rig. Exemplo para um rig misto com duas Vegas
nos índices 1 e 3 e duas outras GPUs: --nr_cu_override=,64,,64. Você pode verificar seu
argumento adicionando também --list_devices antes de minerar.
Opções de controle de clock/tensão (somente windows, funcionalidade BETA):
O minerador tem funcionalidades básicas para definir os clocks de núcleo e memória e suas respectivas
tensões, além de escolher entre os timings integrados do driver do windows. Para cada
argumento disponível abaixo, você enumera os valores para as GPUs do rig em uma lista separada
por vírgulas. Alguns argumentos não são usados em certas GPUs. Você pode pular GPUs na lista.
O minerador sempre define e usa o p-state mais alto tanto para o núcleo quanto para a memória em GPUs GCN
(Polaris, Vega). Observe que GPUs Rx Vega _precisam_ ter a powerplay table modificada
no estado p2 da memória antes de conseguirem rodar com tensão abaixo de 900mV. Além disso, GPUs Big Navi
ainda precisam usar, por exemplo, o MorePowerTool para modificar a powerplay table, por exemplo
para permitir definir uma tensão menor. O minerador _pode_ adicionar suporte a funcionalidades relacionadas
à powerplay table no futuro.
--clk_debug Ativa mensagens de log na inicialização relacionadas à definição de clocks/tensões/timings.
--clk_core_mhz=MHZ1,MHZ2,... Define o clock do núcleo por GPU em MHz.
--clk_core_mv=MV1,MV2,... Define a tensão do núcleo por GPU em mV.
--clk_mem_mhz=MHZ1,MHZ2,... Define o clock da memória por GPU em MHz.
--clk_mem_mv=MV1,MV2,... Define a tensão da memória por GPU em mV. Não é usado em GPUs Navi ou Big Navi.
--clk_timing=V1,V2,... Escolhe entre os conjuntos de timings de memória disponíveis no driver. Não está disponível em todas as GPUs e
drivers.
Exemplo de linha de comando parcial para um sistema com quatro GPUs, com uma Rx Vega 64, 580, 5700XT e
6800 minerando ethash ou similar. Especificamos a tensão da memória apenas para a Vega e a 580, e só escolhemos
um valor de timing do driver para a Big Navi:
teamredminer.exe ... --clk_core_mhz=1100,1000,1275,1000 --clk_core_mv=875,850,725,675
--clk_mem_mhz=1107,2100,1820,2130 --clk_mem_mv=875,850,, --clk_timing=,,,1
Opções de controle das ventoinhas:
--fan_control(=CFG1,CFG2,...) Este argumento ativa o controle das ventoinhas das GPUs pelo minerador. O TRM suporta
o ajuste automático da velocidade das ventoinhas com base na temperatura do núcleo, da junção e/ou da memória.
Também suportamos definir uma velocidade fixa da ventoinha em porcentagem.
Cada tipo de GPU tem uma configuração de ventoinha usada por padrão. Suportamos
tanto substituir a configuração padrão por tipo de GPU quanto definir uma
configuração específica para cada GPU do rig.
Uma configuração de ventoinha consiste em (no máximo) seis valores, separados pelo caractere ':' (dois-pontos). Os valores
são: temperatura alvo do núcleo, temperatura alvo da junção, temperatura alvo da memória, velocidade inicial da ventoinha em
porcentagem, velocidade mínima da ventoinha em porcentagem, velocidade máxima da ventoinha em porcentagem. Qualquer valor pode ficar vazio.
Alguns exemplos:
::70:50:25 Temperatura alvo da memória de 70C, ventoinha inicia a 50%, velocidade mínima de 25%.
55::::20:80 Temperatura alvo do núcleo de 55C, ventoinha inicia na velocidade da configuração padrão,
sempre mantendo a ventoinha entre 20% e 80%.
55::75:80 Ajusta a ventoinha para que o núcleo fique <= 55C e a memória <= 75C, iniciando
a ventoinha a 80%.
:::100 Define a velocidade fixa da ventoinha em 100%, sem nunca ajustar com base nas temperaturas.
A configuração de ventoinha usada para uma GPU é determinada na seguinte ordem de precedência:
1. O argumento --fan_control recebeu uma lista de configurações que inclui uma
entrada para a GPU X.
2. A configuração padrão de ventoinha para este tipo de GPU foi substituída com um parâmetro
--fan_default_<type>=... .
3. Usa a configuração padrão integrada de ventoinha para este tipo de GPU.
Na lista acima, se a configuração escolhida não tiver o valor inicial da ventoinha,
é usado o valor da próxima configuração.
OBSERVAÇÃO: o suporte às ventoinhas é um recurso beta e não funcionará melhor do que o suporte que os
drivers oferecem. Por exemplo, muitas vezes os drivers no linux não permitem forçar uma
ventoinha a 100% usando o suporte pwm do sysfs.
--fan_default_polaris=CFG Define a configuração padrão usada para todas as GPUs Polaris (450/460/550/560/470/480/570/580/590).
O padrão integrado é 55:::50, para temperatura do núcleo de 55C e ventoinha iniciando a 50%.
Observação: esta configuração também é reutilizada para GPUs Tonga.
--fan_default_vega=CFG Define a configuração padrão usada para todas as GPUs Vega (Vega 56/Vega 64).
O padrão integrado é 55::70:50, para núcleo a 55C, memória a 70C e ventoinha a 50%.
--fan_default_vega2=CFG Define a configuração padrão usada para todas as GPUs Radeon VII.
O padrão integrado é 70::75:80, para núcleo a 70C, memória a 75C e ventoinha a 80%.
--fan_default_navi=CFG Define a configuração padrão usada para todas as Navi (Navi10).
O padrão integrado é 60::80:70, para núcleo a 60C, memória a 80C e ventoinha a 70%.
--fan_default_big_navi=CFG Define a configuração padrão usada para todas as Big Navi (Navi21).
O padrão integrado é 50:::70, para núcleo a 50C e ventoinha a 70%. O motivo para
não incluir a temperatura da memória é a falta de um sensor na biblioteca ADL do Windows.
--fan_debug Ativa mensagens de log relacionadas aos ajustes.
--fan_no_restore Desativa a restauração dos perfis originais das ventoinhas ao sair do minerador.
Opções do watchdog:
--no_gpu_monitor Desativa o monitor de GPU ADL (Windows) ou sysfs (Linux) para temperatura e
velocidade da ventoinha.
--temp_limit=TEMP Define a temperatura do núcleo na qual o minerador vai parar as GPUs que estiverem quentes demais.
O padrão é 85C. Valores específicos por GPU podem ser informados em uma lista separada por vírgulas,
um valor por GPU. Se uma GPU não tiver um valor definido, o primeiro valor da lista
é usado.
--temp_resume=TEMP Define a temperatura do núcleo abaixo da qual o minerador retomará as GPUs que foram
paradas por a temperatura do núcleo ter excedido o limite. O padrão é 60C. Valores específicos por GPU
podem ser informados em uma lista separada por vírgulas, um valor por GPU. Se uma GPU não
tiver um valor definido, é usado o primeiro valor da lista.
--mem_temp_limit=TEMP Define a temperatura da memória na qual o minerador vai parar as GPUs que estiverem quentes demais.
Desativado por padrão. Só é usado se a GPU tiver um sensor de temperatura da memória.
Valores específicos por GPU podem ser informados em uma lista separada por vírgulas, um valor por GPU.
Se uma GPU não tiver um valor definido, é usado o primeiro valor da lista.
--mem_temp_resume=TEMP Define a temperatura da memória abaixo da qual o minerador retomará as GPUs que foram
paradas por a temperatura da memória ter excedido o limite. Desativado por padrão. Só
é usado se a GPU tiver um sensor de temperatura da memória. Valores específicos por GPU podem ser informados
em uma lista separada por vírgulas, um valor por GPU. Se uma GPU não tiver um valor definido,
é usado o primeiro valor da lista.
--watchdog_script(=X) Configura o watchdog de GPU para encerrar o minerador, executar o script específico da plataforma
e sair imediatamente. O script padrão é watchdog.bat/watchdog.sh no
diretório atual, mas um script diferente pode ser informado como argumento opcional,
possivelmente também com um caminho absoluto ou relativo.
--watchdog_test Testa o script de watchdog configurado, acionando a mesma ação de uma GPU travada
após ~20 segundos de mineração.
--watchdog_disabled Força o watchdog a não ser executado. Pode ser usado para desativar o watchdog em sistemas de mineração
que sempre rodam com o watchdog ativado.
Opções do Ethash:
--eth_config=CONFIG Configuração manual do ethash para o minerador. CONFIG deve estar no formato [X][M][L].
O valor [M] seleciona o modo, que pode ser 'A', 'B' ou 'C'.
O modo 'B' usa memória adicional e só funciona em placas com 8+GB.
O modo 'C' usa memória adicional e só funciona em placas com 16+GB, como a VII, em
um sistema configurado corretamente. Veja o ETHASH_TUNING_GUIDE.txt para mais detalhes.
O valor [L] seleciona a intensidade, e sua faixa depende da arquitetura da GPU.
O prefixo [X] é opcional e exclusivo para Navi/Big Navi; ele ativa mais operações de memória e
leva a um valor de ajuste [L] menor. Pode ser vantajoso sempre que o auto-tuner atinge repetidamente
um valor próximo do máximo possível para a GPU.
Ambos os valores são opcionais, mas se [L] for especificado, [M] também deve ser especificado.
Exemplos de configuração: --eth_config=A
--eth_config=B750
--eth_config=XB
CONFIG também pode ser uma lista de valores de configuração separados por vírgula, em que cada um é
aplicado a cada GPU. Por exemplo: --eth_config=A,B750,,A288
Qualquer GPU que não tenha uma configuração específica na lista usará a primeira
configuração da lista.
--eth_variant_mode=X Este argumento controla a ativação das mudanças do ethash para ETC a partir da época 390, conforme descrito
no ecip-1099. Os seguintes modos estão disponíveis:
pool - Modo padrão. Só é ativado se o pool enviar uma flag de algoritmo contendo etchash.
Depois que essa flag é vista, todos os jobs do pool serão considerados etchash, a menos que outra
flag de algoritmo contendo ethash seja recebida.
etchash - Modo etchash. Épocas >= 390 serão consideradas etchash, épocas menores ethash. As flags de algoritmo
do pool não são usadas.
deduce - Ignora as flags de algoritmo do pool e aplica apenas uma heurística baseada no horário atual do sistema
e nas alturas e horários conhecidos de ETC e ETH. Este modo deve funcionar como uma abordagem
genérica quando o ETH atingir a época 390 em jan. de 2021. O relógio do sistema precisa estar correto.
Ele também deve lidar com configurações de profit switching que alternam livremente entre jobs ethash e
etchash por meio de proxy dos pools subjacentes.
auto - Enquanto o pool não tiver enviado uma flag de algoritmo, usa o modo deduce. Quando uma flag de algoritmo
é vista, muda para o modo pool.
ethash - Modo ethash forçado. Nunca aplica o ecip-1099.
force_etc - Modo etchash forçado. Sempre aplica as regras do ecip-1099. Use para minerar na testnet do ETC.
--eth_aggr_mode Ativa o uso automático do modo 'B' para todas as placas Polaris de 8GB, a menos que tenham uma
configuração diferente informada pelo argumento --eth_config. É o mesmo que
definir manualmente todas as GPUs Polaris de 8GB do rig no modo 'B' usando --eth_config.
Na maioria das GPUs, isso adiciona 0.1-0.2 MH/s de hashrate. OBSERVAÇÃO: 20-25% dos rigs ficam menos
estáveis neste modo, e é por isso que ele não é o modo padrão. Se você tiver
GPUs travando, remova este argumento e rode as GPUs no modo 'A'.
--eth_stratum_mode=MODE Define um modo stratum fixo para pools ethash. Por padrão, o minerador tentará
determinar automaticamente o tipo de stratum que o pool suporta e usar esse modo.
Essa detecção automática pode ser substituída especificando esta opção. MODE pode ser
definido como uma das seguintes opções: stratum, nicehash, ethproxy.
--eth_worker Define o id do worker que será enviado ao pool. Isto só se aplica a pools com o modo stratum
ethproxy.
--eth_hash_report=X Controla os relatórios de hashrate enviados aos pools configurados. Este valor é aplicado a todos os pools. Valores:
default - deixa o minerador decidir com base no protocolo stratum usado em cada pool.
force - sempre envia relatórios de hashrate, mesmo que o pool os rejeite.
on - envia um primeiro relatório de hashrate e desativa para qualquer pool que rejeite a mensagem.
off - nunca envia relatórios de hashrate.
--eth_epoch Testa uma época específica do ethash. OBSERVAÇÃO: isto colocará o minerador automaticamente no modo de benchmark, como
se você tivesse adicionado --benchmark.
--eth_alloc_epoch=N Aloca desde o início memória suficiente para a época informada. O minerador tentará alocar mais
se precisar mais tarde durante a mineração.
--eth_dag_buf=X,Y,... O minerador pode alocar um único buffer ou dois buffers para o DAG. Por enquanto, o padrão é AUTO. Um buffer
único é um pouco melhor, levando a uma pequena economia de energia em todos os tipos de GPU. Apenas drivers recentes suportam
alocações únicas grandes, maiores que 4GiB, normalmente a partir do Adrenalin 20.9.1 e do amdgpu-pro 20.x. Com este argumento, o minerador
pode usar automaticamente o modo de buffer único quando possível, ou forçar buffer único ou duplo
por GPU. Os valores suportados são A(uto), S(ingle), D(ual). Você pode enumerar uma lista separada por vírgulas
para todas as GPUs do rig, ou um único valor para todas as GPUs. Uma GPU que não tiver valor na
lista separada por vírgulas usará o primeiro valor.
--eth_big_mode_adjust=X,Y,... Ao usar os modos B ou C, o minerador funciona melhor quanto mais vram conseguir alocar. Infelizmente, os
drivers não informam com precisão quanta memória é possível alocar, especialmente no Windows.
O minerador usará um valor seguro e conservador de 256MiB (Linux) e 512MiB (Windows) como margem em relação
ao tamanho de vram disponível. Se você quiser alterar esse número, pode fazer isso com este argumento, informando
uma lista separada por vírgulas com valores para uma ou mais GPUs. Valores para GPUs que não rodam no modo B/C serão
ignorados. Se uma GPU não tiver valor na lista, o primeiro valor informado será usado.
O intervalo permitido é [-64, 2048]. Quanto maior o número, menos vram é alocada na GPU.
--eth_dag_slowdown=N Desacelera a geração do DAG. Informe um único dígito de 0 a 9. 0 significa sem desaceleração (comportamento <= 0.7.9),
1 significa desaceleração mínima, 9 significa máxima. Valor padrão: 4, para uma leve desaceleração.
--eth_stagger Ativa o escalonamento das GPUs ao construir um novo DAG. Isso é mais suave para fontes (PSUs) que não gostam
de passar de 0 a 100% de carga em todas as GPUs ao mesmo tempo.
--eth_no_stagger Desativa --eth_stagger. Já é o comportamento padrão desde a 0.7.18. Argumento mantido apenas para
compatibilidade com versões anteriores.
--eth_ramp_up Adiciona o aumento gradual da intensidade em todas as GPUs após a construção do DAG, desativação/ativação de GPU ou queda de rede.
Pode ajudar rigs que travam logo entre a construção do DAG e o início da mineração.
--eth_no_ramp_up Desativa --eth_ramp_up. Já é o comportamento padrão desde a 0.7.18. Argumento mantido apenas para
compatibilidade com versões anteriores.
--eth_direct_abort Usa um mecanismo diferente para abortar jobs em andamento na GPU. Recomendado para Vegas em ambientes ROCm
para minimizar shares obsoletos (stale). Só se aplica às GPUs Vega e Polaris do rig.
--eth_dag_alloc_patch Algumas placas-mãe com bios desatualizada podem apresentar erros de hardware, normalmente na primeira ou na última GPU do sistema.
Use este argumento para forçar uma estratégia de alocação do DAG corrigida, que na maioria das vezes resolve o problema.
Atualizar a bios também costuma resolver o problema.
--eth_hashwatch(=M,M) Define um hashrate mínimo/máximo do watchdog, em MH/s, esperado quando as GPUs estão minerando. Se uma GPU ficar fora
dessa faixa por tempo demais, ela será considerada com defeito e o watchdog será acionado. Os
valores padrão de mínimo/máximo são 2 MH/s e 150 MH/s. Para ativar com os valores padrão, use
--eth_hashwatch. Para definir seus próprios valores, use por exemplo --eth_hashwatch=1.25,60. A mesma faixa é usada
para todas as GPUs do rig. Um valor negativo de um lado o desativa; por exemplo, use --eth_hashwatch=-1,1000
para lidar com resets de GPU que resultam em hashrates falsos enormes, mas sem verificação de mínimo.
--eth_dag_cache(=EPOCH) Ativa o salvamento de DAGs eth de jobs com épocas diferentes, para evitar ter que reconstruí-los no
futuro caso jobs com as épocas antigas sejam recebidos novamente. No máximo um DAG será salvo, se o espaço na memória
da GPU permitir. Isso é útil para pools com alternância, como na mineração eth+zil. Se você quiser pré-construir uma
determinada época logo na inicialização, adicione o valor opcional. Mineradores com alternância eth+zil devem usar
--eth_dag_cache=0. Por enquanto, apenas épocas ethash (e não etchash) podem ser pré-construídas.
--eth_dag_cache_resv=MEM Define a quantidade de memória da GPU que o minerador tentará deixar sem uso ao rodar com o cache de DAG
ativado (veja --eth_dag_cache). O argumento MEM é a quantidade de memória a deixar sem uso, em
mebibytes. O valor padrão é 256.
--eth_dag_cache_verify Ativa a leitura e verificação do cache de DAG após a conclusão da construção do DAG. Isso detecta situações
em que o cache de DAG teve erros de bit e o DAG resultante está parcialmente corrompido. Temos visto isso
acontecer cada vez mais em Vegas, à medida que o DAG cresce. Quando detectado, um novo buffer será
alocado para o cache de DAG e a construção do DAG será reiniciada.
--eth_micro_delay=VAL,VAL,... Adiciona um atraso (medido em microssegundos) ao reenfileirar trabalho na(s) GPU(s).
Fontes mais fracas alimentando muitas GPUs às vezes não conseguem lidar com a "slew rate" quando várias GPUs
reenfileiram trabalho exatamente ao mesmo tempo. Definir isto como, por exemplo, 32 suaviza a transição
de carga zero para 100% o suficiente para reduzir a slew rate nesses rigs. O sintoma típico deste
problema são travamentos completos, em que o rig para de responder e precisa ser desligado e ligado novamente, mas também podem
ser travamentos comuns de GPU. Os valores válidos são 0-256. Valores por GPU podem ser informados em uma lista separada por vírgulas.
GPUs sem valor especificado na lista usarão o primeiro valor. Os valores padrão deste argumento na
mineração ethash de algoritmo único são:
Polaris: 64
Vega: 0
Navi: 0
--eth_ignore_abort_fail Quando o aborto de um job falha, normalmente é resultado de uma intensidade alta demais, e por isso o minerador
a reduz automaticamente. Esta opção _desativa_ essa lógica, mantendo a intensidade, mas
registrando um aviso no log.
--eth_no_job_logs Suprime todos os logs de novos jobs recebidos do(s) pool(s). Aplica-se a todas as sessões de mineração da família ethash,
ou seja, em uma configuração dual eth+zil, os logs dos pools de eth e de zil serão suprimidos. Jobs do pool que
mudam para uma nova época continuarão sendo registrados.
--eth_smooth_power=X,Y,... O agendamento "smooth power" foi adicionado na 0.10.0 e está disponível para todos os tipos de GPU.
Em geral é um bom recurso, que adiciona um pouco de hashrate e também melhora a estabilidade na maioria
dos casos, e vem ativado por padrão em todas as GPUs. No entanto, há rigs que não reagem bem e
começam a travar. Nesse caso, você pode usar este argumento para controlar o recurso por GPU no seu rig.
Os valores válidos são 0 ou 1. Para um rig com 5 GPUs, você pode usar --eth_smooth_power=0,1,1,1,0 para desativar o smooth
power na primeira e na última GPU. Se você não especificar um valor para uma GPU, é usado o primeiro valor
da lista. Isso significa que você pode desativar o recurso para o rig inteiro usando --eth_smooth_power=0.
Opções do Progpow (kawpow, firopow):
--prog_config=CONFIG Configuração manual do progpow para o minerador. CONFIG deve estar no formato [M][L].
O valor [M] seleciona o modo, que pode ser 'A' ou 'B'.
O modo 'B' normalmente resulta em melhor desempenho, mas só está disponível para
Vega no linux e Navi (linux ou windows).
O valor [L] seleciona a intensidade, e sua faixa depende da arquitetura da GPU.
Ambos os valores são opcionais, mas se [L] for especificado, [M] também deve ser especificado.
Exemplos de configuração: --prog_config=A
--prog_config=B750
CONFIG também pode ser uma lista de valores de configuração separados por vírgula, em que cada um é
aplicado a cada GPU. Por exemplo: --prog_config=A,B750,,A288
Qualquer GPU que não tenha uma configuração específica na lista usará a primeira.
--prog_height=VALUE Define uma altura de bloco fixa para algoritmos progpow, para fins de benchmark. Isto colocará automaticamente
o minerador no modo de benchmark.
--prog_strict Força o minerador a sempre gerar kernels estritamente precisos. Por padrão, o minerador
gera kernels relaxados, que usam menos poder de computação, mas podem resultar em
shares inválidos ocasionais.
--prog_dag_slowdown=N Desacelera a geração do DAG. Informe um único dígito de 0 a 9. 0 significa sem desaceleração (comportamento <= 0.7.9),
1 significa desaceleração mínima, 9 significa máxima. Valor padrão: 4, para uma leve desaceleração.
--prog_stagger Veja --eth_stagger.
--prog_ramp_up Veja --eth_ramp_up.
--prog_no_stagger Veja --eth_no_stagger.
--prog_no_ramp_up Veja --eth_no_ramp_up.
--prog_micro_tune=X,Y,... Esta opção ativa uma pequena sessão de reajuste a cada novo bloco de código aleatório. Isso é importante
para que as GPUs Polaris rodem na velocidade máxima. Para Vegas e Navis, normalmente não melhora o
desempenho. O modo padrão AUTO o ativa para todas as GPUs Polaris e o desativa nas demais.
O único motivo para desativá-lo seria a estabilidade. O valor do argumento é uma
lista de valores separados por vírgula, um por GPU. Se faltar o valor de uma GPU, é usado o valor da
primeira GPU. Observe que definir um prog_config manual também desativa, na prática, o
micro-tuner. Os valores disponíveis são:
1 - DESATIVA o micro-tuning do progpow para esta GPU.
2 - ATIVA o micro-tuning do progpow para esta GPU.
3 - deixa o minerador decidir se o micro-tuning deve ser ativado (AUTO).
--prog_hash_report Ativa o envio forçado de relatórios de hashrate (como no ethash) para todos os pools. É um alias para
--eth_hash_report=force, que também se aplica, já que progpow e ethash usam o(s) mesmo(s)
protocolo(s) de pool.
Opções do Cryptonight:
--rig_id Define o identificador do rig que será enviado ao pool. Só é usado em
pools cryptonight.
--cn_config=CONFIG Configuração manual do cryptonight para o minerador. CONFIG deve estar no formato
[P][I0][M][I1][:xyz], em que [P] é um prefixo opcional e [:xyz] é um
sufixo opcional. Para [P], só é suportado o valor 'L', para GPUs de
entrada como Lexa/Baffin. [I0] e [I1] são os valores de intensidade das threads, normalmente
de 1 a 16, mas valores maiores são possíveis em GPUs de 16GB. [M] é o
modo, que pode ser '.', -', '+' ou '*'. O modo '.' significa que o minerador
deve escolher ou procurar o melhor modo. O modo '*' é um bom padrão e
_deve_ ser usado se você minera em uma Vega 56/64 com timings de memória modificados. As
exceções a esta regra são as variantes de pad pequeno (cnv8_trtl e cnv8_upx2), que
ainda devem usar '+'. Para GPUs Polaris, apenas os modos '-' e '+' estão disponíveis.
OBSERVAÇÃO: no TRM 0.5.0 foi adicionada a funcionalidade de auto-tuning, tornando a configuração manual
dos modos CN desnecessária, exceto em casos raros. Para mais informações,
veja os documentos de tuning e how-to incluídos na versão.
Exemplos de configuração: --cn_config=15*15:AAA
--cn_config=14-14
--cn_config=L4+3
CONFIG também pode ser uma lista de valores de configuração separados por vírgula, em que cada um é
aplicado a cada GPU. Por exemplo: --cn_config=8-8,16+14:CBB,15*15,14-14
Qualquer GPU que não tenha uma configuração específica na lista usará a primeira
configuração da lista.
--no_cpu_check Desativa a verificação pela CPU dos shares encontrados antes de serem enviados ao pool.
Observação: atualmente só os algoritmos CN suportam a verificação pela CPU.
--no_lean Desativa o modo lean do CN, que aumenta as threads gradualmente na inicialização ou ao reiniciar após
problemas de rede ou throttling por temperatura da GPU.
--no_interleave=DEVS Lista as GPUs em que a lógica de interleave de threads do CN não deve ser usada.
O argumento é uma lista de dispositivos separados por vírgula, como na opção -d.
Use este argumento se algum dispositivo tiver hashrate pior junto com muitas
mensagens de log de ajuste de interleave.
--alloc_patch=DEVS Lista as GPUs que perdem hashrate entre o TRM v0.4.5 e versões posteriores. Com este
argumento, é usada uma estratégia de alocação de memória mais simples, e o hashrate antigo (maior) deve
ser restaurado. O modo de auto-tuning ainda pode ser usado.
--auto_tune=MODE Ativa o modo de auto-tuning na inicialização. Disponível apenas para variantes CN. MODE deve
ser NONE, QUICK ou SCAN. O modo QUICK verifica algumas configurações conhecidas como boas
e termina em até 1 min. O modo SCAN verifica todas as combinações possíveis e
roda por 20-30 min. Definir MODE como NONE desativa o recurso de auto-tuning. O modo
padrão é QUICK.
--auto_tune_runs(=N) Executa várias rodadas de auto-tuning, a cada vez reduzindo em 1 a unidade de pads usada
em uma das threads (15+15 -> 15+14 -> 14+14 -> 14+13 -> ...). Você pode especificar o
número exato de rodadas ou deixar o minerador escolher um valor padrão por tipo de GPU (normalmente 3-4).
--auto_tune_exit Se presente, o minerador sairá após concluir o processo de auto-tuning. Isso é útil
quando você quer procurar as configurações ideais e depois usar o argumento de linha de comando resultante
exibido pelo minerador.
--allow_large_alloc Se presente, e quando o driver indicar que há vram suficiente disponível na GPU, o minerador
será mais agressivo na alocação inicial de memória. Na prática, esta opção
significa que GPUs Vega no Linux começarão o processo de auto-tuning em 16*15, em vez de
16*14 ou 15*15.
Opções do MTP:
--allow_all_devices Alguns algoritmos não podem ser minerados, por exemplo, em GPUs de 4GB. Essas GPUs serão desativadas automaticamente
pelo minerador. Este argumento substitui essa lógica e permite minerar em todos os dispositivos especificados
ou detectados.
Opções do X16*:
--hash_order=VALUE Define uma ordem de hash fixa para algoritmos como x16r, para fins de benchmark.
Esta configuração colocará automaticamente o minerador no modo de benchmark.
A ordem de hash padrão de benchmark para x16r é --hash_order=0123456789abcdef.
Opções do Nimiq:
--nimiq_worker=VALUE Define o nome do worker/dispositivo do nimiq a ser passado ao(s) pool(s).
--nimiq_no_proxy Desativa o proxy automático do Nimiq executado como processo separado. Isso significa que o
host e a porta passados ao minerador devem apontar para um proxy.
--nimiq_proxy=VALUE Substitui o caminho padrão do proxy do Nimiq. O padrão é trm_nimiq_proxy-win.exe
e trm_nimiq_proxy-linux no diretório atual do minerador.
--nimiq_port=VALUE Substitui a porta local padrão (4444) usada pelo proxy do Nimiq. Pode ser usado se o seu
sistema já estiver usando a porta 4444 para algum outro serviço tcp/ip.
Opções do Verthash:
--verthash_file=FILE Define o nome do arquivo usado para carregar/armazenar o arquivo de dados do verthash. Se esta opção for
especificada ao usar o algoritmo verthash, o minerador tentará carregar os dados do verthash
a partir do arquivo. Se o arquivo não existir, o minerador gerará os dados do verthash
e depois os salvará no arquivo para uso futuro. Se esta opção não for especificada, o
minerador gerará os dados do verthash na memória do sistema a cada inicialização.
--verthash_max_uploads=N Algumas placas-mãe têm problemas quando todas as GPUs do rig enviam a tabela do verthash
ao mesmo tempo. Este argumento limita o número de GPUs que enviam
a tabela simultaneamente na inicialização. Os valores permitidos são 1-32. O valor padrão é 4.
Opções do Autolykos2:
--autolykos_mem_adjust=N Define a quantidade de memória em MiB que o minerador deve deixar sem uso ao alocar
buffers de GPU para o autolykos. O valor padrão é 384 no linux e 512 no windows. Para GPUs
com monitores conectados, o padrão é aumentado em 512. Na mineração dual com ZIL, o
valor padrão é aumentado em 1024. A opção também pode ser informada como uma lista de valores
separados por vírgula, em que cada valor é aplicado a cada GPU. Se um valor vazio for especificado
na lista, o padrão será usado para essa GPU. Se não houver valor especificado para uma GPU,
ela usará o primeiro valor da lista. A quantidade de vram usada precisa comportar tanto os buffers
principais quanto qualquer buffer pré-construído para a próxima altura. Por exemplo:
--autolykos_mem_adjust=256,512,,256
--autolykos_prebuild=N Configura a velocidade da pré-construção do pad para a próxima altura. Um valor maior significa uma pré-construção mais rápida,
mas com maiores oscilações de consumo de energia e provavelmente uma queda maior de hashrate enquanto a pré-construção
estiver rodando. Os valores válidos são 0-9, em que 0 significa nenhuma pré-construção e 9 é a variante mais rápida.
O valor padrão é 3 ou 4, dependendo da GPU. Você pode especificar um único valor para todas as
GPUs ou uma lista de valores por GPU separados por vírgula.
--autolykos_slowdown=N Adiciona uma desaceleração ao processo de construção do pad. Os valores válidos são 0-100. O padrão é 0, sem
desaceleração.
--autolykos_ignore_diff Ignora a dificuldade enviada pelo pool e usa apenas o target de 256 bits fornecido nos jobs.
Alguns pools não seguem a implementação de pool do minerador de referência do ERGO; nesse caso, este
argumento _pode_ ajudar. OBSERVAÇÃO: isto será aplicado a todos os pools.
Opções de mineração dual com ZIL:
--zil_start ou --zil Inicia a configuração de mineração dual com ZIL. Entre este marcador e o --zil_end, todos os argumentos são
aplicados à mineração de ZIL, e não ao algoritmo principal. Espera-se que o algoritmo principal
tenha sido configurado nos argumentos anteriores. A ideia é que você possa adicionar uma configuração --zil ... --zil_end
a qualquer configuração de algoritmo do TRM que já funcione, e tudo funcione de imediato.
Este argumento define automaticamente uma série de configurações padrão que você vai querer usar para ZIL:
- Cópia em cache do DAG da época 0 do ZIL.
- Ajuste da memória alocada para o algoritmo principal para caber o DAG do ZIL.
- Escolha do modo A do ethash para a mineração de ZIL.
A configuração mínima funcional é informar apenas um pool de ZIL que aceite que o minerador ignore
os jobs da moeda principal e só minere durante as janelas de ZIL. Este é um exemplo para o ezil.me:
--zil -o stratum+tcp://eu.ezil.me:5555 -u <eth wallet>.<zil wallet>.<worker name> -p x --zil_end
Para mais informações, leia o guia de mineração dual com ZIL incluído na versão do TRM.
--zil_end Indica que terminamos a configuração da mineração de ZIL e que todos os argumentos seguintes são para o algoritmo
principal. Este argumento não é estritamente necessário, mas deve ser incluído em distros de mineração, já que
o usuário não tem garantia de quais argumentos serão adicionados automaticamente ao final da linha
de comando pela distro.
--stats_mode=single/dual Ao adicionar a mineração dual com ZIL, a saída de estatísticas será por padrão duplicada para incluir informações
da mineração de ZIL. Alguns contextos podem se confundir com isso se estiverem analisando a saída ou os
arquivos de log do TRM. Para voltar à saída padrão, adicione --stats_mode=single.
Opções do TON:
--ton_pool_mode=X Especifica o dialeto de mineração de TON usado. Se não for definido, o minerador tentará deduzir a escolha correta
a partir do nome de host do pool. As opções disponíveis são:
toncoinpool - usa o protocolo stratum wss do toncoinpool.
icemining - usa o protocolo stratum do ice mining sobre tcp/ip.
tonpool - usa a versão do tonpool do protocolo stratum do ice mining sobre wss.
--wss_force_proxy Força a ativação do proxy wss automático, executado como processo separado, usado para pools de TON que rodam seu
protocolo de mineração sobre wss. Normalmente o minerador ativa isso automaticamente, mas se for usado um endereço IP bruto
ou um nome de host com alias para a conexão, este argumento pode ser necessário.
--wss_no_proxy Desativa o proxy wss automático, executado como processo separado, usado para pools de TON que rodam seu
protocolo de mineração sobre wss. Isso significa que o host e a porta passados ao minerador devem apontar
para um proxy.
--wss_proxy=VALUE Substitui o caminho padrão do proxy wss. O padrão é trm_nimiq_proxy-win.exe
e trm_nimiq_proxy-linux no diretório atual do minerador, já que originalmente ele só era usado para o
Nimiq.
--wss_port=VALUE Substitui a porta local padrão (4444) usada pelo proxy wss. Pode ser usado se o seu
sistema já estiver usando a porta 4444 para algum outro serviço tcp/ip.
Opções de mineração dual com Ethash:
--ton_start ou --ton Inicia a configuração de mineração dual com TON. Entre este marcador e o --ton_end, todos os argumentos são
aplicados à mineração de TON, e não ao algoritmo principal, normalmente o ethash. Espera-se que
o ethash tenha sido configurado nos argumentos anteriores. A ideia é que você possa adicionar uma configuração --ton ... --ton_end
a qualquer configuração de algoritmo do TRM que já funcione, e tudo funcione de imediato.
A configuração mínima funcional é informar apenas um pool de TON. Leia o guia de mineração de TON para saber quais
pools são suportados. Este é um exemplo para o icemining, usando o endereço do pool beta:
--ton -o stratum+tcp://ton.hashrate.to:4003 -u <ton wallet>.<worker name> -p x --ton_end
Para mais informações, leia o guia de mineração dual com TON incluído na versão do TRM.
--ton_end Indica que terminamos a configuração da mineração de TON e que todos os argumentos seguintes são para o algoritmo
principal. Este argumento não é estritamente necessário, mas deve ser incluído em distros de mineração, já que
o usuário não tem garantia de quais argumentos serão adicionados automaticamente ao final da linha
de comando pela distro.
--kas_start ou --kas Inicia a configuração de mineração dual com Kaspa. Entre este marcador e o --kas_end, todos os argumentos são
aplicados à mineração de Kaspa, e não ao algoritmo principal, normalmente o ethash. Espera-se que
o ethash tenha sido configurado nos argumentos anteriores. A ideia é que você possa adicionar uma configuração --kas ... --kas_end
a qualquer configuração de algoritmo do TRM que já funcione, e tudo funcione de imediato.
A configuração mínima funcional é informar apenas um pool de Kaspa. Este é um exemplo:
--kas -o stratum+tcp://pool.woolypooly.com:3112 -u <kaspa wallet>.<worker name> -p x --kas_end
--kas_end Indica que terminamos a configuração da mineração de Kaspa e que todos os argumentos seguintes são para o algoritmo
principal. Este argumento não é estritamente necessário, mas deve ser incluído em distros de mineração, já que
o usuário não tem garantia de quais argumentos serão adicionados automaticamente ao final da linha
de comando pela distro.
--dual_intensity=X,Y,Z,... Este argumento ajusta a intensidade da mineração dual com um fator entre 0.0 e 1.0, em que 1.0
significa rodar o máximo possível do algoritmo dual. Esta opção é recomendada para forçar a redução do consumo de energia
sem baixar o clock do núcleo, o que também afetaria o hashrate do ethash.
O argumento é informado como um único valor global ou como uma lista de valores por GPU. Exemplos:
--dual_intensity=0.75 Todas as GPUs usam 75% da disponibilidade máxima possível da GPU para TON.
--dual_intensity=0.75,1.0,0.5 Valores separados para as três primeiras GPUs do rig; as GPUs restantes
usam o primeiro valor, 75%.
--dual_tuner_step=X Define o tamanho de passo que o dual tuner deve usar ao testar diferentes intensidades de eth config. Um valor
menor significa resultados mais precisos, mas também leva mais tempo. Os valores válidos são 1,2,4,8,16,32,64.
--dual_tuner_period=X Define o número de segundos que o dual tuner deve rodar para cada configuração testada. O padrão é 7 s.
--dual_tuner_weights=X:Y:Z O tuner de mineração dual precisa de pesos de pontuação que indiquem quanto vale 1 MH/s do algoritmo principal e do
algoritmo dual. Há padrões embutidos no minerador que eram válidos quando cada algoritmo foi implementado
e adicionado, mas, à medida que os hashrates das redes e os preços de mercado mudam, pode ser preciso informar novos valores.
Este argumento recebe três valores, todos números positivos:
X Pontuação para 1 MH/s do algoritmo principal (normalmente ethash).
Y Pontuação para 1 MH/s do algoritmo secundário (normalmente TON ou Kaspa).
Z Custo por 1 W de consumo medido. Por enquanto, recomendamos definir isto como zero.
Exemplo para ETH+TON:
Com base em um valor relativo manual: cada MH/s de ETH vale 100 MH/s de TON/Kaspa
--dual_tuner_weights=100:1:0
Com base em calculadoras de mineração: $0.0437 por 1 MH/s de ETH, $0.0005476 por 1 MH/s de TON/Kaspa
--dual_tuner_weights=0.0437:0.0005476:0
Opções de FPGA:
--fpga_devices=LIST Define quais dispositivos FPGA da lista detectada serão usados. LIST deve ser uma lista separada por vírgulas de
índices de dispositivos ou DNAs de dispositivos, conforme exibido por --list_devices.
Exemplos: -d 0,1,2,4
-d 40020000013ae32135111111,40020000013ae32135222222,40020000013ae32135333333
Se não for especificado, todos os dispositivos FPGA disponíveis serão usados.
--fpga_clk_core=LIST Define as frequências de clock do núcleo dos dispositivos FPGA. As frequências devem ser informadas como uma
lista de valores em megahertz separados por vírgula, em que cada valor se aplica a cada dispositivo FPGA.
Se a lista for menor que o número total de dispositivos, os dispositivos restantes usarão o
primeiro valor da lista. Por exemplo, --fpga_clk_core=600,620 aplicará clock de 600MHz à
FPGA 0 e 620MHz à FGPA 1. Se houver dispositivos FPGA 2+, eles serão definidos em 600MHz.
--fpga_clk_mem=LIST Define as frequências de clock da memória dos dispositivos FPGA. O formato é o mesmo de --fpga_clk_core.
--fpga_vcc_int=LIST Define a tensão vcc_int nas placas que a suportam. Os valores de tensão devem ser informados como uma
lista de valores em milivolts (mV) separados por vírgula, em que cada valor se aplica a cada placa.
Se a lista for menor que o número total de dispositivos, os dispositivos restantes usarão o
primeiro valor da lista. Por exemplo, --fpga_vcc_int=700,800 aplicará 700mV de vcc_int à
FPGA 0 e 800mV de vcc_int à FGPA 1. Se houver dispositivos FPGA 2+, eles serão definidos em 700mV.
--fpga_vcc_bram=LIST Define a tensão vcc_bram nas placas que a suportam. O formato é o mesmo de --fpga_vcc_int.
--fpga_vcc_mem=LIST Define a tensão da memória/HBM nas placas que a suportam. O formato é o mesmo de --fpga_vcc_int.
--fpga_update_fw Ativa a atualização do firmware do satellite controller em placas C1100 com firmware TRM personalizado,
para suportar recursos como o controle de tensão em tempo de execução. Só serão atualizadas as placas selecionadas com a
opção --fpga_devices que não estiverem rodando a versão mais recente do firmware.
***** ATENÇÃO: tome cuidado para não interromper o processo de atualização do firmware! *****
***** Interrupções podem deixar a placa inutilizada (brick), muito difícil de recuperar. *****
--fpga_allow_unsafe=LIST Desativa os limites de segurança padrão para as FPGAs especificadas. Os dispositivos são especificados com uma
lista de valores de DNA separados por vírgula, por exemplo --fpga_allow_unsafe=40020000013ae32135111111
***** ATENÇÃO: rodar acima dos limites de segurança pode causar DANOS PERMANENTES ao dispositivo! *****
--fpga_tcore_limit=LIST Define os limites suaves de temperatura do núcleo dos dispositivos FPGA. Se a temperatura do núcleo da FPGA ultrapassar o
valor especificado, o minerador reduzirá os clocks da FPGA para trazer a temperatura do núcleo abaixo
do valor especificado. Os valores são em Celsius, com formato de lista semelhante ao de --fpga_clk_core.
--fpga_tmem_limit=LIST Define os limites suaves de temperatura da memória dos dispositivos FPGA. Veja a descrição em --fpga_tcore_limits.
--fpga_ivccint_limit=LIST Define os limites suaves de corrente do regulador de tensão VCCINT. Veja a descrição em --fpga_tcore_limits.
--fpga_ivccbram_limit=LIST Define os limites suaves de corrente do regulador de tensão VCCBRAM. Veja a descrição em --fpga_tcore_limits.
--fpga_max_jtag_mhz=XY.Z Define a frequência máxima permitida para a comunicação jtag da FPGA. O padrão é 30.0 MHz.
--fpga_eth_clk_dag=LIST Define as frequências de clock do núcleo da FPGA usadas durante a construção do DAG do Ethash. Por padrão, elas
serão definidas em 90% do clock normal do núcleo. O formato é o mesmo de --fpga_clk_core.
