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 crtAlthough --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.
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.