TeamRedMiner – Vollständige Anleitung
Optionen:
-a, --algo=ALGORITHM Wählt den Mining-Algorithmus. Derzeit verfügbar:
ethash (eth, etp, andere)
etchash (etc, Alias für -a ethash --eth_variant_mode=etchash)
kawpow (ravencoin)
firopow (firo)
mtp_firopow (wählt firopow oder mtp und beendet den Miner beim Fork am 26. Okt. 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 vor dem firopow-Fork)
cuckatoo31_grin (grin)
cuckarood29_grin (grin)
cnv8
cnr (altes Monero)
cnv8_half (stellite, masari)
cnv8_dbl (x-cash)
cnv8_rwz (graft)
cnv8_trtl (altes turtlecoin, loki)
cnv8_upx2 (uplexa)
cn_heavy (klassisches CN heavy)
cn_haven (haven)
cn_saber (bittube)
cn_conceal (conceal)
trtl_chukwa (turtlecoin)
trtl_chukwa2 (turtlecoin)
-h, --help Zeigt diese Hilfe an und beendet das Programm.
--debug Aktiviert die Debug-Ausgabe im Log.
--hardware=HW_LIST Legt fest, welche Hardwaretypen der Miner nutzen soll, als kommagetrennte Liste.
Derzeit unterstützte Werte sind 'gpu' und 'fpga'. Zum Beispiel:
--hardware=gpu,fpga
--benchmark Aktiviert den Benchmark-Modus. Alle definierten Pools werden ignoriert und automatisch ein
einzelner interner Fake-Pool hinzugefügt. Für Benchmarks von Algorithmen wie eth und kawpow bei bestimmten
Epochen und Blockhöhen müssen Sie zusätzlich algorithmusspezifische Argumente wie --eth_epoch=456 und --prog_height=123456 angeben.
--disable_colors Deaktiviert die farbige Konsolenausgabe.
--force_colors Erzwingt die farbige Konsolenausgabe, auch wenn das Terminal sie scheinbar nicht unterstützt.
--api_listen=IP:PORT Aktiviert die sgminer-kompatible API. IP:PORT ist optional. Falls angegeben, bestimmt die Kombination
IP:PORT die Schnittstelle(n) und den Port, auf dem gelauscht wird. Standard ist 127.0.0.1:4028. Für
externen Zugriff verwenden Sie z. B. 0.0.0.0:4028. Es ist auch zulässig, nur den
Port anzugeben, z. B. 4029. Dieses Argument kann jetzt mehrfach für separate Endpunkte angegeben werden.
--api2_listen=IP:PORT Aktiviert einen zweiten API-Port für Dual-Mining-Setups. Dieser API-Endpunkt liefert Daten für den
Dual-Mining-Algorithmus, so als ob zwei separate Miner-Instanzen parallel laufen würden. Die
Standardeinstellung ist 127.0.0.1:4029, d. h. der Port ist 4029 und nicht 4028. Um einen eigenen Wert
anzugeben, wird das Argument wie --api_listen formatiert. Dieses Argument kann jetzt mehrfach
für separate Endpunkte angegeben werden.
--cm_api_listen=IP:PORT Aktiviert die Claymore-kompatible API. IP:PORT ist optional. Falls angegeben, bestimmt die Kombination
IP:PORT die Schnittstelle(n) und den Port, auf dem gelauscht wird. Standard ist 127.0.0.1:3333. Für
externen Zugriff verwenden Sie z. B. 0.0.0.0:3333. Es ist auch zulässig, nur den
Port anzugeben, z. B. 3334.
--cm_api_password=PSW Legt das erforderliche Passwort für die CM-kompatible API-Schnittstelle fest.
--log_file(=FILENAME) Aktiviert das Protokollieren der Miner-Ausgabe in die mit FILENAME angegebene Datei. Wird kein Dateiname
angegeben, schreibt der Miner in trm_<algo>_<yyyymmdd_hhmmss>.log im aktuellen
Arbeitsverzeichnis. Existiert die Log-Datei bereits, hängt der Miner an.
-l, --log_interval=SEC Legt das Zeitintervall in Sekunden für die Mittelung und Ausgabe der GPU-Hashrates fest.
SEC gibt das Intervall in Sekunden an und muss > 0 sein.
--log_rotate=SZ[,CNT] Aktiviert die Log-Rotation. Der Wert SZ legt die Log-Größe fest, ab der eine neue Log-Datei
erstellt wird. Der Wert SZ unterstützt die Suffixe 'k', 'M' und 'G' und multipliziert den
Wert entsprechend mit 1024, 1048576 bzw. 1073741824. Der optionale Wert CNT legt die
maximale Anzahl aufzubewahrender alter Log-Dateien fest. Zum Beispiel bewirkt die Option '--log_rotate=4M,16',
dass der Miner zu einer neuen Log-Datei wechselt, sobald die aktuelle Log-Datei
4194304 Bytes überschreitet; der Miner behält die letzten 16 solcher Dateien und löscht
ältere.
--short_stats Deaktiviert die vollständige GPU-Statusausgabe bei jeder Hashrate-Ausgabe, wie vor 0.7.10.
--dev_location=LOC Wählt einen bestimmten Standort für die Verbindung der Entwicklergebühr. Verwenden Sie dies nur, wenn der Miner
ständig Verbindungsprobleme bei der Entwicklergebühr meldet. Die Verbindungsverwaltung
funktioniert normalerweise an allen Standorten gut. Verfügbare Optionen sind:
world - Überall auf der Welt außer Festlandchina.
non-gcp - Länder mit gesperrtem Zugriff auf Google-Dienste (z. B. Iran, Kuba).
cn - Festlandchina.
eu - EU, Russland, Ukraine und Umgebung.
us - USA, Kanada, Mittel-/Südamerika.
asia - Asien ohne China.
--enable_compute (Nur Windows) Aktiviert den Compute-Modus und deaktiviert Crossfire auf den betreffenden GPUs.
--long_timestamps Aktiviert Zeitstempel in Mikrosekunden in den Logs statt nur in Sekunden.
--restart_gpus (Nur Windows) Startet alle konfigurierten GPUs vor dem Mining neu, d. h. PCI-Gerät deaktivieren+aktivieren.
--uac (Nur Windows) Aktiviert die Rechteerhöhung, wenn der Miner Aufgaben wie den Neustart von GPUs ausführt.
Sie können dies immer vermeiden, indem Sie den Miner direkt als Administrator ausführen. Dies
löst die standardmäßige Windows-Abfrage zur Rechteerhöhung aus, Sie müssen also da sein, um auf 'Ja' zu klicken.
Ist dies nicht aktiviert, schlagen Aufgaben, die Administratorrechte erfordern, fehl, wenn der
Miner unter einem normalen Benutzerkonto läuft.
--high_score Aktiviert in der Statistikausgabe die Anzeige der 15 besten Shares seit dem Start des Miners.
Hinweis: Dies ist eventuell nicht für alle Algorithmen verfügbar.
--allow_dup_bus_ids Erlaubt mehreren GPUs dieselbe PCI-Bus-ID. Dies sollte nur für Radeon Pro Duo
Karten und ähnliche Hardware verwendet werden, normalerweise deutet es auf eine defekte OpenCL-Umgebung hin.
--dns_https=URL Aktiviert die DNS-Auflösung des Pools über DNS-over-HTTPS. Dies ist eine experimentelle Funktion. TRM
unterstützt nur die JSON-basierte Variante, nicht den später in RFC8484 definierten Mechanismus. Der Benutzer muss
die vollständige https-URL einschließlich des Methodennamens angeben. Es ist zulässig, Hostnamen
statt reiner IP-Adressen anzugeben, diese Hostnamen werden dann jedoch über das System-DNS aufgelöst.
Hier einige Beispiele, deren Funktion überprüft wurde:
--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 Wird das Argument --dns_https verwendet, wird standardmäßig kein SNI in der
SSL/TLS-Verbindung gesendet. Mit diesem Argument können Sie das Senden eines beliebigen SNI erzwingen. Bitte beachten
Sie, dass dies ein fortgeschrittenes Netzwerkargument ist, das die meisten Benutzer nicht benötigen.
--kernel_vm_mode=X (Nur Linux). Automatisiert das Setzen der nötigen Kernelparameter in /etc/default/grub auf Linux-
Systemen auf Basis von Debian/Ubuntu. Das deckt die meisten Mining-Distributionen ab. Das System kann
automatisch über /sbin/reboot neu gestartet werden, wenn die Kernelparameter geändert werden. Sind die richtigen
Parameter bereits gesetzt, tun der Miner und das Hilfsskript nichts. Das bedeutet, dass
dieses Argument immer in der Befehlszeile stehen kann. Gültige Werte sind:
N - kein Modus konfiguriert, entfernt vorhandene Parameter für C- oder R-Modus. Kein Neustart bei Änderung.
C - alter C-Modus der Radeon VII. Kein Neustart bei Änderung.
R - neuer R-Modus für alle GPUs außer Polaris. Kein Neustart bei Änderung.
RN - kein Modus konfiguriert, entfernt vorhandene Parameter für C- oder R-Modus. Neustart bei Änderung.
RC - alter C-Modus der Radeon VII. Neustart bei Änderung.
RR - neuer R-Modus für alle GPUs außer Polaris. Neustart bei Änderung.
--kernel_vm_mode_script=X (Nur Linux). Legt das Skript fest, das zum Setzen neuer Kernelmodus-Parameter aufgerufen wird.
Das Skript muss sich wie das Standard-TRM-Skript aus dem Distributionspaket des Miners verhalten,
das ubuntu_mode_script.sh heißt. Dieses Argument sollte normalerweise nicht nötig sein.
--gpu_sdma=on|off Steuert, ob der Treiber direkte sdma-Operationen zum Kopieren von Speicher von/zur
GPU verwendet. Dieses Argument wird nur in ganz besonderen Situationen benötigt. Zum Beispiel unterstützt die AMD BC-250
kein sdma und benötigt --gpu_sdma=off. Wenn es direkt bei der GPU-Initialisierung zu Hängern kommt,
andere Miner oder ältere TRM-Versionen aber einwandfrei laufen, versuchen Sie --gpu_sdma=off.
Diese Einstellung ist eine Umgebungseinstellung und gilt für alle GPUs.
Pool-Konfigurationsoptionen:
-o, --url=URL Legt die Pool-URL fest. Derzeit werden URLs mit stratum+tcp und stratum+ssl unterstützt.
Jede weitere Angabe dieser Option startet eine neue Pool-Konfiguration.
Pool-spezifische Optionen (wie -u, -p) müssen für jeden neuen Pool erneut
explizit angegeben werden. (Siehe die Beispieldatei start_multipool.sh/bat)
Die Multi-Pool-Strategie des Miners wird mit der Option --pool_strategy festgelegt.
Außerdem gibt es eine spezielle Unterstützung für fortgeschrittene SSL/TLS-Setups, bei denen Sie
dem SSL-Endpunkt einen SNI-Hostnamen übergeben müssen. Das ist zum Beispiel nötig für SSL-
Endpunkte, die als Frontend für mehrere Hosts dienen und wissen müssen, für welchen
sie ein Zertifikat liefern sollen. Verwenden Sie in solchen Fällen folgendes Format:
-o stratum+ssl://pool.tunnel.com/pool.realhostname.com:3333
Damit wird eine Verbindung zu pool.tunnel.com:3333 aufgebaut, aber pool.realhostname.com als SNI-
Hostname in der SSL-Handshake-Phase übergeben. Die beiden Hostnamen können natürlich auch identisch sein.
-u, --user=USERNAME Legt den Benutzernamen für die Autorisierung am Pool fest.
-p, --pass=PASSWORD Legt das Passwort für die Autorisierung am Pool fest.
--pool_force_ensub Erzwingt eine extranonce-Subscribe-Anfrage bei unterstützten Pools, die dem Miner unbekannt sind.
--pool_no_ensub Verhindert, dass der Miner eine extranonce-Subscribe-Anfrage an den Pool sendet.
--pool_broken_rpc Weist den Miner an, nur eine einzige offene RPC-Anfrage auf der Pool-
Verbindung zuzulassen. Dies ist ein Workaround für Pools, die die JSON-RPC-
Spezifikation bezüglich RPC-IDs verletzen.
--pool_ratio=RATIO Legt das Hashrate-Verhältnis zwischen Pools fest, wenn mehrere Pools mit den Pool-Strategien
'load_balance' oder 'quota' verwendet werden (siehe --pool_strategy). Standardmäßig verwenden alle
Pools den Verhältniswert 1. Wird diese Option zum Beispiel mit dem Wert 2 bei
nur einem Pool verwendet, erhält dieser Pool doppelt so viel Hashrate wie die anderen Pools,
da deren Verhältnis weiterhin dem Standardwert 1 entspricht.
--pool_debug Protokolliert den gesamten Pool-Datenverkehr.
Globale Pool-Optionen:
--pool_connect_TO=SEC Legt das Timeout für den Verbindungsversuch zu einem Pool fest. SEC ist die Wartezeit in
Sekunden. Standard ist 10.
--pool_rpc_TO=SEC Legt fest, wie lange der Miner auf eine unbeantwortete RPC-Anfrage an den Pool wartet. Nach dieser
Zeit verbindet sich der Miner neu mit dem Pool. SEC ist die Wartezeit in Sekunden.
Standard ist 60.
--pool_max_rejects=N Lehnt ein Pool N Shares in Folge ab, wird die Pool-Verbindung zurückgesetzt. Dies schützt
vor Pools, die Mining-Sitzungen ungültig machen, ohne den Benutzer zu trennen.
Standardwert ist 5.
--pool_share_limit_ms=N Braucht ein Pool länger als N ms, um einen Share zu akzeptieren oder abzulehnen, wird die aktuelle
Verbindung beendet und neu aufgebaut. Dies ist für Pools gedacht, die oft Probleme mit
einigen ihrer Server haben; ein Reconnect bedeutet, per Load-Balancing auf einen anderen und
hoffentlich besseren Server zu kommen. Standardwert ist kein Timeout.
--pool_strategy=STRAT Legt die Strategie für die Pool-Auswahl beim Betrieb mit mehreren Pools fest. Verfügbare
Werte sind: priority, load_balance, quota und min_epoch. Standard ist priority.
priority: Der Miner verwendet die Pools in der angegebenen Reihenfolge und wechselt nur
zum nächsten Pool, wenn der vorherige keine Verbindung aufbauen kann.
load_balance: Der Miner verteilt die Hashrate gleichmäßig auf alle aktuell
verbundenen Pools. Das Hashrate-Verhältnis zwischen den Pools kann mit --pool_ratio festgelegt werden.
quota: Der Miner verteilt die Gesamtzahl der berechneten Hashes gleichmäßig auf
alle Pools. Trennt sich ein Pool und verbindet sich später wieder, verlagert der Miner
Hashrate auf diesen Pool, bis die Gesamtzahl der Hashes für jeden Pool ausgeglichen ist.
Das Hashrate-Verhältnis zwischen den Pools kann mit --pool_ratio festgelegt werden.
min_epoch: Wechselstrategie für ETH + ZIL. Der Miner mint immer die niedrigste Epoche
unter allen verbundenen Pools, bei Gleichstand den zuerst verbundenen Pool.
Geben Sie daher Ihren ETH-Mining-Pool als ersten/primären Pool an, dann den ZIL-Pool
als zweiten Pool. Sie können für diese Strategie auch den Namen 'eth_zil' verwenden.
--no_ntime_roll Verhindert, dass der Miner ntime im Block-Header verändert; es wird nur der vom Pool
gelieferte Wert verwendet. Dies muss bei einigen Pools beim Mining von x16rt aktiviert werden.
--no_stale_submit Verhindert, dass der Miner Shares sendet, die nicht zum aktuellsten Pool-Job gehören.
GPU-Optionen:
--platform=INDEX Legt den Index der zu verwendenden OpenCL-Plattform fest. Wird er nicht angegeben, wird die Plattform
automatisch erkannt. Linux mit mehreren Plattformen wird nur ohne das Argument
--platform unterstützt, stattdessen mit --bus_reorder.
-d, --devices=DEVLIST Legt fest, welche GPU-Geräte aus der erkannten Liste verwendet werden. DEVLIST muss eine komma-
getrennte Liste von Geräteindizes sein, z. B. -d 0,1,2,4. Ohne Angabe werden alle
Geräte der Plattform(en) verwendet. HINWEIS: Standardmäßig werden die Geräte nach der
Reihenfolge des PCIe-Busses sortiert. Mit --list_devices werden die Indizes angezeigt.
--init_style=1/2/3 Legt den Initialisierungsstil fest (1 ist Standard):
1: Eine GPU nach der anderen, alle abschließen vor dem Mining.
2: Drei GPUs gleichzeitig, alle abschließen vor dem Mining.
3: Alle GPUs parallel, Mining startet sofort.
--pcie_fmt=FORMAT Legt das Ausgabeformat für PCIe-Busnummern fest. Zulässige Werte für FORMAT sind
'hex' oder 'dec'. Standard ist dec für Windows und hex für Linux.
--bus_reorder Sortiert die erkannten oder angegebenen Geräte nach ihrer PCIe-Bus-ID. Ist keine
Plattform angegeben, werden Geräte von allen erkannten AMD-OpenCL-
Plattformen gesammelt. Hinweis: Seit Version v0.7.0 ist dies das Standardverhalten.
--opencl_order Sortiert die erkannten oder angegebenen Geräte in der Reihenfolge, in der OpenCL sie liefert.
--list_devices Listet die verfügbaren Geräte der erkannten oder angegebenen Plattform auf und beendet sich
sofort. Die Bus-Sortierung wird in der angezeigten Reihenfolge angewendet.
--nr_cu_override=X,Y,... Überschreibt die Anzahl der Compute Units pro GPU, wie sie die OpenCL-API meldet. Dies
ist vor allem nützlich für Vega 64 mit geflashtem 56er-BIOS, bei denen der Treiber
56 CU statt der tatsächlichen Anzahl meldet. Geben Sie als Wert des Arguments eine kommagetrennte Liste
der überschriebenen CU-Anzahl pro GPU an. Sie können GPUs überspringen und müssen
nicht für alle GPUs im Rig Werte angeben. Beispiel für ein gemischtes Rig mit zwei Vegas
an Index 1 und 3 und zwei anderen GPUs: --nr_cu_override=,64,,64. Sie können Ihr
Argument überprüfen, indem Sie vor dem Mining zusätzlich --list_devices angeben.
Optionen zur Takt-/Spannungssteuerung (nur Windows, BETA-Funktion):
Der Miner verfügt über grundlegende Funktionen zum Setzen von Core- und Speichertakt sowie der jeweiligen
Spannung und zur Auswahl zwischen den integrierten Timings des Windows-Treibers. Für jedes
unten verfügbare Argument geben Sie die Werte für die GPU(s) im Rig als kommagetrennte
Liste an. Einige Argumente werden für bestimmte GPUs nicht verwendet. Sie können GPUs in der Liste überspringen.
Der Miner setzt und verwendet bei GCN-GPUs (Polaris, Vega) immer den höchsten P-State für Core und Speicher.
Bitte beachten Sie, dass bei Rx-Vega-GPUs die Powerplay-Tabelle für den Speicher-P2-State _unbedingt_ angepasst
werden muss, bevor sie mit einer Spannung unter 900mV laufen können. Außerdem müssen Big-Navi-
GPUs weiterhin z. B. MorePowerTool verwenden, um die Powerplay-Tabelle anzupassen, zum Beispiel
um das Setzen einer niedrigeren Spannung zu ermöglichen. Der Miner wird _eventuell_ künftig Unterstützung für
Funktionen rund um die Powerplay-Tabelle erhalten.
--clk_debug Aktiviert beim Start Log-Ausgaben zum Setzen von Takten/Spannungen/Timings.
--clk_core_mhz=MHZ1,MHZ2,... Legt den Core-Takt pro GPU in MHz fest.
--clk_core_mv=MV1,MV2,... Legt die Core-Spannung pro GPU in mV fest.
--clk_mem_mhz=MHZ1,MHZ2,... Legt den Speichertakt pro GPU in MHz fest.
--clk_mem_mv=MV1,MV2,... Legt die Speicherspannung pro GPU in mV fest. Wird bei Navi- und Big-Navi-GPUs nicht verwendet.
--clk_timing=V1,V2,... Wählt zwischen den verfügbaren Speicher-Timing-Sets des Treibers. Nicht auf allen GPUs und
Treibern verfügbar.
Beispiel einer unvollständigen Befehlszeile für ein System mit vier GPUs, nämlich Rx Vega 64, 580, 5700XT und
6800, die ethash o. Ä. minen. Die Speicherspannung geben wir nur für die Vega und die 580 an, und nur
für die Big Navi wählen wir einen Timing-Wert des Treibers:
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
Optionen zur Lüftersteuerung:
--fan_control(=CFG1,CFG2,...) Dieses Argument aktiviert die Steuerung der GPU-Lüfter durch den Miner. TRM unterstützt
die automatische Anpassung der GPU-Lüfterdrehzahl(en) anhand von Core-, Junction- und/oder Speichertemperatur.
Außerdem unterstützen wir das Setzen einer statischen Lüfterdrehzahl in Prozent.
Jeder GPU-Typ hat eine Lüfterkonfiguration, die standardmäßig verwendet wird. Wir unterstützen
sowohl das Überschreiben der Standardkonfiguration pro GPU-Typ als auch das Setzen einer
eigenen Konfiguration für jede GPU im Rig.
Eine Lüfterkonfiguration besteht aus (max.) sechs Werten, getrennt durch das Zeichen ':' (Doppelpunkt). Die Werte
sind: Ziel-Core-Temperatur, Ziel-Junction-Temperatur, Ziel-Speichertemperatur, anfängliche Lüfterdrehzahl in
Prozent, minimale Lüfterdrehzahl in Prozent, maximale Lüfterdrehzahl in Prozent. Jeder Wert kann leer bleiben.
Hier einige Beispiele:
::70:50:25 Ziel-Speichertemperatur 70C, Lüfter startet mit 50% Drehzahl, minimale Drehzahl 25%.
55::::20:80 Ziel-Core-Temperatur 55C, Lüfter startet mit der Drehzahl der Standardkonfiguration,
Lüfter immer zwischen 20% und 80% halten.
55::75:80 Lüfter so regeln, dass Core-Temperatur <= 55C und Speichertemperatur <= 75C, Lüfter
startet mit 80%.
:::100 Statische Lüfterdrehzahl 100%, nie anhand der Temperaturen anpassen.
Die für eine GPU verwendete Lüfterkonfiguration wird in folgender Rangfolge bestimmt:
1. Dem Argument --fan_control wurde eine Liste von Konfigurationen übergeben, die einen
Eintrag für GPU X enthält.
2. Die Standard-Lüfterkonfiguration für diesen GPU-Typ wurde mit einem Parameter
--fan_default_<type>=... überschrieben.
3. Die integrierte Standard-Lüfterkonfiguration für diesen GPU-Typ wird verwendet.
Fehlt in der obigen Liste der gewählten Konfiguration der Startwert für den Lüfter,
wird die Einstellung aus der nächsten Konfiguration verwendet.
HINWEIS: Die Lüfterunterstützung ist eine Beta-Funktion und funktioniert nicht besser als die Unterstützung, die
die Treiber bieten. Zum Beispiel erlauben die Treiber unter Linux oft nicht, einen
Lüfter über die sysfs-PWM-Unterstützung auf 100% zu zwingen.
--fan_default_polaris=CFG Legt die Standardkonfiguration für alle Polaris-GPUs fest (450/460/550/560/470/480/570/580/590).
Der integrierte Standard ist 55:::50 für 55C Core-Temperatur und Lüfterstart bei 50%.
Hinweis: Diese Einstellung wird auch für Tonga-GPUs verwendet.
--fan_default_vega=CFG Legt die Standardkonfiguration für alle Vega-GPUs fest (Vega 56/Vega 64).
Der integrierte Standard ist 55::70:50 für 55C Core-Temperatur, 70C Speichertemperatur und Lüfter bei 50%.
--fan_default_vega2=CFG Legt die Standardkonfiguration für alle Radeon-VII-GPUs fest.
Der integrierte Standard ist 70::75:80 für 70C Core-Temperatur, 75C Speichertemperatur und Lüfter bei 80%.
--fan_default_navi=CFG Legt die Standardkonfiguration für alle Navi (Navi10) fest.
Der integrierte Standard ist 60::80:70 für 60C Core-Temperatur, 80C Speichertemperatur und Lüfter bei 70%.
--fan_default_big_navi=CFG Legt die Standardkonfiguration für alle Big Navi (Navi21) fest.
Der integrierte Standard ist 50:::70 für 50C Core-Temperatur und Lüfter bei 70%. Der Grund dafür,
dass die Speichertemperatur fehlt, ist ein fehlender Sensor in der Windows-ADL-Bibliothek.
--fan_debug Aktiviert Log-Ausgaben zu den Anpassungen.
--fan_no_restore Deaktiviert die Wiederherstellung der ursprünglichen Lüfterprofile beim Beenden des Miners.
Watchdog-Optionen:
--no_gpu_monitor Deaktiviert die GPU-Überwachung über ADL (Windows) oder sysfs (Linux) für Temperatur und
Lüfterdrehzahl.
--temp_limit=TEMP Legt die Core-Temperatur fest, bei der der Miner zu heiße GPUs anhält.
Standard ist 85C. GPU-spezifische Werte können als kommagetrennte Liste angegeben werden,
ein Wert pro GPU. Hat eine GPU keinen definierten Wert, wird der erste Wert der Liste
verwendet.
--temp_resume=TEMP Legt die Core-Temperatur fest, unterhalb der der Miner GPUs fortsetzt, die zuvor wegen
Überschreitung des Core-Temperaturlimits angehalten wurden. Standard ist 60C. GPU-spezifische
Werte können als kommagetrennte Liste angegeben werden, ein Wert pro GPU. Hat eine GPU
keinen definierten Wert, wird der erste Wert der Liste verwendet.
--mem_temp_limit=TEMP Legt die Speichertemperatur fest, bei der der Miner zu heiße GPUs anhält.
Standardmäßig nicht aktiviert. Wird nur verwendet, wenn die GPU einen Sensor für die Speichertemperatur hat.
GPU-spezifische Werte können als kommagetrennte Liste angegeben werden, ein Wert pro GPU.
Hat eine GPU keinen definierten Wert, wird der erste Wert der Liste verwendet.
--mem_temp_resume=TEMP Legt die Speichertemperatur fest, unterhalb der der Miner GPUs fortsetzt, die zuvor wegen
Überschreitung des Speichertemperaturlimits angehalten wurden. Standardmäßig nicht aktiviert. Wird nur
verwendet, wenn die GPU einen Sensor für die Speichertemperatur hat. GPU-spezifische Werte können
als kommagetrennte Liste angegeben werden, ein Wert pro GPU. Hat eine GPU keinen definierten Wert,
wird der erste Wert der Liste verwendet.
--watchdog_script(=X) Konfiguriert den GPU-Watchdog so, dass er den Miner beendet, das angegebene Plattform-
Skript ausführt und sich sofort beendet. Das Standardskript ist watchdog.bat/watchdog.sh im
aktuellen Verzeichnis, es kann aber auch ein anderes Skript als optionales Argument angegeben werden,
gegebenenfalls auch mit absolutem oder relativem Pfad.
--watchdog_test Testet das konfigurierte Watchdog-Skript, indem nach ~20 Sek. Mining dieselbe Aktion wie bei einer
ausgefallenen GPU ausgelöst wird.
--watchdog_disabled Verhindert die Ausführung des Watchdogs. Damit lässt sich der Watchdog in Mining-Betriebssystemen
deaktivieren, die immer mit aktiviertem Watchdog laufen.
Ethash-Optionen:
--eth_config=CONFIG Manuelle ethash-Konfiguration für den Miner. CONFIG muss die Form [X][M][L] haben.
Der Wert [M] wählt den Modus, möglich sind 'A','B' oder 'C'.
Der Modus 'B' verwendet zusätzlichen Speicher und funktioniert nur auf Karten mit 8+GB.
Der Modus 'C' verwendet zusätzlichen Speicher und funktioniert nur auf Karten mit 16+GB, etwa der VII, bei
korrekt konfiguriertem System. Weitere Details siehe ETHASH_TUNING_GUIDE.txt.
Der Wert [L] wählt die Intensität, ihr Bereich hängt von der GPU-Architektur ab.
Das Präfix [X] ist optional und nur für Navi/Big Navi, es aktiviert mehr Speicheroperationen und
führt zu einem niedrigeren Tuning-Wert [L]. Das kann sinnvoll sein, wenn der Auto-Tuner wiederholt
einen Wert nahe am maximal möglichen Tuning-Wert der GPU erreicht.
Beide Werte sind optional, wird jedoch [L] angegeben, muss auch [M] angegeben werden.
Beispielkonfigurationen: --eth_config=A
--eth_config=B750
--eth_config=XB
CONFIG kann auch eine kommagetrennte Liste von Konfigurationswerten sein, die jeweils
auf jede GPU angewendet werden. Zum Beispiel: --eth_config=A,B750,,A288
Jede GPU ohne eigene Konfiguration in der Liste verwendet die erste
Konfiguration der Liste.
--eth_variant_mode=X Dieses Argument steuert die Aktivierung der ethash-Änderungen für ETC ab Epoche 390, wie
in ecip-1099 beschrieben. Folgende Modi sind verfügbar:
pool - Standardmodus. Wird nur aktiviert, wenn der Pool ein Algo-Flag mit etchash sendet.
Sobald dieses Flag erkannt wird, gelten alle Pool-Jobs als etchash, bis ein anderes
Algo-Flag mit ethash empfangen wird.
etchash - Etchash-Modus. Epochen >= 390 gelten als etchash, niedrigere Epochen als ethash. Algo-Flags
des Pools werden nicht verwendet.
deduce - Algo-Flags des Pools ignorieren und nur eine Heuristik anhand der aktuellen Systemzeit
sowie bekannter Höhen und Zeiten für ETC und ETH anwenden. Dieser Modus sollte als allgemeiner
Ansatz funktionieren, wenn ETH im Jan. 2021 Epoche 390 erreicht. Die Systemuhr muss korrekt gehen.
Er sollte auch Profit-Switching-Setups abdecken, die über Proxys zugrunde liegender Pools frei zwischen
ethash- und etchash-Jobs wechseln.
auto - Solange der Pool kein Algo-Flag übermittelt hat, wird der Modus deduce verwendet. Sobald ein Algo-Flag
erkannt wird, wird in den Modus pool gewechselt.
ethash - Erzwungener ethash-Modus. ecip-1099 wird nie angewendet.
force_etc - Erzwungener etchash-Modus. Die Regeln von ecip-1099 werden immer angewendet. Für Mining im ETC-Testnet.
--eth_aggr_mode Aktiviert die automatische Verwendung des Modus 'B' für alle Polaris-Karten mit 8GB, sofern sie keine
andere Konfiguration über das Argument --eth_config erhalten haben. Das entspricht dem
manuellen Setzen aller Polaris-8GB-GPUs im Rig auf Modus 'B' mit --eth_config.
Bei den meisten GPUs bringt das 0.1-0.2 MH/s mehr Hashrate. HINWEIS: 20-25% der Rigs werden in diesem Modus
weniger stabil, deshalb ist er nicht der Standardmodus. Wenn bei Ihnen
GPUs ausfallen, sollten Sie dieses Argument entfernen und die GPUs im Modus 'A' betreiben.
--eth_stratum_mode=MODE Legt einen festen Stratum-Modus für ethash-Pools fest. Standardmäßig versucht der Miner,
den vom Pool unterstützten Stratum-Typ automatisch zu ermitteln und diesen Modus zu verwenden.
Diese automatische Erkennung kann mit dieser Option überschrieben werden. MODE kann
auf einen der folgenden Werte gesetzt werden: stratum, nicehash, ethproxy.
--eth_worker Legt die Worker-ID fest, die an den Pool gesendet wird. Gilt nur für Pools im Stratum-Modus
ethproxy.
--eth_hash_report=X Steuert die Hashrate-Berichte an die konfigurierten Pools. Der Wert gilt für alle Pools. Werte:
default - der Miner entscheidet anhand des für den jeweiligen Pool verwendeten Stratum-Protokolls.
force - Hashrate-Berichte immer senden, auch wenn der Pool sie ablehnt.
on - einen ersten Hashrate-Bericht senden, für jeden Pool deaktivieren, der die Nachricht ablehnt.
off - nie Hashrate-Berichte senden.
--eth_epoch Testet eine bestimmte ethash-Epoche. HINWEIS: Dadurch wechselt der Miner automatisch in den Benchmark-Modus, so
als hätten Sie --benchmark angegeben.
--eth_alloc_epoch=N Reserviert von Anfang an genug Speicher für die angegebene Epoche. Der Miner versucht, mehr zu reservieren,
falls er später beim Mining mehr braucht.
--eth_dag_buf=X,Y,... Der Miner kann einen einzelnen oder zwei Puffer für den DAG reservieren. Derzeit ist der Standard AUTO. Ein einzelner
Puffer ist etwas besser und spart bei allen GPU-Typen etwas Strom. Nur neuere Treiber unterstützen
einzelne große Reservierungen über 4GiB, typischerweise ab Adrenalin 20.9.1 und amdgpu-pro 20.x. Mit diesem Argument
kann der Miner, wenn möglich, automatisch den Einzelpuffer-Modus nutzen oder pro GPU einen bzw. zwei Puffer
erzwingen. Unterstützte Werte sind A(uto), S(ingle), D(ual). Sie können eine kommagetrennte Liste
für alle GPUs im Rig angeben oder einen einzelnen Wert für alle GPUs. Eine GPU ohne Wert in der
kommagetrennten Liste verwendet den ersten Wert.
--eth_big_mode_adjust=X,Y,... Bei den Modi B oder C läuft der Miner umso besser, je mehr VRAM er reservieren kann. Leider melden die
Treiber nicht genau, wie viel Speicher reserviert werden kann, besonders unter Windows.
Der Miner verwendet einen sicheren, konservativen Wert von 256MiB (Linux) bzw. 512MiB (Windows) als Abstand zur
verfügbaren VRAM-Größe. Wenn Sie diesen Wert ändern möchten, können Sie dies mit diesem Argument tun, indem Sie
eine kommagetrennte Liste mit Werten für eine oder mehrere GPUs angeben. Werte für GPUs, die nicht im B/C-Modus laufen, werden
ignoriert. Hat eine GPU keinen Wert in der Liste, wird stattdessen der erste angegebene Wert verwendet.
Das zulässige Intervall ist [-64, 2048]. Je höher die Zahl, desto weniger VRAM wird auf der GPU reserviert.
--eth_dag_slowdown=N Verlangsamt die DAG-Erzeugung. Geben Sie eine einzelne Ziffer 0-9 an. 0 bedeutet keine Verlangsamung (Verhalten <= 0.7.9),
1 bedeutet minimale Verlangsamung, 9 maximale. Standardwert: 4 für eine leichte Verlangsamung.
--eth_stagger Aktiviert das zeitversetzte Starten der GPUs beim Aufbau eines neuen DAG. Das schont Netzteile, die es nicht mögen,
wenn alle GPUs gleichzeitig von 0-100% Last springen.
--eth_no_stagger Deaktiviert --eth_stagger. Seit 0.7.18 bereits das Standardverhalten. Das Argument bleibt nur aus Gründen der Abwärts-
kompatibilität erhalten.
--eth_ramp_up Fährt die Intensität auf allen GPUs nach einem DAG-Aufbau, dem Deaktivieren/Aktivieren einer GPU oder einem Netzwerkausfall schrittweise hoch.
Kann Rigs helfen, die genau zwischen DAG-Aufbau und Mining-Start abstürzen.
--eth_no_ramp_up Deaktiviert --eth_ramp_up. Seit 0.7.18 bereits das Standardverhalten. Das Argument bleibt nur aus Gründen der Abwärts-
kompatibilität erhalten.
--eth_direct_abort Verwendet einen anderen Mechanismus zum Abbrechen laufender GPU-Jobs. Empfohlen für Vegas in ROCm-Umgebungen,
um veraltete (stale) Shares zu minimieren. Gilt nur für Vega- und Polaris-GPUs im Rig.
--eth_dag_alloc_patch Bei manchen Mainboards mit veraltetem BIOS können HW-Fehler auftreten, typischerweise auf der ersten oder letzten GPU im System.
Mit diesem Argument erzwingen Sie eine gepatchte DAG-Reservierungsstrategie, die das Problem meistens löst.
Oft löst auch ein BIOS-Update das Problem.
--eth_hashwatch(=M,M) Legt eine minimale/maximale Watchdog-Hashrate in MH/s fest, die beim Hashen der GPUs erwartet wird. Liegt eine GPU
zu lange außerhalb dieses Bereichs, gilt sie als fehlerhaft und der Watchdog wird ausgelöst. Die
Standardwerte für Min./Max. sind 2 MH/s und 150 MH/s. Zum Aktivieren mit Standardwerten verwenden Sie
--eth_hashwatch. Um eigene Werte zu setzen, verwenden Sie z. B. --eth_hashwatch=1.25,60. Derselbe Bereich gilt
für alle GPUs im Rig. Ein negativer Wert für eine Seite deaktiviert diese, z. B. --eth_hashwatch=-1,1000,
um GPU-Resets abzufangen, die riesige falsche Hashrates erzeugen, aber ohne Mindestprüfung.
--eth_dag_cache(=EPOCH) Aktiviert das Speichern von eth-DAGs aus Jobs mit unterschiedlichen Epochen, damit sie künftig nicht neu
aufgebaut werden müssen, wenn wieder Jobs mit den alten Epochen eingehen. Es wird höchstens ein DAG gespeichert, sofern der
GPU-Speicher ausreicht. Das ist nützlich für wechselnde Pools wie beim eth+zil-Mining. Wenn Sie eine
bestimmte Epoche direkt beim Start vorab aufbauen möchten, geben Sie den optionalen Wert an. Miner mit eth+zil-Wechsel sollten
--eth_dag_cache=0 verwenden. Derzeit können nur ethash-Epochen (nicht etchash) vorab aufgebaut werden.
--eth_dag_cache_resv=MEM Legt fest, wie viel GPU-Speicher der Miner bei aktiviertem DAG-Caching ungenutzt zu lassen versucht
(siehe --eth_dag_cache). Das Argument MEM ist die ungenutzt zu lassende Speichermenge in
Mebibyte. Der Standardwert ist 256.
--eth_dag_cache_verify Aktiviert das Lesen und Prüfen des DAG-Caches nach einem abgeschlossenen DAG-Aufbau. So werden Situationen erkannt,
in denen der DAG-Cache Bitfehler hatte und der resultierende DAG teilweise defekt ist. Wir haben beobachtet, dass dies
bei Vegas mit wachsender DAG-Größe zunehmend vorkommt. Wird dies erkannt, wird ein neuer Puffer für den
DAG-Cache reserviert und der DAG-Aufbau neu gestartet.
--eth_micro_delay=VAL,VAL,... Fügt eine Verzögerung (in Mikrosekunden) beim erneuten Einreihen von Arbeit auf der/den GPU(s) hinzu.
Schwächere Netzteile, die viele GPUs versorgen, kommen manchmal nicht mit der "Slew Rate" zurecht, wenn mehrere GPUs
genau gleichzeitig Arbeit neu einreihen. Ein Wert von z. B. 32 glättet den Übergang
von keiner Last auf 100% Last so weit, dass die Slew Rate bei solchen Rigs sinkt. Typisches Anzeichen für dieses
Problem sind harte Hänger, bei denen das Rig nicht mehr reagiert und nur ein Aus- und Einschalten hilft, es können aber auch
normale GPU-Abstürze sein. Gültige Werte sind 0-256. Werte pro GPU können als kommagetrennte Liste angegeben werden.
GPUs ohne Wert in der Liste verwenden den ersten Wert. Die Standardwerte für dieses Argument beim
reinen ethash-Mining (ein Algorithmus) sind:
Polaris: 64
Vega: 0
Navi: 0
--eth_ignore_abort_fail Schlägt der Abbruch eines Jobs fehl, liegt das meist an zu hoher Intensität, und der Miner
senkt sie daher automatisch. Diese Option _deaktiviert_ diese Logik: Die Intensität bleibt, stattdessen
wird eine Warnung protokolliert.
--eth_no_job_logs Unterdrückt alle Logs für neue Jobs vom Pool/von den Pools. Gilt für alle Mining-Sitzungen der ethash-Familie,
d. h. in einem Dual-Setup eth+zil werden die Logs für die eth- und die zil-Pools unterdrückt. Pool-Jobs, die
zu einer neuen Epoche wechseln, werden weiterhin protokolliert.
--eth_smooth_power=X,Y,... Die Scheduling-Methode "Smooth Power" wurde in 0.10.0 eingeführt und ist für alle GPU-Typen verfügbar.
Grundsätzlich ist es eine gute Funktion, die etwas Hashrate bringt und in den meisten Fällen auch die Stabilität
verbessert; sie ist standardmäßig auf allen GPUs aktiviert. Es gibt jedoch Rigs, die schlecht darauf reagieren und
abstürzen. In diesem Fall können Sie die Funktion mit diesem Argument für jede GPU in Ihrem Rig steuern.
Gültige Werte sind 0 oder 1. Bei einem Rig mit 5 GPUs könnten Sie --eth_smooth_power=0,1,1,1,0 verwenden, um Smooth
Power auf der ersten und letzten GPU zu deaktivieren. Geben Sie für eine GPU keinen Wert an, wird der erste Wert der Liste
verwendet. Sie können die Funktion also für ein ganzes Rig mit --eth_smooth_power=0 deaktivieren.
Progpow-Optionen (kawpow, firopow):
--prog_config=CONFIG Manuelle progpow-Konfiguration für den Miner. CONFIG muss die Form [M][L] haben.
Der Wert [M] wählt den Modus, möglich sind 'A' oder 'B'.
Der Modus 'B' bringt in der Regel mehr Leistung, ist aber nur für
Vega unter Linux und Navi (Linux oder Windows) verfügbar.
Der Wert [L] wählt die Intensität, ihr Bereich hängt von der GPU-Architektur ab.
Beide Werte sind optional, wird jedoch [L] angegeben, muss auch [M] angegeben werden.
Beispielkonfigurationen: --prog_config=A
--prog_config=B750
CONFIG kann auch eine kommagetrennte Liste von Konfigurationswerten sein, die jeweils
auf jede GPU angewendet werden. Zum Beispiel: --prog_config=A,B750,,A288
Jede GPU ohne eigene Konfiguration in der Liste verwendet die erste.
--prog_height=VALUE Legt für Benchmark-Zwecke eine feste Blockhöhe für progpow-Algorithmen fest. Dadurch wechselt der Miner
automatisch in den Benchmark-Modus.
--prog_strict Zwingt den Miner, immer streng exakte Kernels zu erzeugen. Standardmäßig erzeugt der Miner
gelockerte Kernels, die weniger Rechenleistung benötigen, aber gelegentlich
zu ungültigen Shares führen können.
--prog_dag_slowdown=N Verlangsamt die DAG-Erzeugung. Geben Sie eine einzelne Ziffer 0-9 an. 0 bedeutet keine Verlangsamung (Verhalten <= 0.7.9),
1 bedeutet minimale Verlangsamung, 9 maximale. Standardwert: 4 für eine leichte Verlangsamung.
--prog_stagger Siehe --eth_stagger.
--prog_ramp_up Siehe --eth_ramp_up.
--prog_no_stagger Siehe --eth_no_stagger.
--prog_no_ramp_up Siehe --eth_no_ramp_up.
--prog_micro_tune=X,Y,... Diese Option aktiviert für jeden neuen zufälligen Codeblock eine kurze Nachjustierung. Das ist wichtig,
damit Polaris-GPUs mit maximaler Geschwindigkeit laufen. Bei Vegas und Navis verbessert es die Leistung
meist nicht. Der Standardmodus AUTO aktiviert es für alle Polaris-GPUs und deaktiviert es sonst.
Der einzige Grund, es zu deaktivieren, wäre die Stabilität. Der Wert des Arguments ist eine
kommagetrennte Liste von Werten, einer pro GPU. Fehlt für eine GPU ein Wert, wird der Wert der
ersten GPU verwendet. Bitte beachten Sie, dass eine manuelle prog_config den
Micro-Tuner ebenfalls faktisch deaktiviert. Verfügbare Werte sind:
1 - progpow-Micro-Tuning für diese GPU AUSschalten.
2 - progpow-Micro-Tuning für diese GPU EINschalten.
3 - der Miner entscheidet, ob Micro-Tuning aktiviert werden soll (AUTO).
--prog_hash_report Aktiviert erzwungene Hashrate-Berichte (wie bei ethash) an alle Pools. Dies ist ein Alias für
--eth_hash_report=force, das ebenfalls gilt, da progpow und ethash dieselben Pool-
Protokolle verwenden.
Cryptonight-Optionen:
--rig_id Legt die Rig-Kennung fest, die an den Pool gesendet wird. Wird nur für
Cryptonight-Pools verwendet.
--cn_config=CONFIG Manuelle Cryptonight-Konfiguration für den Miner. CONFIG muss die Form
[P][I0][M][I1][:xyz] haben, wobei [P] ein optionales Präfix und [:xyz] ein
optionales Suffix ist. Für [P] wird nur der Wert 'L' für Low-End-
GPUs wie Lexa/Baffin unterstützt. [I0] und [I1] sind die Thread-Intensitätswerte, normalerweise
im Bereich von 1 bis 16, bei 16GB-GPUs sind aber auch größere Werte möglich. [M] ist der
Modus, möglich sind '.', -', '+' oder '*'. Modus '.' bedeutet, dass der Miner
den besten Modus wählen oder ermitteln soll. Modus '*' ist ein guter Standardmodus und
_sollte_ verwendet werden, wenn Sie auf einer Vega 56/64 mit modifizierten Speicher-Timings minen. Die
Ausnahmen von dieser Regel sind Varianten mit kleinem Pad (cnv8_trtl und cnv8_upx2), sie
sollten weiterhin '+' verwenden. Für Polaris-GPUs sind nur die Modi '-' und '+' verfügbar.
HINWEIS: In TRM 0.5.0 wurde das Auto-Tuning eingeführt, wodurch die manuelle Konfiguration
der CN-Modi außer in seltenen Sonderfällen überflüssig ist. Weitere Informationen
finden Sie in den Tuning-Dokumenten und Anleitungen, die dem Release beiliegen.
Beispielkonfigurationen: --cn_config=15*15:AAA
--cn_config=14-14
--cn_config=L4+3
CONFIG kann auch eine kommagetrennte Liste von Konfigurationswerten sein, die jeweils
auf jede GPU angewendet werden. Zum Beispiel: --cn_config=8-8,16+14:CBB,15*15,14-14
Jede GPU ohne eigene Konfiguration in der Liste verwendet die erste
Konfiguration der Liste.
--no_cpu_check Deaktiviert die CPU-Prüfung gefundener Shares, bevor sie an den Pool gesendet werden.
Hinweis: Derzeit unterstützen nur CN-Algorithmen die CPU-Prüfung.
--no_lean Deaktiviert den CN-Lean-Modus, bei dem die Threads beim Start oder Neustart nach
Netzwerkproblemen oder temperaturbedingter Drosselung der GPU langsam hochgefahren werden.
--no_interleave=DEVS Listet GPU-Geräte auf, bei denen die CN-Thread-Interleave-Logik nicht verwendet werden soll.
Das Argument ist eine kommagetrennte Liste von Geräten wie bei der Option -d.
Verwenden Sie dieses Argument, wenn einzelne Geräte eine schlechtere Hashrate haben und dazu viele
Log-Meldungen zur Interleave-Anpassung erscheinen.
--alloc_patch=DEVS Listet GPU-Geräte auf, die zwischen TRM v0.4.5 und späteren Versionen Hashrate verlieren. Mit diesem
Argument wird eine einfachere Speicherreservierungsstrategie verwendet, und die alte (höhere) Hashrate sollte
wiederhergestellt werden. Der Auto-Tuning-Modus kann weiterhin verwendet werden.
--auto_tune=MODE Aktiviert den Auto-Tuning-Modus beim Start. Nur für CN-Varianten verfügbar. MODE muss
NONE, QUICK oder SCAN sein. Der Modus QUICK prüft einige bekannte gute Konfigurationen
und ist innerhalb von 1 Min. fertig. Der Modus SCAN prüft alle möglichen Kombinationen und
läuft 20-30 Min. Mit MODE gleich NONE wird das Auto-Tuning deaktiviert. Der Standard-
modus ist QUICK.
--auto_tune_runs(=N) Führt mehrere Durchläufe des Auto-Tunings aus und verringert dabei jedes Mal die Anzahl der verwendeten Pads um -1
in einem der Threads (15+15 -> 15+14 -> 14+14 -> 14+13 -> ...). Sie können die
Anzahl der Durchläufe explizit angeben oder den Miner einen Standardwert pro GPU-Typ wählen lassen (typischerweise 3-4).
--auto_tune_exit Falls angegeben, beendet sich der Miner nach Abschluss des Auto-Tunings. Das ist hilfreich,
wenn Sie nach optimalen Einstellungen suchen und dann das resultierende Befehlszeilenargument verwenden möchten,
das der Miner ausgibt.
--allow_large_alloc Falls angegeben und wenn der Treiber meldet, dass genug GPU-VRAM verfügbar ist, geht der Miner
bei der anfänglichen Speicherreservierung aggressiver vor. In der Praxis bedeutet diese Option,
dass Vega-GPUs unter Linux das Auto-Tuning bei 16*15 statt
bei 16*14 oder 15*15 beginnen.
MTP-Optionen:
--allow_all_devices Manche Algorithmen lassen sich z. B. auf 4GB-GPUs nicht minen. Diese GPUs werden vom Miner automatisch
deaktiviert. Dieses Argument hebt diese Logik auf und erlaubt das Mining auf allen angegebenen
oder erkannten Geräten.
X16*-Optionen:
--hash_order=VALUE Legt für Benchmark-Zwecke eine feste Hash-Reihenfolge für Algorithmen wie x16r fest.
Diese Einstellung schaltet den Miner automatisch in den Benchmark-Modus.
Die Standard-Benchmark-Hash-Reihenfolge für x16r ist --hash_order=0123456789abcdef.
Nimiq-Optionen:
--nimiq_worker=VALUE Legt den Worker-/Gerätenamen für Nimiq fest, der an den Pool/die Pools übergeben wird.
--nimiq_no_proxy Deaktiviert den automatischen Nimiq-Proxy, der als separater Prozess läuft. Das bedeutet, dass
Host und Port, die dem Miner übergeben werden, auf einen Proxy zeigen müssen.
--nimiq_proxy=VALUE Überschreibt den Standardpfad zum Nimiq-Proxy. Standard ist trm_nimiq_proxy-win.exe
bzw. trm_nimiq_proxy-linux im aktuellen Miner-Verzeichnis.
--nimiq_port=VALUE Überschreibt den lokalen Standardport (4444) des Nimiq-Proxys. Das ist nützlich, wenn Ihr
System Port 4444 bereits für einen anderen TCP/IP-Dienst verwendet.
Verthash-Optionen:
--verthash_file=FILE Legt den Dateinamen zum Laden/Speichern der Verthash-Datendatei fest. Ist diese Option
bei Verwendung des Algorithmus verthash angegeben, versucht der Miner, die Verthash-Daten
aus der Datei zu laden. Existiert die Datei nicht, erzeugt der Miner die Verthash-
Daten und speichert sie für die spätere Verwendung in der Datei. Ist diese Option nicht angegeben,
erzeugt der Miner die Verthash-Daten bei jedem Start im Arbeitsspeicher.
--verthash_max_uploads=N Manche Mainboards haben Probleme, wenn alle GPUs im Rig die Verthash-Tabelle
gleichzeitig hochladen. Dieses Argument begrenzt die Anzahl der GPUs, die die Tabelle
beim Start gleichzeitig hochladen. Zulässige Werte sind 1-32. Der Standardwert ist 4.
Autolykos2-Optionen:
--autolykos_mem_adjust=N Legt die Speichermenge in MiB fest, die der Miner beim Reservieren der
GPU-Puffer für autolykos ungenutzt lassen soll. Der Standardwert ist 384 unter Linux und 512 unter Windows. Bei GPUs
mit angeschlossenen Displays erhöht sich der Standard um 512. Beim Dual-Mining mit ZIL erhöht sich der
Standardwert um 1024. Die Option kann auch als kommagetrennte
Liste von Werten angegeben werden, die jeweils auf jede GPU angewendet werden. Ist ein leerer Wert
in der Liste angegeben, wird für diese GPU der Standard verwendet. Ist für eine GPU kein Wert angegeben,
verwendet sie den ersten Wert der Liste. Der genutzte VRAM muss sowohl die Haupt-
puffer als auch einen eventuell vorab aufgebauten Puffer für die nächste Höhe aufnehmen. Zum Beispiel:
--autolykos_mem_adjust=256,512,,256
--autolykos_prebuild=N Konfiguriert die Geschwindigkeit des vorab aufgebauten Pads für die nächste Höhe. Ein höherer Wert bedeutet einen schnelleren Vorabaufbau,
aber mit stärkeren Leistungsschwankungen und vermutlich stärkerem Hashrate-Einbruch, solange der Vorabaufbau
läuft. Gültige Werte sind 0-9, wobei 0 gar keinen Vorabaufbau bedeutet und 9 die schnellste Variante ist.
Der Standardwert ist je nach GPU 3 oder 4. Sie können einen einzelnen Wert für alle
GPUs angeben oder eine kommagetrennte Liste von Werten pro GPU.
--autolykos_slowdown=N Verlangsamt den Aufbau der Pads. Gültige Werte sind 0-100. Standard ist 0, keine
Verlangsamung.
--autolykos_ignore_diff Ignoriert die vom Pool gesendete Schwierigkeit und verwendet nur das 256-Bit-Target aus den Jobs.
Manche Pools folgen nicht der Pool-Implementierung des ERGO-Referenzminers; in diesem Fall _könnte_ dieses
Argument helfen. HINWEIS: Dies gilt für alle Pools.
Optionen für ZIL-Dual-Mining:
--zil_start oder --zil Startet die Konfiguration für ZIL-Dual-Mining. Zwischen diesem und dem Marker --zil_end gelten alle Argumente
für das ZIL-Mining statt für den primären Algorithmus. Es wird erwartet, dass der primäre Algorithmus
in vorherigen Argumenten eingerichtet wurde. Die Idee ist, dass Sie eine Konfiguration --zil ... --zil_end
zu jeder funktionierenden TRM-Konfiguration hinzufügen können und alles sofort funktioniert.
Dieses Argument setzt automatisch eine Reihe von Standardeinstellungen, die Sie für ZIL brauchen:
- Zwischengespeicherte Kopie des ZIL-DAG der Epoche 0.
- Anpassung des für den primären Algorithmus reservierten Speichers, damit der ZIL-DAG passt.
- Auswahl des ethash-Modus A für das ZIL-Mining.
Das minimale funktionierende Setup besteht darin, nur einen ZIL-Pool anzugeben, der damit einverstanden ist, dass der Miner
die Jobs des primären Coins ignoriert und nur während der ZIL-Fenster mint. Hier ein Beispiel für ezil.me:
--zil -o stratum+tcp://eu.ezil.me:5555 -u <eth wallet>.<zil wallet>.<worker name> -p x --zil_end
Weitere Informationen finden Sie in der Anleitung zum ZIL-Dual-Mining, die dem TRM-Release beiliegt.
--zil_end Markiert das Ende der ZIL-Mining-Konfiguration; alle folgenden Argumente gelten für den primären
Algorithmus. Dieses Argument ist nicht unbedingt nötig, sollte aber bei Mining-Distributionen angegeben werden, da
der Benutzer keine Garantie hat, welche Argumente die Distribution automatisch ans Ende der Befehls-
zeile anhängt.
--stats_mode=single/dual Beim Hinzufügen von ZIL-Dual-Mining wird die Statistikausgabe standardmäßig verdoppelt, um Informationen zum
ZIL-Mining hinzuzufügen. Manche Umgebungen kommen damit durcheinander, wenn sie die TRM-Ausgabe oder
Log-Dateien auswerten. Um zur Standardausgabe zu wechseln, fügen Sie --stats_mode=single hinzu.
TON-Optionen:
--ton_pool_mode=X Legt den verwendeten TON-Mining-Dialekt fest. Ist er nicht gesetzt, versucht der Miner, die richtige Wahl
aus dem Hostnamen des Pools abzuleiten. Verfügbare Optionen sind:
toncoinpool - das Stratum-Protokoll über wss für toncoinpool verwenden.
icemining - das Stratum-Protokoll von ice mining über TCP/IP verwenden.
tonpool - die tonpool-Version des Stratum-Protokolls von ice mining über wss verwenden.
--wss_force_proxy Erzwingt den automatischen wss-Proxy, der als separater Prozess läuft und für TON-Pools verwendet wird, die ihr
Mining-Protokoll über wss betreiben. Der Miner aktiviert ihn normalerweise automatisch, wird aber eine reine IP-Adresse
oder ein Alias-Hostname für die Verbindung verwendet, kann dieses Argument nötig sein.
--wss_no_proxy Deaktiviert den automatischen wss-Proxy, der als separater Prozess läuft und für TON-Pools verwendet wird, die ihr
Mining-Protokoll über wss betreiben. Das bedeutet, dass Host und Port, die dem Miner übergeben werden,
auf einen Proxy zeigen müssen.
--wss_proxy=VALUE Überschreibt den Standardpfad zum wss-Proxy. Standard ist trm_nimiq_proxy-win.exe
bzw. trm_nimiq_proxy-linux im aktuellen Miner-Verzeichnis, da er ursprünglich nur für
Nimiq verwendet wurde.
--wss_port=VALUE Überschreibt den lokalen Standardport (4444) des wss-Proxys. Das ist nützlich, wenn Ihr
System Port 4444 bereits für einen anderen TCP/IP-Dienst verwendet.
Optionen für Ethash-Dual-Mining:
--ton_start oder --ton Startet die Konfiguration für TON-Dual-Mining. Zwischen diesem und dem Marker --ton_end gelten alle Argumente
für das TON-Mining statt für den primären Algorithmus, typischerweise ethash. Es wird erwartet, dass
ethash in vorherigen Argumenten eingerichtet wurde. Die Idee ist, dass Sie eine Konfiguration --ton ... --ton_end
zu jeder funktionierenden TRM-Konfiguration hinzufügen können und alles sofort funktioniert.
Das minimale funktionierende Setup besteht darin, nur einen TON-Pool anzugeben. Informationen zu unterstützten Pools
finden Sie in der Anleitung zum TON-Mining. Hier ein Beispiel für icemining mit dessen Beta-Pool-Adresse:
--ton -o stratum+tcp://ton.hashrate.to:4003 -u <ton wallet>.<worker name> -p x --ton_end
Weitere Informationen finden Sie in der Anleitung zum TON-Dual-Mining, die dem TRM-Release beiliegt.
--ton_end Markiert das Ende der TON-Mining-Konfiguration; alle folgenden Argumente gelten für den primären
Algorithmus. Dieses Argument ist nicht unbedingt nötig, sollte aber bei Mining-Distributionen angegeben werden, da
der Benutzer keine Garantie hat, welche Argumente die Distribution automatisch ans Ende der Befehls-
zeile anhängt.
--kas_start oder --kas Startet die Konfiguration für Kaspa-Dual-Mining. Zwischen diesem und dem Marker --kas_end gelten alle Argumente
für das Kaspa-Mining statt für den primären Algorithmus, typischerweise ethash. Es wird erwartet, dass
ethash in vorherigen Argumenten eingerichtet wurde. Die Idee ist, dass Sie eine Konfiguration --kas ... --kas_end
zu jeder funktionierenden TRM-Konfiguration hinzufügen können und alles sofort funktioniert.
Das minimale funktionierende Setup besteht darin, nur einen Kaspa-Pool anzugeben. Hier ein Beispiel:
--kas -o stratum+tcp://pool.woolypooly.com:3112 -u <kaspa wallet>.<worker name> -p x --kas_end
--kas_end Markiert das Ende der Kaspa-Mining-Konfiguration; alle folgenden Argumente gelten für den primären
Algorithmus. Dieses Argument ist nicht unbedingt nötig, sollte aber bei Mining-Distributionen angegeben werden, da
der Benutzer keine Garantie hat, welche Argumente die Distribution automatisch ans Ende der Befehls-
zeile anhängt.
--dual_intensity=X,Y,Z,... Dieses Argument passt die Intensität des Dual-Minings mit einem Faktor zwischen 0.0 und 1.0 an, wobei 1.0
bedeutet, so viel vom Dual-Algorithmus wie möglich laufen zu lassen. Diese Option wird empfohlen, um die Leistungsaufnahme zu senken,
ohne den Core-Takt zu reduzieren, was sich auch auf die ethash-Hashrate auswirken würde.
Das Argument wird entweder als einzelner globaler Wert oder als Liste von Werten pro GPU angegeben. Beispiele:
--dual_intensity=0.75 Alle GPUs nutzen 75% der maximal möglichen GPU-Verfügbarkeit für TON.
--dual_intensity=0.75,1.0,0.5 Separate Werte für die ersten drei GPUs im Rig, die übrigen GPUs
verwenden den ersten Wert, also 75%.
--dual_tuner_step=X Legt die Schrittweite fest, die der Dual-Tuner beim Testen verschiedener eth-Konfigurationsintensitäten verwendet. Ein niedrigerer
Wert liefert genauere Ergebnisse, dauert aber auch länger. Gültige Werte sind 1,2,4,8,16,32,64.
--dual_tuner_period=X Legt fest, wie viele Sekunden der Dual-Tuner jede getestete Konfiguration laufen lässt. Standard ist 7 Sek.
--dual_tuner_weights=X:Y:Z Der Dual-Mining-Tuner braucht Gewichtungen dafür, wie viel 1 MH/s des primären und des Dual-Algorithmus
wert ist. Im Miner sind Standardwerte hinterlegt, die zum Zeitpunkt der Implementierung jedes Algorithmus
gültig waren; da sich Netzwerk-Hashrates und Marktpreise ändern, müssen eventuell neue Werte angegeben werden.
Dieses Argument nimmt drei Werte, die alle positive Zahlen sein müssen:
X Bewertung für 1 MH/s des primären Algorithmus (typischerweise ethash).
Y Bewertung für 1 MH/s des sekundären Algorithmus (typischerweise TON oder Kaspa).
Z Kosten pro 1 W gemessener Leistung. Wir empfehlen, dies vorerst auf null zu setzen.
Beispiel für ETH+TON:
Anhand eines manuell festgelegten relativen Werts: jedes MH/s ETH ist 100 MH/s TON/Kaspa wert
--dual_tuner_weights=100:1:0
Anhand von Mining-Rechnern: $0.0437 für 1 MH/s ETH, $0.0005476 für 1 MH/s TON/Kaspa
--dual_tuner_weights=0.0437:0.0005476:0
FPGA-Optionen:
--fpga_devices=LIST Legt fest, welche FPGA-Geräte aus der erkannten Liste verwendet werden. LIST muss eine kommagetrennte Liste von
Geräteindizes oder Geräte-DNAs sein, wie sie --list_devices anzeigt.
Beispiele: -d 0,1,2,4
-d 40020000013ae32135111111,40020000013ae32135222222,40020000013ae32135333333
Ohne Angabe werden alle verfügbaren FPGA-Geräte verwendet.
--fpga_clk_core=LIST Legt die Core-Taktfrequenzen der FPGA-Geräte fest. Die Taktfrequenzen werden als
kommagetrennte Liste von Werten in Megahertz angegeben, wobei jeder Wert für je ein FPGA-Gerät gilt.
Ist die Liste kürzer als die Gesamtzahl der Geräte, verwenden die übrigen Geräte den
ersten Wert der Liste. Zum Beispiel setzt --fpga_clk_core=600,620 den Takt von
FPGA 0 auf 600MHz und von FPGA 1 auf 620MHz. Sind Geräte ab FPGA 2 vorhanden, werden sie auf 600MHz gesetzt.
--fpga_clk_mem=LIST Legt die Speichertaktfrequenzen der FPGA-Geräte fest. Das Format ist dasselbe wie bei --fpga_clk_core.
--fpga_vcc_int=LIST Legt die Spannung vcc_int auf Boards fest, die dies unterstützen. Die Spannungswerte werden als
kommagetrennte Liste von Werten in Millivolt (mV) angegeben, wobei jeder Wert für je ein Board gilt.
Ist die Liste kürzer als die Gesamtzahl der Geräte, verwenden die übrigen Geräte den
ersten Wert der Liste. Zum Beispiel setzt --fpga_vcc_int=700,800 vcc_int von
FPGA 0 auf 700mV und von FPGA 1 auf 800mV. Sind Geräte ab FPGA 2 vorhanden, werden sie auf 700mV gesetzt.
--fpga_vcc_bram=LIST Legt die Spannung vcc_bram auf Boards fest, die dies unterstützen. Das Format ist dasselbe wie bei --fpga_vcc_int.
--fpga_vcc_mem=LIST Legt die Speicher-/HBM-Spannung auf Boards fest, die dies unterstützen. Das Format ist dasselbe wie bei --fpga_vcc_int.
--fpga_update_fw Aktiviert das Update der Satellite-Controller-Firmware für C1100-Boards mit eigener TRM-Firmware,
um Funktionen wie die Spannungssteuerung zur Laufzeit zu unterstützen. Es werden nur Boards aktualisiert, die mit der Option
--fpga_devices ausgewählt sind und nicht die neueste Firmware-Version haben.
***** VORSICHT: Unterbrechen Sie den Firmware-Update-Vorgang auf keinen Fall! *****
***** Eine Unterbrechung kann das Board unbrauchbar machen, was sehr schwer zu beheben ist. *****
--fpga_allow_unsafe=LIST Deaktiviert die Standard-Sicherheitslimits für die angegebenen FPGAs. Die Geräte werden als
kommagetrennte Liste von DNA-Werten angegeben, z. B. --fpga_allow_unsafe=40020000013ae32135111111
***** VORSICHT: Der Betrieb über den Sicherheitslimits kann das Gerät DAUERHAFT BESCHÄDIGEN! *****
--fpga_tcore_limit=LIST Legt weiche Limits für die Core-Temperatur der FPGA-Geräte fest. Überschreitet die FPGA-Core-Temperatur den
angegebenen Wert, senkt der Miner die FPGA-Takte, um die Core-Temperatur unter
den angegebenen Wert zu bringen. Die Werte sind in Celsius, das Listenformat entspricht --fpga_clk_core.
--fpga_tmem_limit=LIST Legt weiche Limits für die Speichertemperatur der FPGA-Geräte fest. Beschreibung siehe --fpga_tcore_limits.
--fpga_ivccint_limit=LIST Legt weiche Stromlimits für den Spannungsregler VCCINT fest. Beschreibung siehe --fpga_tcore_limits.
--fpga_ivccbram_limit=LIST Legt weiche Stromlimits für den Spannungsregler VCCBRAM fest. Beschreibung siehe --fpga_tcore_limits.
--fpga_max_jtag_mhz=XY.Z Legt die maximal zulässige Frequenz für die JTAG-Kommunikation des FPGA fest. Standard ist 30.0 MHz.
--fpga_eth_clk_dag=LIST Legt die FPGA-Core-Taktfrequenzen fest, die beim Aufbau des Ethash-DAG verwendet werden. Standardmäßig werden sie
auf 90% des regulären Core-Takts gesetzt. Das Format ist dasselbe wie bei --fpga_clk_core.
