Latest release of cgminer-gekko v4.12.1 Mining Software branch

Together with the release of the GekkoScience R909 Pod Miner miner, Kano has released a new version of the CGMiner GekkoScience Mining Software branch. Here I will explain the main innovations and describe installation, build and configuration for Linux, Windows and Mac.

CGMiner Gekkoscience Branch Git Repository

The original Git repo (master) of Kano can be found here:  https://github.com/kanoi/cgminer . This repository is a fork of the original CGMiner repository by Kon Colivas and can be clearly identified on Github as follows:

Caution

ATTENTION: There are also a few illegitimate copies of this repository on Github that are not correctly marked as a fork, contain dubious changes/extensions and also offer precompiled binaries for Windows. I can only strongly advise against using any repository other than the one we have officially released for obtaining sources and binaries.

Here’s an example:

For example, this repository owner has removed all references to the origin of the source code, added security-critical modules (extranonce) and added code that contains, for example, the solo mining bug, which can potentially send a block reward to a random address. A number of altcoin code changes have also been made, the purpose of which is unknown. The Windows executables offered for download are not identical to the originals (checked via the hash) and may contain – who knows what – changes to the functionality.

Running the 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

In the examples above, please replace both the pool data and username.workername with your own pool data if necessary.

Frequency settings

Default frequency settings for Compac F and R909, Autodetect and Autotune

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

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

If no command line parameters are specified at runtime, the above settings are used as default.

For both miners, CGMiner now starts by default with the Autotune parameter, the parameter

--gekko-mine2

is no longer needs to be added explicitly.

If both Compac F and R909 are operated on a CGMiner instance, the frequency settings can be specified as follows:

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

If the CGMiner instance is to be restricted exclusively for the operation of Compac F or R909 miners, this can be set with the following parameters:

--gekko-compacf-detect

--gekko-r909-detect

It is also possible to specify both parameters. Future miners will also receive detect parameters. This allows the user to decide for which GekkoScience Miner the CGMiner instance should be used. If no parameter is specified, CGMiner automatically scans for all existing GekkoScience miners (including older models).

The previous tuning functionality

--gekko-tune2 60

is still available. This option forces the miner to return to the originally specified starting frequency after the specified time interval. With some miners (series distribution of ASICs!) this leads to the miners clocking up and automatically clocking down again at intervals. the value range (for minutes) is: 30-9999

Tuning options via the API

In future, all of the new tuning options will be available via the API, allowing complex, sensor data-dependent controls, e.g. of home automation or PV systems, to be implemented, which do not have to run on the same controller on which the CGMiner instance is running.

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

Enabling the API:

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

The specified IP addresses receive access to the CGMiner API. 127.0.0.1 is the so-called localhost or loopback address and points to the controller on which the CGMiner instance is also running.

The API requires a Java installation on the computer you use to access the API. The build instructions below also contain a dependency on Java if you only use one controller for the CGMiner instance and the tuning configuration.

To view the settings and miner configuration, use the following command:

java API estats {Miner-IP}

for example:

java API estats 192.168.0.12

If you are accessing the API from localhost, you can omit the IP address in the call:

java API estats

Example output:

[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

Further details about the CGMiner RPC API and further examples of how to access the API:

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

Override the default wait factor

The wait factor (the frequency with which the CGMiner sends work packages to the miner can be adjusted

--gekko-wait-factor 0.5

The result can be read in the API output in average duration of a job in milliseconds:

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

The value range is set from 0.5 to 2. Default value is 0.5. The higher the value is set, the less often the controller sends work packages to the miner. Values that are too high cause overflows in the serial communication with the ASICs. The lower the value, the more CPU load there is on the controller. In some cases, lower values (0.4 or 0.3 instead of the default value) allow higher hashrates for a given clock speed because hashes are processed more frequently by the miner.

If your hash rate is too low compared to the set clock speed and your computer still has available CPU reserves, decreasing the wait factor can help increase the hash rate, but will also use more CPU on the controller.

Frequency settings via the API

With version 4.12.1, many new frequency setting options are available for individual or all ASICs of a miner. Since the ASICs used usually have a high series spread, the individual frequency optimum of each ASIC can be determined and set.

Setting a uniform clock frequency (400 in the example) for all ASICs of a miner via the API:

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

If you change the frequency and the frequencies of each ASIC are not locked, AutoTune mode will activate and attempt to adjust the frequency to find the optimum automatically.

As a special case, you can also set the frequency to zero. This effectively stops mining and reduces power consumption to the minimum. This option is particularly suitable for hysteresis control when the available power fluctuates (e.g. PV systems)

You can also see the current chip frequencies in the API output:

[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” is the chip’s response after sending it the “send” frequency. You will always see details of this on the screen when frequency changes occur.

Locking frequencies (overriding AutoTune mode)

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

This API call blocks all currently set frequencies for the selected miner. CGMiner will no longer change the currently set frequency unless the ASICs stop responding (zombie), in which case AutoTune will be activated again.

If all of a miner’s ASICs no longer respond, the lock is lifted, a reset is carried out and continued in standard mode without frequency lock.

The frequency lock will be lifted using the following API call:

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

If you operate more than one miner on your CGMiner instance, you must specify the ASIC number of the miner for which you want to set the frequency settings.

This is the [STATS] number in the output of the ‘estats’ command.

[STATS] => 0

Note: The [ID] number is not the API ASIC number, although it is often the same.

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

Reset the miner when the hashrate falls below a specified value

There is an API-adjustable command that resets and restarts the miner if the hashrate falls below a specified hashrate. By default, the miner is reset when the current hashrate falls below 65% of the expected hashrate. In this case, the miner is reset and the frequency is adjusted downwards.

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

Note: Each individual miner can be addressed with this command via the [ID] number.

Setting the same frequency on all chips (e.g. 400 MHz)

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

Of course, if you change the frequency and the frequencies are not locked, the plateau code comes into effect and tries to automatically adjust the frequency towards the miner optimum.

Setting a specific frequency for a specified ASIC (e.g. 410 MHz on ASIC 0)

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

Our experience with the BM1397 ASIC: If you set a chip frequency to zero, all chips appear to go to zero automatically. Our assumption is that the frequency range of each ASICS in a string cannot be set very far apart for all ASICS to work properly. Try it. To test individual ASICs you can set one chip 100 MHz below the clock speed of the others, this has worked well for testing individual ASICs.

Changing the amount of time cgminer/USB waits to send data packets to the miner.

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

You can change the amount of time cgminer/USB waits to send the next USB data packets to the miner. The adjustable range is 200 to 1000 µs. The default value is 1000 µs.

This can be useful on a computer that can perform USB I/O faster and has many miners connected. If the value is chosen too small, problems can arise in that the work packages do not fully reach the miner in the (too) small time window and the nonces do not always return in full. The error rate increases in this case. This setting is only compatible with the BM1397 refills R909 and CompacF. If the value is adjusted downwards, the CPU utilization of the controller increases.

Reset of the Miner

java API "ascset|0,reset" minerIP

This API command causes a reset of the miner addressed via the respective ID and a reset to standard settings in conjunction with the plateau code to automatically determine the mining optimum.