TeamRedMiner — Guía completa
Opciones:
-a, --algo=ALGORITHM Selecciona el algoritmo de minería. Disponibles actualmente:
ethash (eth, etp, otros)
etchash (etc, alias de -a ethash --eth_variant_mode=etchash)
kawpow (ravencoin)
firopow (firo)
mtp_firopow (elige firopow o mtp y detiene el minero en el fork del 26 de octubre 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 del fork de firopow)
cuckatoo31_grin (grin)
cuckarood29_grin (grin)
cnv8
cnr (monero antiguo)
cnv8_half (stellite, masari)
cnv8_dbl (x-cash)
cnv8_rwz (graft)
cnv8_trtl (turtlecoin antiguo, loki)
cnv8_upx2 (uplexa)
cn_heavy (CN heavy clásico)
cn_haven (haven)
cn_saber (bittube)
cn_conceal (conceal)
trtl_chukwa (turtlecoin)
trtl_chukwa2 (turtlecoin)
-h, --help Muestra este mensaje de ayuda y sale.
--debug Activa la salida del log de depuración.
--hardware=HW_LIST Indica en qué tipos de hardware debe intentar ejecutarse el minero, como lista separada por comas.
Los valores admitidos actualmente son 'gpu' y 'fpga'. Por ejemplo:
--hardware=gpu,fpga
--benchmark Activa el modo benchmark. Se ignoran todos los pools definidos y se añade automáticamente
un único pool interno ficticio. Para hacer benchmark de algoritmos como eth y kawpow en épocas
y alturas de bloque concretas, también debes añadir argumentos específicos del algoritmo, como --eth_epoch=456 y --prog_height=123456.
--disable_colors Desactiva los colores en la salida de la consola.
--force_colors Fuerza los colores en la consola aunque parezca que el terminal no los admite.
--api_listen=IP:PORT Activa la API compatible con sgminer. IP:PORT es opcional. Si se indica, la combinación IP:PORT
define la(s) interfaz(ces) y el puerto de escucha. El valor por defecto es 127.0.0.1:4028. Para
acceso externo, usa por ejemplo 0.0.0.0:4028. También es válido indicar solo el
puerto, p. ej. 4029. Ahora se puede repetir este argumento para tener endpoints separados.
--api2_listen=IP:PORT Activa un segundo puerto de API para configuraciones de minería dual. Este endpoint de la API ofrece datos del
algoritmo dual, igual que si se ejecutaran dos instancias separadas del minero en paralelo. El
valor por defecto es 127.0.0.1:4029, es decir, el puerto es 4029 y no 4028. Para indicar tu
propio valor, el argumento tiene el mismo formato que --api_listen. Ahora se puede repetir este argumento
para tener endpoints separados.
--cm_api_listen=IP:PORT Activa la API compatible con Claymore. IP:PORT es opcional. Si se indica, la combinación IP:PORT
define la(s) interfaz(ces) y el puerto de escucha. El valor por defecto es 127.0.0.1:3333. Para
acceso externo, usa por ejemplo 0.0.0.0:3333. También es válido indicar solo el
puerto, p. ej. 3334.
--cm_api_password=PSW Establece la contraseña requerida para la interfaz de la API compatible con CM.
--log_file(=FILENAME) Guarda la salida del minero en el archivo indicado por FILENAME. Si no se indica
un nombre de archivo, el minero escribe en trm_<algo>_<yyyymmdd_hhmmss>.log en el
directorio de trabajo actual. Si el archivo de log ya existe, el minero añade al final.
-l, --log_interval=SEC Establece el intervalo en segundos para promediar y mostrar el hashrate de las GPU.
SEC define el intervalo en segundos y debe ser > 0.
--log_rotate=SZ[,CNT] Activa la rotación de logs. El valor SZ define el tamaño del log a partir del cual se crea
un nuevo archivo. El valor SZ admite los sufijos 'k', 'M' y 'G', que multiplican el
valor por 1024, 1048576 y 1073741824 respectivamente. El valor opcional CNT define el
número máximo de logs antiguos que se conservan. Por ejemplo, la opción '--log_rotate=4M,16'
hace que el minero cambie a un nuevo archivo de log cuando el actual supere
4194304 bytes, y el minero conservará los últimos 16 archivos de este tipo y borrará
los más antiguos.
--short_stats Desactiva la salida completa del estado de las GPU en cada informe de hashrate, como antes de 0.7.10.
--dev_location=LOC Selecciona una ubicación concreta para la conexión de la comisión del desarrollador. Úsalo solo si ves
problemas continuos de conexión de la dev fee reportados por el minero. La gestión de la
conexión normalmente funciona bien en todas las ubicaciones. Opciones disponibles:
world - Cualquier lugar del mundo excepto China continental.
non-gcp - Países con acceso bloqueado a los servicios de Google (p. ej. Irán, Cuba).
cn - China continental.
eu - UE, Rusia, Ucrania y alrededores.
us - EE. UU., Canadá, Centroamérica/Sudamérica.
asia - Asia excepto China.
--enable_compute (Solo Windows) Activa el modo de cómputo y desactiva crossfire en las GPU que lo necesiten.
--long_timestamps Activa marcas de tiempo en microsegundos en los logs en lugar de solo segundos.
--restart_gpus (Solo Windows) Reinicia todas las GPU configuradas antes de minar, es decir, desactiva+activa el dispositivo PCI.
--uac (Solo Windows) Activa la elevación de privilegios cuando el minero realiza tareas como reiniciar GPU.
Siempre puedes evitarlo ejecutando el minero directamente como Administrador. Esto
mostrará el aviso estándar de elevación de Windows, así que tendrás que estar presente para hacer clic en 'Sí'.
Si no está activado, las tareas que requieren privilegios de Administrador fallarán cuando el
minero se ejecute con una cuenta de usuario normal.
--high_score Muestra en las estadísticas los 15 mejores shares encontrados desde el inicio del minero.
Nota: puede que no esté disponible para todos los algoritmos.
--allow_dup_bus_ids Permite que varias GPU usen el mismo ID de bus PCI. Solo debe usarse con tarjetas Radeon Pro Duo
y hardware similar; normalmente indica un entorno OpenCL defectuoso.
--dns_https=URL Activa la resolución DNS del pool mediante DNS-over-HTTPS. Es una función experimental. TRM solo
admite la variante basada en JSON, no el mecanismo definido posteriormente en RFC8484. Debes
indicar la URL https completa, incluido el nombre del método. Se permite usar nombres de host
en lugar de direcciones IP, pero esos nombres se resolverán con el DNS del sistema.
Estos son algunos ejemplos que se ha comprobado que funcionan:
--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 (Cloudflare DNS service)
--dns_https_sni=HOST Cuando se usa el argumento --dns_https, por defecto no se envía SNI en la
conexión SSL/TLS. Con este argumento puedes forzar el envío de cualquier SNI. Ten en cuenta
que es un argumento de red avanzado y la mayoría de usuarios no lo necesita.
--kernel_vm_mode=X (Solo Linux). Automatiza la configuración de los parámetros del kernel necesarios en /etc/default/grub en sistemas
Linux basados en Debian/Ubuntu. Esto cubre la mayoría de distros de minería. El sistema puede reiniciarse
automáticamente con /sbin/reboot cuando se modifican los parámetros del kernel. Si los parámetros
correctos ya están configurados, el minero y el script auxiliar no hacen nada. Esto significa que
este argumento puede estar siempre en la línea de comandos. Valores válidos:
N - sin modo configurado, elimina los parámetros existentes de C- o R-mode. Sin reinicio al cambiar.
C - antiguo C-mode de Radeon VII. Sin reinicio al cambiar.
R - nuevo R-mode para todas las GPU excepto Polaris. Sin reinicio al cambiar.
RN - sin modo configurado, elimina los parámetros existentes de C- o R-mode. Reinicia al cambiar.
RC - antiguo C-mode de Radeon VII. Reinicia al cambiar.
RR - nuevo R-mode para todas las GPU excepto Polaris. Reinicia al cambiar.
--kernel_vm_mode_script=X (Solo Linux). Indica el script que se llama para establecer los nuevos parámetros de modo del kernel.
El script debe comportarse como el script de TRM por defecto incluido en el paquete del minero,
llamado ubuntu_mode_script.sh. Normalmente este argumento no debería ser necesario.
--gpu_sdma=on|off Controla si el controlador usa operaciones sdma directas para copiar memoria desde/hacia
la GPU. Este argumento solo se necesita en situaciones muy especiales. Por ejemplo, la AMD BC-250
no admite sdma y necesita --gpu_sdma=off. Si ves bloqueos justo en la inicialización de la GPU,
pero otros mineros o versiones antiguas de TRM funcionan bien, prueba --gpu_sdma=off.
Este ajuste es de entorno y afecta a todas las GPU.
Opciones de configuración del pool:
-o, --url=URL Establece la URL del pool. Actualmente se admiten URL stratum+tcp y stratum+ssl.
Cada vez que se repite esta opción se inicia una nueva configuración de pool.
Las opciones por pool (como -u, -p) deben indicarse explícitamente
de nuevo para cada pool nuevo. (Mira el archivo de ejemplo start_multipool.sh/bat)
La estrategia multipool del minero se define con la opción --pool_strategy.
También hay soporte especial para configuraciones SSL/TLS avanzadas en las que necesitas
pasar un nombre de host SNI al endpoint SSL. Por ejemplo, es necesario para endpoints SSL
que actúan como frontend de varios hosts y necesitan saber para cuál
deben presentar el certificado. En esos casos, usa el siguiente formato:
-o stratum+ssl://pool.tunnel.com/pool.realhostname.com:3333
Esto se conectará a pool.tunnel.com:3333 pero pasará pool.realhostname.com como nombre de host
SNI en la fase de handshake SSL. Por supuesto, los dos nombres de host también pueden ser idénticos.
-u, --user=USERNAME Establece el nombre de usuario para la autorización en el pool.
-p, --pass=PASSWORD Establece la contraseña para la autorización en el pool.
--pool_force_ensub Fuerza una solicitud de suscripción a extranonce en pools compatibles que el minero no conoce.
--pool_no_ensub Evita que el minero envíe al pool la solicitud de suscripción a extranonce.
--pool_broken_rpc Indica al minero que solo permita una solicitud rpc pendiente en la conexión
con el pool. Es una solución para pools que incumplen la especificación json rpc
en cuanto a los ID de rpc.
--pool_ratio=RATIO Establece la proporción de hashrate entre pools al usar varios pools con las estrategias
'load_balance' o 'quota' (ver --pool_strategy). Por defecto, todos los
pools usan la proporción 1. Por ejemplo, usar esta opción con valor 2 en
un solo pool hará que ese pool reciba el doble de hashrate que los demás,
ya que su proporción seguirá siendo el valor por defecto 1.
--pool_debug Registra todo el tráfico del pool.
Opciones globales de pools:
--pool_connect_TO=SEC Establece el tiempo de espera al intentar conectar con un pool. SEC es el tiempo de espera en
segundos. Por defecto es 10.
--pool_rpc_TO=SEC Establece cuánto esperará el minero una respuesta del pool a un RPC. Pasado ese
tiempo, el minero se reconectará al pool. SEC es el tiempo de espera en segundos.
Por defecto es 60.
--pool_max_rejects=N Si un pool rechaza N shares seguidos, se reinicia la conexión con el pool. Sirve para protegerse
de pools que invalidan las sesiones de minería sin desconectar al usuario.
El valor por defecto es 5.
--pool_share_limit_ms=N Si un pool tarda más de N ms en aceptar o rechazar un share, se cierra la conexión
actual y se reconecta. Está pensado para pools que suelen tener problemas con
algunos de sus servidores; al reconectar, el balanceo de carga te lleva a otro servidor,
con suerte mejor. Por defecto no hay tiempo de espera.
--pool_strategy=STRAT Establece la estrategia de selección de pools al trabajar con varios pools. Los valores
disponibles son: priority, load_balance, quota y min_epoch. Por defecto es priority.
priority: El minero usa los pools en el orden en que se listan y solo pasa
al siguiente pool si el anterior no puede establecer conexión.
load_balance: El minero reparte el hashrate de forma uniforme entre todos los pools
conectados en ese momento. La proporción de hashrate entre pools se define con --pool_ratio.
quota: El minero reparte de forma uniforme el total de hashes completados entre
todos los pools. Si un pool se desconecta y luego se reconecta, el minero le dará
hashrate a ese pool hasta que el total de hashes de cada pool quede equilibrado.
La proporción de hashrate entre pools se define con --pool_ratio.
min_epoch: Estrategia de cambio ETH + ZIL. El minero siempre mina la época más baja
entre todos los pools conectados y, en caso de empate, el primer pool conectado.
Por eso, indica tu pool de ETH como primer pool/principal y después el pool de ZIL
como segundo pool. También puedes usar 'eth_zil' como nombre de esta estrategia.
--no_ntime_roll Impide que el minero modifique ntime en la cabecera del bloque y usa solo el valor
que da el pool. Hay que activarlo en algunos pools al minar x16rt.
--no_stale_submit Impide que el minero envíe shares que no corresponden al trabajo más reciente del pool.
Opciones de GPU:
--platform=INDEX Establece el índice de la plataforma OpenCL a usar. Si no se indica, la plataforma se
detecta automáticamente. En Linux con varias plataformas solo se admite no usar el argumento
--platform y añadir en su lugar --bus_reorder.
-d, --devices=DEVLIST Establece las GPU a usar de la lista detectada. DEVLIST debe ser una lista de índices
de dispositivos separados por comas, p. ej. -d 0,1,2,4. Si no se indica, se usarán todos
los dispositivos de la(s) plataforma(s). NOTA: por defecto los dispositivos se ordenan
según el bus pcie. Usa --list_devices para ver los índices.
--init_style=1/2/3 Indica el estilo de inicialización (1 por defecto):
1: Una GPU a la vez, se completan todas antes de minar.
2: Tres GPU a la vez, se completan todas antes de minar.
3: Todas las GPU en paralelo, empieza a minar de inmediato.
--pcie_fmt=FORMAT Establece el formato de impresión de los números de bus pcie. Los valores aceptados para FORMAT son
'hex' o 'dec'. Por defecto es dec en Windows y hex en Linux.
--bus_reorder Reordena los dispositivos detectados o indicados según su ID de bus pcie. Si no se
indica plataforma, se recogen los dispositivos de todas las plataformas AMD OpenCL
detectadas. Nota: desde la versión v0.7.0 este es el comportamiento por defecto.
--opencl_order Ordena los dispositivos detectados o indicados en el orden en que los presenta OpenCL.
--list_devices Lista los dispositivos disponibles de la plataforma detectada o indicada y sale
de inmediato. El reordenamiento por bus se aplica al orden mostrado.
--nr_cu_override=X,Y,... Sobrescribe el número de compute units por GPU que informa la API de OpenCL. Es
útil sobre todo para Vega 64 flasheadas con BIOS de 56, en las que el controlador
informa 56 CU en lugar del número real. Indica como valor del argumento una lista separada
por comas con el número de CU por GPU. Puedes omitir GPU y no
necesitas dar valores para todas las GPU del rig. Ejemplo para un rig mixto con dos Vega
en los índices 1 y 3 y otras dos GPU: --nr_cu_override=,64,,64. Puedes verificar el
argumento añadiendo también --list_devices antes de minar.
Opciones de control de frecuencias/voltajes (solo Windows, función BETA):
El minero tiene funciones básicas para ajustar las frecuencias de core y memoria y sus
voltajes, así como para elegir entre los timings integrados del controlador de Windows. Para cada
argumento de abajo, enumeras los valores para las GPU del rig en una lista separada
por comas. Algunos argumentos no se usan en ciertas GPU. Puedes omitir GPU en la lista.
El minero siempre establece y usa el p-state más alto tanto para core como para memoria en GPU GCN
(Polaris, Vega). Ten en cuenta que las GPU Rx Vega _deben_ tener modificada la tabla powerplay
en el p-state p2 de memoria para poder funcionar con un voltaje inferior a 900mV. Además, las GPU
Big Navi todavía necesitan usar p. ej. MorePowerTool para modificar la tabla powerplay, por ejemplo
para poder establecer un voltaje más bajo. Es _posible_ que el minero añada soporte para funciones
relacionadas con la tabla powerplay en el futuro.
--clk_debug Activa mensajes de log al inicio relacionados con el ajuste de frecuencias/voltajes/timings.
--clk_core_mhz=MHZ1,MHZ2,... Establece la frecuencia del core por GPU en MHz.
--clk_core_mv=MV1,MV2,... Establece el voltaje del core por GPU en mV.
--clk_mem_mhz=MHZ1,MHZ2,... Establece la frecuencia de la memoria por GPU en MHz.
--clk_mem_mv=MV1,MV2,... Establece el voltaje de la memoria por GPU en mV. No se usa en GPU Navi ni Big Navi.
--clk_timing=V1,V2,... Elige entre los conjuntos de timings de memoria disponibles en el controlador. No disponible en todas las GPU y
controladores.
Ejemplo de línea de comandos parcial para un sistema de cuatro GPU con una Rx Vega 64, 580, 5700XT y
6800 minando ethash o similar. Solo indicamos el voltaje de memoria para la Vega y la 580, y solo elegimos
un valor de timing del controlador para la 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
Opciones de control de ventiladores:
--fan_control(=CFG1,CFG2,...) Este argumento activa el control de los ventiladores de las GPU por parte del minero. TRM admite
el ajuste automático de la velocidad de los ventiladores según la temperatura del core, junction y/o memoria.
También admitimos fijar una velocidad estática del ventilador en porcentaje.
Cada tipo de GPU tiene una configuración de ventilador que se usa por defecto. Se puede
tanto sobrescribir la configuración por defecto de cada tipo de GPU como establecer
una configuración específica para cada GPU del rig.
Una configuración de ventilador consta de (como máximo) seis valores separados por ':' (dos puntos). Los valores
son: temperatura objetivo del core, temperatura objetivo de junction, temperatura objetivo de memoria, velocidad inicial
del ventilador en porcentaje, velocidad mínima en porcentaje, velocidad máxima en porcentaje. Cualquier valor puede quedar vacío.
Algunos ejemplos:
::70:50:25 Temperatura objetivo de memoria 70C, ventilador inicial al 50%, velocidad mínima 25%.
55::::20:80 Temperatura objetivo del core 55C, ventilador inicial a la velocidad de la configuración por defecto,
mantener siempre el ventilador entre 20% y 80%.
55::75:80 Ajusta el ventilador para que el core esté a <= 55C y la memoria a <= 75C, ventilador
inicial al 80%.
:::100 Fija la velocidad del ventilador al 100%, sin ajustar nunca según las temperaturas.
La configuración de ventilador usada para una GPU se determina en el siguiente orden de prioridad:
1. Se pasó al argumento --fan_control una lista de configuraciones que incluye una
entrada para la GPU X.
2. Se sobrescribió la configuración por defecto para este tipo de GPU con un
parámetro --fan_default_<type>=....
3. Se usa la configuración de ventilador integrada por defecto para este tipo de GPU.
En la lista anterior, si a la configuración elegida le falta el valor inicial del ventilador,
se usa el de la siguiente configuración.
NOTA: el control de ventiladores es una función beta y no funcionará mejor que el soporte que
ofrecen los controladores. Por ejemplo, muchas veces los controladores en linux no permiten forzar un
ventilador al 100% mediante el soporte pwm de sysfs.
--fan_default_polaris=CFG Establece la configuración por defecto para todas las GPU Polaris (450/460/550/560/470/480/570/580/590).
El valor integrado por defecto es 55:::50: core a 55C y ventilador inicial al 50%.
Nota: este ajuste también se usa para las GPU Tonga.
--fan_default_vega=CFG Establece la configuración por defecto para todas las GPU Vega (Vega 56/Vega 64).
El valor integrado por defecto es 55::70:50: core a 55C, memoria a 70C y ventilador al 50%.
--fan_default_vega2=CFG Establece la configuración por defecto para todas las GPU Radeon VII.
El valor integrado por defecto es 70::75:80: core a 70C, memoria a 75C y ventilador al 80%.
--fan_default_navi=CFG Establece la configuración por defecto para todas las Navi (Navi10).
El valor integrado por defecto es 60::80:70: core a 60C, memoria a 80C y ventilador al 70%.
--fan_default_big_navi=CFG Establece la configuración por defecto para todas las Big Navi (Navi21).
El valor integrado por defecto es 50:::70: core a 50C y ventilador al 70%. No se incluye
la temperatura de memoria porque falta el sensor en la librería ADL de Windows.
--fan_debug Activa mensajes de log relacionados con los ajustes.
--fan_no_restore Desactiva la restauración de los perfiles de ventilador originales al cerrar el minero.
Opciones del watchdog:
--no_gpu_monitor Desactiva el monitor de GPU ADL (Windows) o sysfs (Linux) de temperatura y
velocidad del ventilador.
--temp_limit=TEMP Establece la temperatura del core a la que el minero detendrá las GPU demasiado calientes.
Por defecto es 85C. Se pueden dar valores por GPU con una lista separada por comas,
un valor por GPU. Si una GPU no tiene un valor definido, se usa el primer valor
de la lista.
--temp_resume=TEMP Establece la temperatura del core por debajo de la cual el minero reanudará las GPU que se
detuvieron por superar el límite de temperatura del core. Por defecto es 60C. Se pueden dar
valores por GPU con una lista separada por comas, un valor por GPU. Si una GPU no
tiene un valor definido, se usa el primer valor de la lista.
--mem_temp_limit=TEMP Establece la temperatura de memoria a la que el minero detendrá las GPU demasiado calientes.
Desactivado por defecto. Solo se usa si la GPU tiene sensor de temperatura de memoria.
Se pueden dar valores por GPU con una lista separada por comas, un valor por GPU.
Si una GPU no tiene un valor definido, se usa el primer valor de la lista.
--mem_temp_resume=TEMP Establece la temperatura de memoria por debajo de la cual el minero reanudará las GPU que se
detuvieron por superar el límite de temperatura de memoria. Desactivado por defecto. Solo
se usa si la GPU tiene sensor de temperatura de memoria. Se pueden dar valores por GPU
con una lista separada por comas, un valor por GPU. Si una GPU no tiene un valor definido,
se usa el primer valor de la lista.
--watchdog_script(=X) Configura el watchdog de GPU para que detenga el minero, ejecute el script de la plataforma
indicado y salga de inmediato. El script por defecto es watchdog.bat/watchdog.sh en el
directorio actual, pero se puede indicar otro script como argumento opcional,
también con una ruta absoluta o relativa.
--watchdog_test Prueba el script de watchdog configurado provocando la misma acción que una GPU caída
tras ~20 s de minería.
--watchdog_disabled Fuerza que el watchdog no se ejecute. Sirve para desactivar el watchdog en sistemas de minería
que siempre funcionan con el watchdog activado.
Opciones de Ethash:
--eth_config=CONFIG Configuración manual de ethash para el minero. CONFIG debe tener el formato [X][M][L].
El valor [M] selecciona el modo, que puede ser 'A','B' o 'C'.
El modo 'B' usa memoria adicional y solo funciona en tarjetas de 8+GB.
El modo 'C' usa memoria adicional y solo funciona en tarjetas de 16+GB, como la VII, con
un sistema correctamente configurado. Consulta ETHASH_TUNING_GUIDE.txt para más detalles.
El valor [L] selecciona la intensidad y su rango depende de la arquitectura de la GPU.
El prefijo [X] es opcional y solo para Navi/Big Navi; activa más operaciones de memoria y
da un valor de ajuste [L] más bajo. Puede ser útil cuando el autoajuste llega repetidamente
a un valor cercano al máximo posible para la GPU.
Ambos valores son opcionales, pero si se indica [L], también hay que indicar [M].
Ejemplos de configuración: --eth_config=A
--eth_config=B750
--eth_config=XB
CONFIG también puede ser una lista de configuraciones separadas por comas, donde cada una
se aplica a cada GPU. Por ejemplo: --eth_config=A,B750,,A288
Cualquier GPU sin una configuración específica en la lista usará la primera
configuración de la lista.
--eth_variant_mode=X Este argumento controla la activación de los cambios de ethash para ETC a partir de la época 390, según
ecip-1099. Están disponibles los siguientes modos:
pool - Modo por defecto. Solo se activa si el pool envía un flag de algoritmo que contenga etchash.
Una vez visto este flag, todos los trabajos del pool se consideran etchash hasta que
se reciba otro flag de algoritmo que contenga ethash.
etchash - Modo etchash. Las épocas >= 390 se consideran etchash y las anteriores ethash. No se usan
los flags de algoritmo del pool.
deduce - Ignora los flags de algoritmo del pool y solo aplica una heurística basada en la hora actual del sistema
y en las alturas y tiempos conocidos de ETC y ETH. Este modo debería funcionar como enfoque
genérico cuando ETH llegue a la época 390 en enero de 2021. El reloj del sistema debe estar en hora.
También debería manejar configuraciones de cambio por rentabilidad que alternan libremente entre trabajos
ethash y etchash mediante un proxy de los pools subyacentes.
auto - Mientras el pool no haya enviado un flag de algoritmo, usa el modo deduce. Cuando se vea un flag
de algoritmo, cambia al modo pool.
ethash - Modo ethash forzado. Nunca aplica ecip-1099.
force_etc - Modo etchash forzado. Siempre aplica las reglas de ecip-1099. Úsalo para minar en la testnet de ETC.
--eth_aggr_mode Activa el uso automático del modo 'B' en todas las tarjetas Polaris de 8GB, salvo que tengan
otra configuración indicada con el argumento --eth_config. Equivale a
poner manualmente todas las GPU Polaris de 8GB del rig en modo 'B' con --eth_config.
En la mayoría de GPU añade 0.1-0.2 MH/s de hashrate. NOTA: el 20-25% de los rigs se vuelve menos
estable en este modo, por eso no es el modo por defecto. Si tienes
GPU que se caen, quita este argumento y usa las GPU en modo 'A'.
--eth_stratum_mode=MODE Establece un modo stratum fijo para pools ethash. Por defecto el minero intenta
detectar automáticamente el tipo de stratum que admite el pool y usa ese modo.
Esta detección automática se puede anular con esta opción. MODE puede
tomar uno de estos valores: stratum, nicehash, ethproxy.
--eth_worker Establece el ID del worker que se envía al pool. Solo se aplica a pools con el modo
stratum ethproxy.
--eth_hash_report=X Controla los informes de hashrate a los pools configurados. Este valor se aplica a todos los pools. Valores:
default - el minero decide según el protocolo stratum usado en cada pool.
force - envía siempre informes de hashrate, aunque el pool los rechace.
on - envía un primer informe de hashrate y lo desactiva en cualquier pool que rechace el mensaje.
off - nunca envía informes de hashrate.
--eth_epoch Prueba una época ethash concreta. NOTA: esto cambia automáticamente el minero a modo benchmark, como
si añadieras --benchmark.
--eth_alloc_epoch=N Reserva desde el inicio memoria suficiente para la época indicada. El minero intentará reservar más
si lo necesita más adelante durante la minería.
--eth_dag_buf=X,Y,... El minero puede reservar uno o dos buffers para el DAG. Por ahora, el valor por defecto es AUTO. Un solo
buffer es algo mejor y ahorra un poco de energía en todos los tipos de GPU. Solo los controladores recientes admiten
reservas únicas mayores de 4GiB, normalmente a partir de Adrenalin 20.9.1 y amdgpu-pro 20.x. Con este argumento
el minero puede usar automáticamente el modo de buffer único cuando sea posible, o forzar uno o dos
buffers por GPU. Valores admitidos: A(uto), S(ingle), D(ual). Puedes indicar una lista separada por comas
para todas las GPU del rig, o un único valor para todas. Una GPU sin valor en la
lista separada por comas usará el primer valor.
--eth_big_mode_adjust=X,Y,... En los modos B o C, el minero funciona mejor cuanta más vram puede reservar. Por desgracia, los
controladores no informan con precisión cuánta memoria se puede reservar, sobre todo en Windows.
El minero usa un margen seguro y conservador de 256MiB (Linux) y 512MiB (Windows) respecto al
tamaño de vram disponible. Si quieres cambiar este número, puedes hacerlo con este argumento indicando
una lista separada por comas con valores para una o más GPU. Se ignoran los valores de las GPU que no
funcionen en modo B/C. Si una GPU no tiene valor en la lista, se usa el primer valor indicado.
El intervalo permitido es [-64, 2048]. Cuanto mayor es el número, menos vram se reserva en la GPU.
--eth_dag_slowdown=N Ralentiza la generación del DAG. Indica un solo dígito 0-9. 0 significa sin ralentización (comportamiento <= 0.7.9),
1 significa ralentización mínima, 9 la máxima. Valor por defecto: 4, una ligera ralentización.
--eth_stagger Escalona las GPU al construir un nuevo DAG. Es más suave con las fuentes de alimentación que no llevan bien
pasar de 0 a 100% de carga en todas las GPU a la vez.
--eth_no_stagger Desactiva --eth_stagger. Ya es el comportamiento por defecto desde 0.7.18. El argumento se mantiene solo por
compatibilidad.
--eth_ramp_up Sube la intensidad de forma gradual en todas las GPU tras construir el DAG, desactivar/activar una GPU o un corte de red.
Puede ayudar a rigs que se cuelgan justo entre la construcción del DAG y el inicio de la minería.
--eth_no_ramp_up Desactiva --eth_ramp_up. Ya es el comportamiento por defecto desde 0.7.18. El argumento se mantiene solo por
compatibilidad.
--eth_direct_abort Usa otro mecanismo para abortar los trabajos en curso de la GPU. Recomendado para Vega en entornos ROCm
para minimizar los shares obsoletos. Solo se aplica a las GPU Vega y Polaris del rig.
--eth_dag_alloc_patch Algunas placas base con BIOS desactualizada pueden mostrar errores de hardware, normalmente en la primera o última GPU del sistema.
Usa este argumento para forzar una estrategia de reserva del DAG modificada que casi siempre resuelve el problema.
Actualizar la BIOS también suele resolverlo.
--eth_hashwatch(=M,M) Define un hashrate mínimo/máximo en MH/s esperado mientras las GPU minan, para el watchdog. Si una GPU sale
de este rango durante demasiado tiempo, se considera defectuosa y se activa el watchdog. Los
valores mínimo/máximo por defecto son 2 MH/s y 150 MH/s. Para activarlo con los valores por defecto, usa
--eth_hashwatch. Para indicar tus propios valores, usa p. ej. --eth_hashwatch=1.25,60. Se usa el mismo rango
para todas las GPU del rig. Un valor negativo en un extremo lo desactiva; p. ej. usa --eth_hashwatch=-1,1000
para detectar reinicios de GPU que dan hashrates falsos enormes, sin comprobar el mínimo.
--eth_dag_cache(=EPOCH) Guarda los DAG de eth de trabajos con distintas épocas para no tener que reconstruirlos en el
futuro si vuelven a llegar trabajos con las épocas anteriores. Se guarda como máximo un DAG si la memoria
de la GPU lo permite. Es útil para pools que alternan, como la minería eth+zil. Si quieres preconstruir una
época concreta justo al arrancar, añade el valor opcional. Los mineros que alternan eth+zil deben usar
--eth_dag_cache=0. Por ahora solo se pueden preconstruir épocas de ethash (no de etchash).
--eth_dag_cache_resv=MEM Establece la cantidad de memoria de GPU que el minero intentará dejar libre cuando funciona con la caché
de DAG activada (ver --eth_dag_cache). El argumento MEM es la cantidad de memoria a dejar libre en
mebibytes. El valor por defecto es 256.
--eth_dag_cache_verify Activa la lectura y verificación de la caché del dag tras terminar de construirlo. Esto detecta situaciones
en las que la caché del dag tenía errores de bits y el dag resultante está parcialmente dañado. Hemos visto que
esto ocurre cada vez más en las Vega a medida que el dag ha crecido. Si se detecta, se reserva un nuevo
buffer para la caché del dag y se reinicia la construcción del dag.
--eth_micro_delay=VAL,VAL,... Añade un retardo (en microsegundos) al volver a encolar trabajo en la(s) GPU.
Las fuentes de alimentación más débiles que alimentan muchas GPU a veces no soportan el "slew rate" cuando varias GPU
vuelven a encolar trabajo exactamente al mismo tiempo. Ponerlo en p. ej. 32 suaviza la transición
de carga cero a 100% lo suficiente para reducir el slew rate en esos rigs. El síntoma típico de este
problema son cuelgues totales en los que el rig deja de responder y hay que cortar la corriente para reiniciarlo, aunque
también pueden ser caídas normales de GPU. Valores válidos: 0-256. Se pueden dar valores por GPU en una lista separada por comas.
Las GPU sin valor en la lista usarán el primer valor. Los valores por defecto de este argumento en
minería de solo ethash son:
Polaris: 64
Vega: 0
Navi: 0
--eth_ignore_abort_fail Cuando falla el aborto de un trabajo, suele deberse a una intensidad demasiado alta, y por eso el minero
la baja automáticamente. Esta opción _desactiva_ esa lógica: mantiene la intensidad y
en su lugar registra una advertencia.
--eth_no_job_logs Suprime todos los logs de trabajos nuevos recibidos del/de los pool(s). Se aplica a todas las sesiones de minería de la familia ethash,
es decir, en una configuración dual eth+zil se suprimen los logs de los pools de eth y de zil. Los trabajos del pool que
cambian a una nueva época se seguirán registrando.
--eth_smooth_power=X,Y,... El modo de planificación "smooth power" se añadió en 0.10.0 y está disponible para todos los tipos de GPU.
En general es una buena función que añade un poco de hashrate y además mejora la estabilidad en la mayoría de
los casos, y está activada por defecto en todas las GPU. Sin embargo, hay rigs que no reaccionan bien y
empiezan a fallar. En ese caso, puedes usar este argumento para controlar la función por GPU en tu rig.
Valores válidos: 0 o 1. Para un rig de 5 GPU podrías usar --eth_smooth_power=0,1,1,1,0 para desactivar smooth
power en la primera y la última GPU. Si no indicas un valor para una GPU, se usa el primer valor de la lista.
Esto significa que puedes desactivar la función en todo el rig con --eth_smooth_power=0.
Opciones de Progpow (kawpow, firopow):
--prog_config=CONFIG Configuración manual de progpow para el minero. CONFIG debe tener el formato [M][L].
El valor [M] selecciona el modo, que puede ser 'A' o 'B'.
El modo 'B' suele dar mejor rendimiento, pero solo está disponible para
Vega en linux y Navi (linux o windows).
El valor [L] selecciona la intensidad y su rango depende de la arquitectura de la GPU.
Ambos valores son opcionales, pero si se indica [L], también hay que indicar [M].
Ejemplos de configuración: --prog_config=A
--prog_config=B750
CONFIG también puede ser una lista de configuraciones separadas por comas, donde cada una
se aplica a cada GPU. Por ejemplo: --prog_config=A,B750,,A288
Cualquier GPU sin una configuración específica en la lista usará la primera.
--prog_height=VALUE Establece una altura de bloque fija para los algoritmos progpow con fines de benchmark. Esto cambia
automáticamente el minero a modo benchmark.
--prog_strict Obliga al minero a generar siempre kernels estrictamente exactos. Por defecto el minero
genera kernels relajados que usan menos potencia de cálculo pero pueden producir
algún share inválido de vez en cuando.
--prog_dag_slowdown=N Ralentiza la generación del DAG. Indica un solo dígito 0-9. 0 significa sin ralentización (comportamiento <= 0.7.9),
1 significa ralentización mínima, 9 la máxima. Valor por defecto: 4, una ligera ralentización.
--prog_stagger Ver --eth_stagger.
--prog_ramp_up Ver --eth_ramp_up.
--prog_no_stagger Ver --eth_no_stagger.
--prog_no_ramp_up Ver --eth_no_ramp_up.
--prog_micro_tune=X,Y,... Esta opción activa una pequeña sesión de reajuste para cada nuevo bloque de código aleatorio. Es importante
para que las GPU Polaris funcionen a su velocidad máxima. En Vega y Navi normalmente no mejora
el rendimiento. El modo AUTO por defecto lo activa en todas las GPU Polaris y lo desactiva en las demás.
El único motivo para desactivarlo sería la estabilidad. El valor del argumento es una
lista de valores separados por comas, uno por GPU. Si falta el valor de una GPU, se usa el de la
primera GPU. Ten en cuenta que establecer un prog_config manual también desactiva en la práctica el
microajuste. Valores disponibles:
1 - DESACTIVA el microajuste de progpow en esta GPU.
2 - ACTIVA el microajuste de progpow en esta GPU.
3 - deja que el minero decida si activar el microajuste (AUTO).
--prog_hash_report Activa el envío forzado de informes de hashrate (como en ethash) a todos los pools. Es un alias de
--eth_hash_report=force, que también se aplica porque progpow y ethash usan el mismo
protocolo de pool.
Opciones de Cryptonight:
--rig_id Establece el identificador del rig que se envía al pool. Solo se usa en
pools cryptonight.
--cn_config=CONFIG Configuración manual de cryptonight para el minero. CONFIG debe tener el formato
[P][I0][M][I1][:xyz], donde [P] es un prefijo opcional y [:xyz] es un
sufijo opcional. Para [P], solo se admite el valor 'L' para GPU de gama
baja como Lexa/Baffin. [I0] e [I1] son los valores de intensidad de los hilos, normalmente
de 1 a 16, aunque en GPU de 16GB son posibles valores mayores. [M] es el
modo, que puede ser '.', -', '+' o '*'. El modo '.' significa que el minero
debe elegir o buscar el mejor modo. El modo '*' es un buen valor por defecto y
_debería_ usarse si minas con una Vega 56/64 con timings de memoria modificados. Las
excepciones a esta regla son las variantes de pad pequeño (cnv8_trtl y cnv8_upx2), que
deben seguir usando '+'. En GPU Polaris solo están disponibles los modos '-' y '+'.
NOTA: en TRM 0.5.0 se añadió el autoajuste, por lo que la configuración manual
de los modos CN ya no es necesaria salvo en casos excepcionales. Para más información,
consulta los documentos de ajuste y las guías incluidas en la versión.
Ejemplos de configuración: --cn_config=15*15:AAA
--cn_config=14-14
--cn_config=L4+3
CONFIG también puede ser una lista de configuraciones separadas por comas, donde cada una
se aplica a cada GPU. Por ejemplo: --cn_config=8-8,16+14:CBB,15*15,14-14
Cualquier GPU sin una configuración específica en la lista usará la primera
configuración de la lista.
--no_cpu_check Desactiva la verificación por CPU de los shares encontrados antes de enviarlos al pool.
Nota: por ahora solo los algoritmos CN admiten la verificación por CPU.
--no_lean Desactiva el modo lean de CN, que sube los hilos poco a poco al iniciar o al reiniciar tras
problemas de red o throttling por temperatura de la GPU.
--no_interleave=DEVS Lista las GPU en las que no se debe usar la lógica de intercalado de hilos CN.
El argumento es una lista de dispositivos separados por comas, como en la opción -d.
Usa este argumento si algún dispositivo da peor hashrate junto con muchos
mensajes de log de ajuste del intercalado.
--alloc_patch=DEVS Lista las GPU que pierden hashrate entre TRM v0.4.5 y versiones posteriores. Con este
argumento se usa una estrategia de reserva de memoria más simple y se debería recuperar
el hashrate anterior (más alto). Se puede seguir usando el modo de autoajuste.
--auto_tune=MODE Activa el modo de autoajuste al arrancar. Solo disponible para variantes CN. MODE debe
ser NONE, QUICK o SCAN. El modo QUICK prueba algunas configuraciones conocidas como buenas
y termina en 1 min. El modo SCAN prueba todas las combinaciones posibles y
tarda 20-30 min. Con MODE en NONE se desactiva el autoajuste. El modo
por defecto es QUICK.
--auto_tune_runs(=N) Ejecuta varias pasadas de autoajuste, reduciendo cada vez en 1 la unidad de pads usada
en uno de los hilos (15+15 -> 15+14 -> 14+14 -> 14+13 -> ...). Puedes indicar el
número exacto de pasadas o dejar que el minero elija un valor por defecto según el tipo de GPU (normalmente 3-4).
--auto_tune_exit Si está presente, el minero se cierra al terminar el autoajuste. Es útil
cuando quieres buscar los ajustes óptimos y luego usar el argumento de línea de comandos resultante
que muestra el minero.
--allow_large_alloc Si está presente y el controlador indica que hay suficiente vram libre en la GPU, el minero
será más agresivo en la reserva inicial de memoria. En la práctica, esta opción
hace que las GPU Vega en Linux empiecen el autoajuste en 16*15 en lugar de
16*14 o 15*15.
Opciones de MTP:
--allow_all_devices Algunos algoritmos no se pueden minar, por ejemplo, en GPU de 4GB. El minero desactiva
esas GPU automáticamente. Este argumento anula esa lógica y permite minar en todos los
dispositivos indicados o detectados.
Opciones de X16*:
--hash_order=VALUE Establece un orden de hash fijo para algoritmos como x16r con fines de benchmark.
Este ajuste cambia automáticamente el minero a modo benchmark.
El orden de hash estándar de benchmark para x16r es --hash_order=0123456789abcdef.
Opciones de Nimiq:
--nimiq_worker=VALUE Establece el nombre del worker/dispositivo de nimiq que se pasa al/a los pool(s).
--nimiq_no_proxy Desactiva el proxy automático de Nimiq que se ejecuta como proceso aparte. Esto significa que el
host y el puerto que se pasan al minero deben apuntar a un proxy.
--nimiq_proxy=VALUE Sobrescribe la ruta por defecto del proxy de Nimiq. Por defecto es trm_nimiq_proxy-win.exe.
y trm_nimiq_proxy-linux en el directorio actual del minero.
--nimiq_port=VALUE Sobrescribe el puerto local por defecto (4444) del proxy de Nimiq. Úsalo si tu
sistema ya usa el puerto 4444 para otro servicio tcp/ip.
Opciones de Verthash:
--verthash_file=FILE Establece el nombre del archivo para cargar/guardar los datos de verthash. Si se indica esta
opción al usar el algoritmo verthash, el minero intentará cargar los datos de verthash
desde el archivo. Si el archivo no existe, el minero generará los datos de verthash
y los guardará en el archivo para usarlos más adelante. Si no se indica esta opción, el
minero generará los datos de verthash en la memoria del sistema en cada arranque.
--verthash_max_uploads=N Algunas placas base tienen problemas cuando todas las GPU del rig cargan la tabla verthash
al mismo tiempo. Este argumento limita el número de GPU que cargan la tabla
simultáneamente al arrancar. Valores permitidos: 1-32. El valor por defecto es 4.
Opciones de Autolykos2:
--autolykos_mem_adjust=N Establece la cantidad de memoria en MiB que el minero debe dejar libre al reservar
los buffers de GPU para autolykos. El valor por defecto es 384 en linux y 512 en windows. En GPU
con monitores conectados, el valor por defecto aumenta en 512. En minería dual con ZIL, el
valor por defecto aumenta en 1024. La opción también admite una lista de valores separados
por comas, donde cada valor se aplica a cada GPU. Si se indica un valor vacío
en la lista, se usa el valor por defecto para esa GPU. Si no se indica un valor para una GPU,
usará el primer valor de la lista. La vram usada debe poder contener tanto los buffers
principales como cualquier buffer preconstruido para la siguiente altura. Por ejemplo:
--autolykos_mem_adjust=256,512,,256
--autolykos_prebuild=N Configura la velocidad de preconstrucción del pad de la siguiente altura. Un valor más alto significa una preconstrucción más rápida,
pero con mayores fluctuaciones de consumo y probablemente una mayor caída de hashrate mientras dure la
preconstrucción. Valores válidos: 0-9, donde 0 significa sin preconstrucción y 9 es la variante más rápida.
El valor por defecto es 3 o 4 según la GPU. Puedes indicar un único valor para todas
las GPU o una lista de valores separados por comas, uno por GPU.
--autolykos_slowdown=N Ralentiza el proceso de construcción del pad. Valores válidos: 0-100. Por defecto es 0, sin
ralentización.
--autolykos_ignore_diff Ignora la dificultad que envía el pool y usa solo el target de 256 bits incluido en los trabajos.
Algunos pools no siguen la implementación de pool del minero de referencia de ERGO; en ese caso este
argumento _podría_ ayudar. NOTA: se aplica a todos los pools.
Opciones de minería dual con ZIL:
--zil_start o --zil Inicia la configuración de minería dual con ZIL. Entre este argumento y el marcador --zil_end, todos los argumentos se
aplican a la minería de ZIL y no al algoritmo principal. Se espera que el algoritmo principal
esté configurado en argumentos anteriores. La idea es que puedas añadir una configuración --zil ... --zil_end
a cualquier configuración de TRM que funcione y todo funcione sin más.
Este argumento establece automáticamente una serie de ajustes por defecto recomendados para ZIL:
- Copia en caché del DAG de la época 0 de ZIL.
- Ajuste de la memoria reservada para el algoritmo principal para que quepa el DAG de ZIL.
- Modo A de ethash para la minería de ZIL.
La configuración mínima es indicar solo un pool de ZIL que acepte que el minero ignore
los trabajos de la moneda principal y mine solo durante las ventanas de ZIL. Este es un ejemplo para ezil.me:
--zil -o stratum+tcp://eu.ezil.me:5555 -u <eth wallet>.<zil wallet>.<worker name> -p x --zil_end
Para más información, lee la guía de minería dual con ZIL incluida en la versión de TRM.
--zil_end Marca el final de la configuración de minería de ZIL; todos los argumentos siguientes son para el algoritmo
principal. No es estrictamente necesario, pero conviene incluirlo en las distros de minería, ya que
el usuario no sabe con certeza qué argumentos añadirá automáticamente la distro al final de la línea
de comandos.
--stats_mode=single/dual Al añadir minería dual con ZIL, la salida de estadísticas se duplica por defecto para añadir la información
de la minería de ZIL. Esto puede confundir a herramientas que analizan la salida o los
archivos de log de TRM. Para volver a la salida por defecto, añade --stats_mode=single.
Opciones de TON:
--ton_pool_mode=X Indica el dialecto de minería de TON a usar. Si no se establece, el minero intentará deducir la opción correcta
a partir del nombre de host del pool. Opciones disponibles:
toncoinpool - usa el protocolo stratum sobre wss de toncoinpool.
icemining - usa el protocolo stratum de ice mining sobre tcp/ip.
tonpool - usa la versión de tonpool del protocolo stratum de ice mining sobre wss.
--wss_force_proxy Fuerza la activación del proxy wss automático, que se ejecuta como proceso aparte, para pools de TON que usan su
protocolo de minería sobre wss. Normalmente el minero lo activa automáticamente, pero si para conectar se usa
una dirección IP directa o un nombre de host alias, puede ser necesario este argumento.
--wss_no_proxy Desactiva el proxy wss automático, que se ejecuta como proceso aparte, para pools de TON que usan su
protocolo de minería sobre wss. Esto significa que el host y el puerto que se pasan al minero deben apuntar
a un proxy.
--wss_proxy=VALUE Sobrescribe la ruta por defecto del proxy wss. Por defecto es trm_nimiq_proxy-win.exe y.
y trm_nimiq_proxy-linux en el directorio actual del minero, ya que originalmente solo se usaba para.
Nimiq.
--wss_port=VALUE Sobrescribe el puerto local por defecto (4444) del proxy wss. Úsalo si tu
sistema ya usa el puerto 4444 para otro servicio tcp/ip.
Opciones de minería dual con Ethash:
--ton_start o --ton Inicia la configuración de minería dual con TON. Entre este argumento y el marcador --ton_end, todos los argumentos se
aplican a la minería de TON y no al algoritmo principal, normalmente ethash. Se espera que
ethash esté configurado en argumentos anteriores. La idea es que puedas añadir una configuración --ton ... --ton_end
a cualquier configuración de TRM que funcione y todo funcione sin más.
La configuración mínima es indicar solo un pool de TON. Lee la guía de minería de TON para ver los
pools compatibles. Este es un ejemplo para icemining, con la dirección de su pool beta:
--ton -o stratum+tcp://ton.hashrate.to:4003 -u <ton wallet>.<worker name> -p x --ton_end
Para más información, lee la guía de minería dual con TON incluida en la versión de TRM.
--ton_end Marca el final de la configuración de minería de TON; todos los argumentos siguientes son para el algoritmo
principal. No es estrictamente necesario, pero conviene incluirlo en las distros de minería, ya que
el usuario no sabe con certeza qué argumentos añadirá automáticamente la distro al final de la línea
de comandos.
--kas_start o --kas Inicia la configuración de minería dual con Kaspa. Entre este argumento y el marcador --kas_end, todos los argumentos se
aplican a la minería de Kaspa y no al algoritmo principal, normalmente ethash. Se espera que
ethash esté configurado en argumentos anteriores. La idea es que puedas añadir una configuración --kas ... --kas_end
a cualquier configuración de TRM que funcione y todo funcione sin más.
La configuración mínima es indicar solo un pool de Kaspa. Este es un ejemplo:
--kas -o stratum+tcp://pool.woolypooly.com:3112 -u <kaspa wallet>.<worker name> -p x --kas_end
--kas_end Marca el final de la configuración de minería de Kaspa; todos los argumentos siguientes son para el algoritmo
principal. No es estrictamente necesario, pero conviene incluirlo en las distros de minería, ya que
el usuario no sabe con certeza qué argumentos añadirá automáticamente la distro al final de la línea
de comandos.
--dual_intensity=X,Y,Z,... Este argumento ajusta la intensidad de la minería dual con un factor entre 0.0 y 1.0, donde 1.0
significa ejecutar todo el algoritmo dual que sea posible. Se recomienda esta opción para reducir el consumo
sin bajar la frecuencia del core, lo que también afectaría al hashrate de ethash.
El argumento se indica como un único valor global o como una lista de valores por GPU. Ejemplos:
--dual_intensity=0.75 Todas las GPU usan el 75% de la disponibilidad máxima posible de la GPU para TON.
--dual_intensity=0.75,1.0,0.5 Valores separados para las tres primeras GPU del rig; las demás GPU
usan el primer valor, 75%.
--dual_tuner_step=X Establece el tamaño de paso que usa el ajustador dual al probar distintas intensidades de configuración de eth. Un valor
más bajo da resultados más precisos, pero también tarda más. Valores válidos: 1,2,4,8,16,32,64.
--dual_tuner_period=X Establece cuántos segundos debe funcionar el ajustador dual con cada configuración probada. Por defecto son 7 s.
--dual_tuner_weights=X:Y:Z El ajustador de minería dual necesita pesos de puntuación que indiquen cuánto vale 1 MH/s del algoritmo principal
y del dual. El minero trae valores por defecto que eran válidos cuando se implementó y añadió cada algoritmo,
pero como el hashrate de la red y los precios de mercado cambian, puede que haya que indicar valores nuevos.
Este argumento recibe tres valores, todos números positivos:
X Puntuación por 1 MH/s del algoritmo principal (normalmente ethash).
Y Puntuación por 1 MH/s del algoritmo secundario (normalmente TON o Kaspa).
Z Coste por 1 W de consumo medido. Por ahora recomendamos dejarlo en cero.
Ejemplo para ETH+TON:
Según un valor relativo manual: cada MH/s de ETH vale 100 MH/s de TON/Kaspa
--dual_tuner_weights=100:1:0
Según calculadoras de minería: $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
Opciones de FPGA:
--fpga_devices=LIST Establece los dispositivos FPGA a usar de la lista detectada. LIST debe ser una lista separada por comas de
índices de dispositivo o DNA de dispositivo, tal como los muestra --list_devices.
Ejemplos: -d 0,1,2,4
-d 40020000013ae32135111111,40020000013ae32135222222,40020000013ae32135333333
Si no se indica, se usarán todos los dispositivos FPGA disponibles.
--fpga_clk_core=LIST Establece las frecuencias del core de los dispositivos FPGA. Las frecuencias se indican como una
lista de valores en megahercios separados por comas, donde cada valor se aplica a cada dispositivo FPGA.
Si la lista es más corta que el número total de dispositivos, los dispositivos restantes usarán el
primer valor de la lista. Por ejemplo, --fpga_clk_core=600,620 aplicará 600MHz a la
FPGA 0 y 620MHz a la FGPA 1. Si hay dispositivos FPGA 2+, se configurarán a 600MHz.
--fpga_clk_mem=LIST Establece las frecuencias de memoria de los dispositivos FPGA. El formato es el mismo que en --fpga_clk_core.
--fpga_vcc_int=LIST Establece el voltaje vcc_int en las placas que lo admiten. Los voltajes se indican como una
lista de valores en milivoltios (mV) separados por comas, donde cada valor se aplica a cada placa.
Si la lista es más corta que el número total de dispositivos, los dispositivos restantes usarán el
primer valor de la lista. Por ejemplo, --fpga_vcc_int=700,800 aplicará 700mV de vcc_int a la
FPGA 0 y 800mV de vcc_int a la FGPA 1. Si hay dispositivos FPGA 2+, se configurarán a 700mV.
--fpga_vcc_bram=LIST Establece el voltaje vcc_bram en las placas que lo admiten. El formato es el mismo que en --fpga_vcc_int.
--fpga_vcc_mem=LIST Establece el voltaje de memoria/HBM en las placas que lo admiten. El formato es el mismo que en --fpga_vcc_int.
--fpga_update_fw Activa la actualización del firmware del controlador satélite en placas C1100 con firmware TRM personalizado
para admitir funciones como el control de voltaje en tiempo real. Solo se actualizarán las placas seleccionadas con la
opción --fpga_devices que no tengan la última versión del firmware.
***** PRECAUCIÓN: ¡No interrumpas el proceso de actualización del firmware! *****
***** Una interrupción puede dejar la placa inservible y muy difícil de recuperar. *****
--fpga_allow_unsafe=LIST Desactiva los límites de seguridad por defecto para las FPGA indicadas. Los dispositivos se indican con una
lista de valores DNA separados por comas, p. ej. --fpga_allow_unsafe=40020000013ae32135111111
***** PRECAUCIÓN: ¡Superar los límites de seguridad puede DAÑAR PERMANENTEMENTE el dispositivo! *****
--fpga_tcore_limit=LIST Establece límites suaves de temperatura del core de los dispositivos FPGA. Si la temperatura del core de la FPGA supera el
valor indicado, el minero bajará las frecuencias de la FPGA para que la temperatura del core quede por debajo
de ese valor. Los valores están en grados Celsius, con un formato de lista similar a --fpga_clk_core.
--fpga_tmem_limit=LIST Establece límites suaves de temperatura de memoria de los dispositivos FPGA. Ver --fpga_tcore_limits para la descripción.
--fpga_ivccint_limit=LIST Establece límites suaves de corriente del regulador de voltaje VCCINT. Ver --fpga_tcore_limits para la descripción.
--fpga_ivccbram_limit=LIST Establece límites suaves de corriente del regulador de voltaje VCCBRAM. Ver --fpga_tcore_limits para la descripción.
--fpga_max_jtag_mhz=XY.Z Establece la frecuencia máxima permitida para la comunicación jtag de la fpga. Por defecto es 30.0 MHz.
--fpga_eth_clk_dag=LIST Establece las frecuencias del core de la FPGA que se usan durante la construcción del DAG de Ethash. Por defecto
se establecen al 90% de la frecuencia normal del core. El formato es el mismo que en --fpga_clk_core.
