Neues release der cgminer-gekko v4.12.1 Mining Software

Anlässlich der Auslieferung des GekkoScience R909 Pod Miner miner hat Kano eine neue Version des GekkoScience Branch der Mining Software CGMiner veröffentlicht. Ich erkläre Euch hier die wesentlichen Neuerungen und beschreibe Installation, Build und Konfiguration für Linux, Windows und Mac.

CGMiner Gekkoscience Branch Git Repository

Das Original Git Repo (den Master) von Kano findet ihr hier:  https://github.com/kanoi/cgminer . Dieses Repository ist ein Fork des Original CGMiner Repository von Kon Colivas und ist auf Github folgendermaßen eindeutig zu identifizieren:

Warnung

ACHTUNG: Es sind auch ein paar nicht gekennzeichnete Kopien dieses Repositories auf Github zu finden, die nicht korrekt als Fork gekennzeichnet sind, dubiose Änderungen/Erweiterungen enthalten und auch vorkompilierte Binaries für Windows anbieten. Ich kann nur nachdrücklich davon abraten, andere als das offiziell von uns freigegebene Repository für den Bezug von Sourcen und Binaries zu nutzen.

Hier ein Beispiel:

Dieser Repository Eigentümer hat zum Beispiel alle Referenzen zur Herkunft des Source Code entfernt, sicherheitskritische Module (extranonce) ergänzt und beinhaltet Code, der zum Beispiel den Solo-Mining-Fehler enthält, der einen Block Reward ggf. an eine zufällige Adresse senden kann. Es wurden auch eine Reihe von Altcoin-Codeänderungen vorgenommen, deren Zweck unbekannt ist. Die darin zum Download angebotenen Windows-Executables sind (über den Hash geprüft) nicht identisch mit mit den Originalen und können – wer weiß was für – Änderungen an der Funktionalität enthalten.

Ausführen des CGMiner

./cgminer -o stratum+tcp://stratum.kano.is:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 442

./cgminer -c gekko.conf

cgminer.exe -o stratum+tcp://stratum.kano.is:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 442

cgminer.exe -c gekko.conf

cgminer -o stratum+tcp://stratum.kano.is:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 442

cgminer -c gekko.conf

Bitte tausche in oben genannten Beispielen sowohl die Pool-Daten als auch Benutzername.Workername ggf. gegen eigene Pooldaten aus.

Frequenzeinstellungen

Standard-Frequenzeinstellungen für Compac F und R909, Autodetect und Autotune

--gekko-start-freq 200 --gekko-compacf-freq 200

--gekko-start-freq 400 --gekko-r909-freq 450

Werden keine Kommandozeilenparameter zur Laufzeit angegeben, werden die oben genannten Einstellungen als Standard verwendet.

Für beiden Miner startet CGMiner nun in standardmäßig mit dem Autotune Parameter, der Parameter

--gekko-mine2

muss also nicht mehr explizit angefügt werden.

Werden an einer CGMiner Instanz sowohl Compac F als auch R909 betrieben, können die Frequenzeinstellungen wie folgt angegeben werden:

--gekko-r909-freq 450 --gekko-compacf-freq 400

Soll die CGMiner Instanz ausschließlich für den Betrieb von Compac F oder von R909 Minern eingeschränkt werden, kann das mit folgenden Parameteren eingestellt werden:

--gekko-compacf-detect

--gekko-r909-detect

Es ist auch die Angabe beider Parameter möglich. Zukünftige Miner werden ebenfalls Detect-Parameter erhalten. So kann der Anwender entscheiden, für welche GekkoScience Miner die CGMiner Instanz verwendet werden soll. Wird kein Parameter angegeben, scannt CGMiner automatisch nach allen vorhandenen GekkoScience Minern (auch ältere Modelle).

Die bisherige Tuning-Funktionalität

--gekko-tune2 60

ist weiterhin verfügbar. Diese Option zwingt den Miner, nach dem angegebenen Zeitintervall die ursprünglich angegebene Startfrequenz wieder zu erreichen. Bei manchen Minern (Serienstreuung der ASICs!) führt das dazu, dass die Miner im Zeitintervall hoch- und automatisch wieder heruntertakten. der Wertebereich (für Minuten) ist: 30-9999

Tuning Optionen über die API

Die gesamten neue Tuning-Möglichkeiten stehen zukünftig über die API zur Verfügung, damit lassen sich komplexe, Sensordaten-abhängige Steuerungen z.B. von Hausautomatisierungen oder PV Anlagen realisieren, die nicht auf dem gleichen Controller laufen müssen, auf dem auch die CGMiner Instanz läuft.

Es empfiehlt sie dabei die Tuning-Parameter in eine Konfigurationsdatei auszulagern (siehe weiter unten in diesem Artikel)

Aktivieren der API:

--api-listen --api-allow "W:192.168.1.0/24,W:127.0.0.1"

Die angegebenen IP Adressen erhalten Zugriff auf die CGMiner API. 127.0.0.1 ist dabei die sogenannte localhost oder loopback Adresse und zeigt auf den Controller, auf dem auch die CGMiner Instanz läuft.

Für die API wird eine Java Installation auf dem Computer benötigt, mit dem Sie auf die API zugreifen. Die weiter unten folgenden Build-Anweisungen enthalten auch eine Dependency zu Java, falls Sie nur einen Controller für die CGMiner-Instanz und die Tuning-Konfiguration verwenden.

Um die Einstellungen und die Miner-Konfiguration anzuzeigen, verwenden Sie folgendes Kommando:

java API estats {Miner-IP}

zum Beispiel:

java API estats 192.168.0.12

Sollten Sie von localhost auf die API zugreifen, können Sie die IP-Adresse im Aufruf weglassen:

java API estats

Beispielausgabe:

[STATS] => 0
[Serial] => GS-10008000
[WaitFactor0] => 0.500000
[WaitFactor] => 2.000000
[JobDataAge] => 0.001697
[Jobs] => 10081/12972/12980/12972/12980
[JobElapsed] => 46.61/59.99/60.00/59.99/60.00
[JobsPerSec] => 216.28/216.20/216.33/216.21/216.32
[JobsAvgms] => 4.62/4.63/4.62/4.63/4.62
[JobsMinMaxms] => 0.52:5.12/0.30:4.99/0.28:4.91/0.84:5.77/0.53:5.06

Weitere Details zur CGMiner RPC API und weitere Beispiele, wie auf die API zugegriffen werden kann:

https://github.com/kanoi/cgminer/blob/master/API-README#L485

Überschreiben des Standard Wait Factor

Der Wait Factor (die Häufigkeit, mit der vom CGMiner Arbeitspakete an den Miner gesendet werden kann angepasst werden

--gekko-wait-factor 0.5

Das Ergebnis kann in durchschnittlichen Dauer eines Jobs in Milisekunden in der API Ausgabe abgelesen werden:

[JobsAvgms] => 4.62/4.63/4.62/4.63/4.62

Der Wertebereich ist von 0.5 bis 2 festgelegt. Standardwert ist 0.5. Je höher der Wert gesetzt wird, umso weniger oft sendet der Controller Arbeitspakete an den Miner. Zu hohe Werte provozieren Überläufe in der seriellen Kommunikation mit den ASICs. Je niedriger der Wert, desto mehr CPU Last entsteht auf dem Controller. In manchen Fällen lassen sich mit niedrigeren Werten (0.4 oder 0.3 statt dem Standardwert) höhere Hashraten bei gegebener Taktrate ermöglichen, weil Hashes vom Miner häufiger verarbeitet werden.

Wenn Ihre Hash-Rate für die eingestellte Taktrate im Vergleich zu niedrig ist und Ihr Computer noch über verfügbare CPU Reserven verfügt, kann ein Verringern des Wait Factor dabei helfen, die Hash-Rate zu erhöhen, verbraucht aber auch mehr CPU auf dem Controller.

Frequenz-Einstellungen über die API

Mit der der Version 4.12.1 stehen viele neue Frequenz-Einstellungsmöglichkeiten für einzelne oder alles ASICs eines Miners zur Verfügung. Da die verwendeten ASICs meist eine hohe Serienstreuung verfügen, kann so das individuelle Frequenz-Optimum eines jeden ASICs ermittelt und eingestellt werden.

Setzen einer einheitlichen Taktfrequenz (im Beispiel 400) für alle ASICs eines Miners über die API:

   java API "ascset|0,freq,400" {Miner-IP}

Wenn Sie die Frequenz ändern und die Frequenzen der einzelnen ASICs nicht gesperrt sind, wird der AutoTune Modus aktiv und versucht, die Frequenz anzupassen, um das Optimum automatisch zu finden.

Als Sonderfall können Sie die Frequenz auch auf Null setzen.
Dies stoppt effektiv das Mining und senkt die Leistungsaufnahme auf das Minimum. Diese Option eignet sich besonders für die Hysteresesteuerung bei schwankender verfügbarer Leistung (z.B. PV Anlagen)

Sie sehen die aktuellen Chipfrequenzen auch in der API-Ausgabe:

[Chip0FreqSend] => 500.000000
[Chip0FreqReply] => 500.000000
[Chip1FreqSend] => 500.000000
[Chip1FreqReply] => 500.000000
[Chip2FreqSend] => 500.000000
[Chip2FreqReply] => 500.000000
[Chip3FreqSend] => 500.000000
[Chip3FreqReply] => 500.000000
[Chip4FreqSend] => 500.000000
[Chip4FreqReply] => 500.000000
[Chip5FreqSend] => 500.000000
[Chip5FreqReply] => 500.000000

“Reply“ ist die Antwort des Chips, nachdem ihm die „Sende“-Frequenz gesendet wurde. Sie sehen immer Details dazu auf dem Bildschirm, wenn Frequenzänderungen auftreten.

Sperren von Frequenzen (überschreiben des AutoTune Modus)

java API "ascset|0,lockfreq" {Miner-IP}

Dieser API Aufruf sperrt alle aktuell gesetzten Frequenzen für den ausgewählten Miner. CGMiner wird die aktuell gesetzte Frequenz nicht mehr ändern, es sei denn, die ASICs reagieren nicht mehr (Zombie), in dem Fall wird wieder AutoTune aktiviert.

Sollten alle ASICs eines Miners nicht mehr reagieren, wird die Sperre aufgehoben, ein Reset durchgeführt und im Standardmodus ohne Frequenzsperre, fortgesetzt.

Die Frequenz-Sperre wird über folgenden API Aufruf wieder aufgehoben werden:

java API "ascset|0,unlockfreq" {Miner-IP}

Wenn Sie mehr als einen Miner an Ihrer CGMiner Instanz betreiben, müssen Sie die ASIC-Nummer des Miners mit angeben, für den Sie die Frequenzeinstellungen setzen möchten.

Dies ist die [STATS]-Nummer in der Ausgabe des Befehls ‘estats’.

[STATS] => 0

Hinweis: Die [ID]-Nummer ist nicht die API-Asic-Nummer, obwohl sie oft gleich ist.

 java API "ascset|0,lockfreq" {Miner-IP}

Reset des Miners beim Unterschreiten einer festgelegten Hashrate

Es gibt eine API-einstellbaren Befehl, der den Miner beim dauerhaften Unterschreiten einer festgelegten Hashrate zurücksetzt und neu startet. In der Standardeinstellung wird der Miner zurückgesetzt, wenn die aktuelle Hashrate 65 % der erwarteten Hash-Rate unterschritten wird. In diesem Fall wird der Miner zurückgesetzt und die Frequenz nach unten angepasst.

java API "ascset|0,require,0.65" {Miner-IP}

Hinweis: Über die [ID]-Nummer kann jeder einzelne Miner mit diesem Befehl angesprochen werden.

Setzen der gleichen Frequenz auf allen Chips (z.B. 400 MHz)

java API "ascset|0,freq,400" {Miner-IP}

Wenn Sie die Frequenz ändern und die Frequenzen nicht gesperrt sind, tritt natürlich der Plateau-Code in Kraft und versucht, die Frequenz in Richtung des Miner-Optimums automatisch anzupassen.

Setzen einer bestimmten Frequenz für einen festgelegten ASIC (z.B. 410 MHz auf ASIC 0)

java API "ascset|0,chip,0:410" {Miner-IP}

Unsere Erfahrung mit dem BM1397 ASIC: Wenn Sie eine Chipfrequenz auf Null setzen, scheinen alle Chips automatisch auf Null zu gehen.
Unsere Annahme ist, dass der Frequenzbereich der einzelnen ASICS in einem String nicht sehr weit auseinander eingestellt werden kann, damit alle ASICS ordnungsgemäß arbeiten. Probieren Sie es aus. Zum Testen einzelner ASICs können Sie einen Chip 100 MHz unter die Taktfrequenz der anderen einstellen, das hat sich für das Testen einzelner ASICs gut bewährt.

Ändern der Zeitspanne, die cgminer/USB wartet, um Datenpakete an den Miner zu senden.

java API "ascset|0,usbprop,800" {Miner-IP}

Sie können die Zeitspanne ändern, die cgminer/USB wartet, um die nächsten USB-Datenpakete an den Miner zu senden.
Der einstellbare Bereich ist 200 bis 1000 µs. Der Standardwert ist 1000 µs.

Dies kann auf einem Computer nützlich sein, der die USB Ein-/Ausgabe schneller ausführen kann und an dem viele Miner angeschlossen sind.
Wird der Wert zu klein gewählt, können Probleme dabei entstehen, dass die Arbeitspakete im dem (zu) kleinen Zeitfenster nicht vollständig zum Miner gelangen und die Nonces nicht immer vollständig zurückkommen. Die Fehlerrate steigt in diesem Fall.
Diese Einstellung ist nur mit den BM1397 Minen R909 und CompacF kompatibel. Wird der Wert nach unten angepasst, erhöht sich dadurch die CPU-Auslastung des Controllers.

Reset des Miners

java API "ascset|0,reset" minerIP

Dieses API Kommando bewirkt einen Reset des über die jeweilige ID angesprochenen Miners und das Zurücksetzen auf Standardeinstellungen in Verbindung mit dem Plateau-Code zur automatischen Ermittlung des Mining-Optimums.