The speed of mining * with higher shifts* (64 and above) can be improved by using the Chinese Reminder Theorem (CRT). The higher the shift (up to 1024), the better the improvement from using the CRT - but with higher shifts the mining speed also decreases. However, if you are aiming for shifts 64 and above anyway, then using the CRT will make a positive difference.

Get-you-started crt mining params: shift 64, 4 threads (1@gap scanning, 3@fermat sieving), sieve-primes of 13000.

gapminer localhost -p 31397 -u <user> -x <password> -t 4 -d 3 -f 64 -i 13000 -r crt-22m-64s.txt

When using GapMiner with the Chinese Remainder Theorem for mining, in addition to the standard GapMiner parameters `--threads`, `--sieve-primes` and `--sieve-size`, there are two additional mining parameters that must be set appropriately: `--crt` and `--fermat-threads`.

-r --crt use the given Chinese Remainder Theorem file
-d --fermat-threads number of fermat threads when using the crt

Although `--sieve-size` remains settable, it is **not used** when mining with the Chinese Remainder Theorem.

`-r --crt`

use the given Chinese Remainder Theorem file

Using GapMiner with the Chinese Remainder Theorem requires the choice of a CRT file, containing search values optimized for a specific shift, starting at 64 (i.e. searching primes of 97 digits in length).

As originally distributed, crt files for the following shifts were made available in the GapMiner repository: 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, 512, 544, 576, 608, 640, 672, 704, 736, 768, 800, 832, 864, 896, 928, 992, 1024.

The shift setting doesn‘t **have** to match the crt shift, you can mine with `--shift 510` using the crt file `crt-22m-512s.txt`

.

`-d --fermat-threads`

number of fermat threads when using the crt

Mining with the CRT is split into sieve and primality testing, using separate threads for each:

--threads 4 --fermat-threads 1

The above example is parsed by the Gapcoin miner as: use 3 threads for sieving and 1 thread for gap scanning.

Using GapMiner with CRT requires at least **two** threads.

The scan threads always pick the most promising gap from the gaplist (the gaplist is implemented as an heap), therefore **the gaplist value should always be at least over 100**. Altering the gaplist size can be achieved by altering `--sieve-primes`, `--threads` or `--fermat-threads`.

Having a gaplist with too high a value (e.g. over 9000) can slow down mining.

- set
`--fermat-threads = --threads`minus 3 for shifts*below*128. - set
`--fermat-threads = --threads`minus*2*for shifts*above*128. - set
`--sieve-primes`for optimal block% (probably close or below).

If you want more `--fermat-threads` then the value of `--sieve-primes` needs to be reduced and vice versa.

Fine-tune the sieve-primes value by only adjusting 1000 at a time then running for a minute to observe. The ideal behavior is for the gaplist size generally (most of the time) to stay above 100. It'll creep up to a 2000-3000 then drop back down to 100 and will continue in this see-saw fashion.

There are 2 new verbose outputs:

gaplist: The number of sieved gaps ready for scanning block: The percent of the calculation amount of an average block

When mining with the CRT, the primes/sec and block values are **estimated** using the theoretical speed improvements from CRT so may not be accurate.

Mining with the CRT is optimized for solo mining. Pool miniing with CRT is possible but will probably result in fewer shares (the primes/sec and block values are probably inaccurate) but the chance of finding a block is almost the same as when mining solo.

Copyright © 2021, Gapcoin Project.