rieMiner - Solo + pooled Riecoin mining

[Rockhawk]

I've submitted another pull request. This fixes a small bug in the previous PR, which was very slightly reducing performance.

In addition, I've added full support in the mining code for tuples other than the standard riecoin tuple, providing the offset between each prime in the tuple is <= 6. I was able to do this with no significant performance impact. I've successfully tested with an 8-tuple configuration.

[Rockhawk]

I've been thinking about the throughput/fully utilising the CPU issue - one place where there's a sync point across all threads is when it finishes processing a block and has to get a new one. Obviously if the block height has changed you have to clear everything and start again, but if it hasn't it would be possible (from the miner code point of view) to start sieving for a new block while the prime tests for the old one were still running.

So, how possible would it be to request a new block while the old one is still running? Do the client protocols allow you to have mutliple blocks outstanding at once, or would that require having 2 client connections?

If this can be made to work, I'm thinking we'd change the miner API so process() never exited, and instead of being passed a WorkData it would call the manager to get a WorkData when it needed a new one or when the height changed.

[Pttn]

Merged, thanks. I did not notice any performance gain or loss that cannot be caused by statistical error, code looks Ok. I hope that the best still has to come. It is also possible to set the Constellation Type directly in the rieMiner.conf (read the ReadMe for how).

The clients implementation stores only one block (work) at any time, which is regularly updated after a certain short amount of time (customizable by the _workRefresh attribute), to ensure that newer transactions are included. When the manager asks the client to get its work, the client randomizes it a bit before sending it to prevent having 2 threads working on the same problem and producing duplicate tuples.

There should not be any issue to call directly from the miner.cpp's process() the manager to get the new work. Then you need to find a way to make the miner threads know when they need to get new work.

[Rockhawk]

Great, thank you for adding that configuration.

OK, understood on how the client work refresh works - it sounds like what I had in mind should be fine, I'll look at making that change in future.

[czakris]

Tried to set sieve value to 17179869184 and got "File: miner.cpp, Line 138" overflow error message, so I will test it with 2^32. Thank You Guys for all your hard work.

[Rockhawk]

I've submitted a PR bringing across my work adding precomputation to reduce the time spent calculating remainders. This gives a speed up of a few % (more the higher you sieve), although as the remainder calculations all need to be done before prime testing can start for each block, the effect on mining should be slightly greater (because when mining some blocks are interrupted).

This does use more memory (a little more than twice as much as before), so I've added a MaxMemory configuration parameter to help control usage. This will reduce the amount of precomputed data, or even reduce the number of primes sieved if you request a sieve limit that's too high for the MaxMemory setting.

I've also fixed the code so the sieve limit can go over 2^32 again.

Next up will be the throughput improvements, probably at the weekend.

[Pttn]

I got a ~5% improvement during mining, good job. Though, in the Benchmark Mode, I did not really notice any difference.

Merged, thanks. I will bump the version to bêta 3 and make a post in BitcoinTalk Sunday.

[Pttn]

Wow, I found more than 10 blocks in less than 24 hours! 5% of the latest 100 blocks!
This is more pure luck than related from the recent improvements, but still.
Solo mining is worth it, I encourage every current pool miner to try Solo Mining! It is fun!

I still have yet to find a Superblock though...

[Rockhawk]

Record for the quickest finding a block after the miner starts? I was just doing some testing and:

[0000:00:00] Started mining at block 984921 difficulty 1414
[0000:00:30] (1-3t/s) = (111.8 3.88 0.131) ; (2-6t) = (118 4 0 0 0)
Block timing: 10396219, 24270330, 253198398
[0000:01:00] (1-3t/s) = (113.1 4.42 0.132) ; (2-6t) = (267 8 0 0 0)
Block timing: 10053809, 23123397, 256614267
[0000:01:30] (1-3t/s) = (115.3 4.33 0.133) ; (2-6t) = (392 12 0 0 0)
[0000:01:33] 6-tuple found, this is a block!

I'm looking at throughput this weekend. Will hopefully be able to eliminate the idle time when changing work data when there's no difficulty change. I don't think I'll be able to completely eliminate the idle time shortly after a new block starts - the sieve needs to run for a bit to generate enough candidates to fill up the verification threads, I'll see what I can do though!

[Rockhawk]

I've made significant improvements to the throughput of the sieve, in order to keep a larger number of verifying threads busy.

Highlights:
- Sieving on the next block can now start immediately after sieving on the previous block has finished
- Within a block, sieving the next segment is overlapped with scanning the results from the previous segment, by switching back and forth between a pair of sieve arrays
- Remainder computation above the sieve limit is overlapped wit hthe first sieving job each block.
Plus numerous minor improvements.

My testing on a c5.4xlarge AWS instance suggests this should now be able to saturate 16 threads at 1600 difficulty, and just has small idle spikes when the block changes over at 1400 difficulty.

I've submitted a pull request - let me know how it works for you!

If it works well, I'd appreciate a donation to RVSDWEaxH3gjEqgYVAvdaNunVq7zzDivwH :)