Quote from: samsmith16 on March 24, 2016, 11:30:21 PM

Quote from: Rodderick on March 24, 2016, 08:39:29 PM

Quote from: pallas on March 24, 2016, 05:43:18 PM

Quote from: Jayjay04 on March 24, 2016, 05:21:30 PM

Is there a way I could adjust the number of mining threads ?

Threads = minermemory * genproclimit

I suggest leaving minermemory to the default which is 1.
Then with genproclimit you can set the number of threads.

I have an i7 CPU. Changing genproclimit to 6 does change the number of threads reported by my wallet when mining to 6, but the wallet still utilizes 100% of the CPU most of the time but drops off to 25% briefly every few seconds. Is there a setting that would give me a steady 75% CPU utilization instead of the peaks and valleys?

The mining thread count needs to be a power of 2 (2,4,8,16...) or it will round up to the closest one.. So if you have 8 CPU threads and you mined at 50% you need to do 1/4 (ram/threads) or 2/2 but like stated above 1/4 would work the best.. Sam goes if you have 4 CPU threads 1/2 would be 50%.. Like stated a few time before.. Terms to know

CPU cores: the number of physical cores on your CPU
CPU threads: the number of threads your CPU has, so if your CPU is hyper threaded then this is (core count x 2)
Mining threads: number used in "genproclimit"
Total mining threads: genproclimit x minermemory (threads x ram)
Mining instances: each 1gb of ram used ( number used in "minermemory")
Mining cycle: 1000 searched

On most rigs you can get a total mining threads a little higher the CPU threads.. This needs to be test to find optimal for your system.. Let's take one of my rigs for example.. It has 48 CPU threads I have it set at 7/8 which is 56 total mining threads.. This is bc there is a slight delay right after the mining cycle and each instance cycles at different times.. So this leaves just a little room for the extra mining threads..

I guess we could call it a round or a cycle I simply went with cycle

Quote from: pallas on March 25, 2016, 10:40:56 AM

"Mining cycle: 1000 searched"

not sure what that exactly means but there is just 1 cycle of 1 interaction in the miner, which in turn is made of 256K steps (1GB / 4K).

Maybe I should say ~1000 collisions I just was't sure ppl would understand what a collision meant..

Quote from: FreeTrade on February 03, 2016, 04:26:24 AM

To calculate your hashrate:

Have a look at your debug.log file - find some lines like this . . . .

2016-02-03 04:17:29 HOdlcoinMiner:
2016-02-03 04:17:29 search finished - best hash
hash: 000f00a8eb9fde09dcfb398de5418c7fbbcbeb4d782dfbff396cf282c339e2dd collisions:1039 gethash:000f00a8eb9fde09dcfb398de5418c7fbbcbeb4d782dfbff396cf282c339e2dd ba:31773 bb:766922187 nonce:8861
target: 00000760a6000000000000000000000000000000000000000000000000000000
2016-02-03 04:17:36 HOdlcoinMiner:
2016-02-03 04:17:36 search finished - best hash
hash: 001d781dccb23ed017c6b805ac596f190124c4754b60ae091cd6621563bc64d2 collisions:989 gethash:001d781dccb23ed017c6b805ac596f190124c4754b60ae091cd6621563bc64d2 ba:253952 bb:2993905001 nonce:9325
target: 00000760a6000000000000000000000000000000000000000000000000000000

You'll see in this example that the searches are about 7 seconds apart . . . each completed search counts as approximately 1000 hashes (collisions) . . . so here there are 1000 per 7 seconds . . a rate of about 143 hash/sec. This is an i7 4770 and the overall network rate at the moment is 8417 hash/sec . . so the whole network is about as strong as 60 i7 4770's . . . . and if you're mining with an i7 4770, you would expect 1 in every 60 blocks. That's about 1 every 3 hours.

each completed search counts as approximately 1000 hashes (collisions)

Quote from: samsmith16 on February 09, 2016, 02:28:53 PM

each instance (1gb of ram) finishes it's cycle (~1000 collisions) at different times..

If we look at the image.. instance 1 finished it's search cycle which had 1006 collisions at 14:15:36.. it then moved on to it's next cycle.. then you see that instance 2 finished it's search cycle which had 1029 collisions at 14:15:42