Author

Topic: [ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay] - page 1234. (Read 2375926 times)

legendary
Activity: 882
Merit: 1000

also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....

That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes.

the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option

I'll need you all keep me posted your suspections in the next 1-2 days.

i will when i get the chance to monitor it, down to 36,000khs now........ sudden drops

then back to 49,000.....

now at 57,000 again.....
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!

also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....

That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes.

the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option

I'll need you all keep me posted your suspections in the next 1-2 days.
legendary
Activity: 882
Merit: 1000

also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....

That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes.

the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!

also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....

That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes.
legendary
Activity: 882
Merit: 1000
from where comes 100MH/s!

Maybe from claymore's GPU miner! Grin

very possible. given that his miner's generally only work on p2p based pools that way he can get his 5% cut, so he is connecting solo or testing a pool version... its a possibilty considering he mentioned that he was already working on it
newbie
Activity: 39
Merit: 0
from where comes 100MH/s!

Maybe from claymore's GPU miner! Grin
legendary
Activity: 882
Merit: 1000
from where comes 100MH/s!

makes you wonder....... some insane speed miners out there with this coin and algo..... wonder if claymore got his gpu miner for this version of M7 working already....

also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!
from where comes 100MH/s!

I can see suprnova pool has many MHps miners, any sign of GPU miners?

Edit, I have around 100 khps, 10MHps means about 100 cpus; that's still possible for one owns a cpu farm. That's a concern of pool mining, though everyone gets a share, pool mining just encourage big miners.
hero member
Activity: 848
Merit: 500
from where comes 100MH/s!
sr. member
Activity: 350
Merit: 250
Mining Co-operative
Oh wow! Thanks Joe. I just saw that in my wallet. I am very glad to be of help. Smiley
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!
@Spexx, thanks for the info that is very useful to other people. I donated 20 XMG to 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX, that's all I have; will send more once I can. I totally solo mined 80 XMG so far, with 60 XMG already donated somewhere to support XMG.
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!

This is very interesting.  I noted similar results when I was testing using a central wallet server like a solo pool.  It turned out that this was because each thread was starved of getwork data due to network latency.  Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true.  Conclusion: don't believe the hashrate results unless you are running at 100%.  

I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value)

Paul, the hash rate reported here by Spexx is the hps (not network hash rate) in a run, that is calculated in a loop by counting hashes within a time. I would say that's basically correct.
Understand that Joe - when I was testing using a remote VPS connecting to my local wallet at home, each thread was running at much higher hashrate than it should have been but the CPU was low - remember we had that conversation on IRC and said it was weird?  It turned out that each thread was starved of getwork due to latency.  Once I changed minerd to use a scantime of 3-5s the hashrate went back down to normal and CPU usage up to 100%.  So something isn't right with the per-thread hashrate calculation
Paul can you possibly confirm that again using the new nonce-pool's minerd: https://github.com/noncepool/m7m-cpuminer? With two minerds giving the same thing, this issue will be affirmed, and something we should look into.
full member
Activity: 131
Merit: 100
Good to know.

Tip of the day

Observations using Windows 7 64 bit, AMD 3100 quad-core processor as a testing rig.

magi.conf

addnode=66.55.90.58
addnode=107.107.52.31
addnode=162.243.219.192
daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=spexx
rpcpassword=stratocaster

Wallet mining solo with 4 threads generates approx 21 Kh/s or 5.25 Kh/s per thread.

Using any one of the 32 bit minerd.exe compilations for Windows that are currently available.

Solo mining using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 22 Kh/s or 5.5 Kh/s per thread.
Only 4.8 percent improvement on wallet mining.

Now, using the 64 bit minerd.exe from https://drive.google.com/file/d/0B9cvOfoOekSdQktZN1I2SVhnNUk/edit?usp=sharing

Using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 28 Kh/s or 7 Kh/s per thread.
Not bad with a 33 percent improvement on wallet mining.

OK so here is the clever bit

Using either the wallet mining or the 32 bit minerd.exe ensured that CPU time used was 100%
but the 64 bit minerd.exe only used 87 percent CPU time despite generating 33 percent more hashes.

Funny that. Smiley The CPU also seemed to be spending a lot of time in Kernel mode. So after a lot
of mucking about I found that starting minerd.exe with only 1 thread four times made a
big difference.

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 38 Kh/s or 9.25 Kh/s per thread.
An impressive 81 percent improvement on wallet mining. CPU time now up to around 98 percent
with very little time spent in Kernel mode. Result. How can we tweak the last 2 percent out now?

OK so here is the second clever bit

Now assign each minerd process to a fixed subset of three processors. On a four-core machine thus:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 41 Kh/s or 10.25 Kh/s per thread.
An impressive 95 percent improvement on wallet mining. CPU time now up to around 100 percent.

There is something here in the way a single minerd process handles multiple threads using this M7M algo.
Having multiple minerd processes running a single thread each uses processor time more efficiently.

On a 8-core machine you would need this batch file:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0x70 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

Hope this helps. Any kind donations for the tip here to XMG 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX please.

This is very interesting.  I noted similar results when I was testing using a central wallet server like a solo pool.  It turned out that this was because each thread was starved of getwork data due to network latency.  Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true.  Conclusion: don't believe the hashrate results unless you are running at 100%. 

I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value)

Paul, the hash rate reported here by Spexx is the hps (not network hash rate) in a run, that is calculated in a loop by counting hashes within a time. I would say that's basically correct.
Understand that Joe - when I was testing using a remote VPS connecting to my local wallet at home, each thread was running at much higher hashrate than it should have been but the CPU was low - remember we had that conversation on IRC and said it was weird?  It turned out that each thread was starved of getwork due to latency.  Once I changed minerd to use a scantime of 3-5s the hashrate went back down to normal and CPU usage up to 100%.  So something isn't right with the per-thread hashrate calculation
hero member
Activity: 820
Merit: 1000
Tip of the day

Observations using Windows 7 64 bit, AMD 3100 quad-core processor as a testing rig.

magi.conf

addnode=66.55.90.58
addnode=107.107.52.31
addnode=162.243.219.192
daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=spexx
rpcpassword=stratocaster

Wallet mining solo with 4 threads generates approx 21 Kh/s or 5.25 Kh/s per thread.

Using any one of the 32 bit minerd.exe compilations for Windows that are currently available.

Solo mining using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 22 Kh/s or 5.5 Kh/s per thread.
Only 4.8 percent improvement on wallet mining.

Now, using the 64 bit minerd.exe from https://drive.google.com/file/d/0B9cvOfoOekSdQktZN1I2SVhnNUk/edit?usp=sharing

Using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 28 Kh/s or 7 Kh/s per thread.
Not bad with a 33 percent improvement on wallet mining.

OK so here is the clever bit

Using either the wallet mining or the 32 bit minerd.exe ensured that CPU time used was 100%
but the 64 bit minerd.exe only used 87 percent CPU time despite generating 33 percent more hashes.

Funny that. Smiley The CPU also seemed to be spending a lot of time in Kernel mode. So after a lot
of mucking about I found that starting minerd.exe with only 1 thread four times made a
big difference.

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 38 Kh/s or 9.25 Kh/s per thread.
An impressive 81 percent improvement on wallet mining. CPU time now up to around 98 percent
with very little time spent in Kernel mode. Result. How can we tweak the last 2 percent out now?

OK so here is the second clever bit

Now assign each minerd process to a fixed subset of three processors. On a four-core machine thus:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 41 Kh/s or 10.25 Kh/s per thread.
An impressive 95 percent improvement on wallet mining. CPU time now up to around 100 percent.

There is something here in the way a single minerd process handles multiple threads using this M7M algo.
Having multiple minerd processes running a single thread each uses processor time more efficiently.

On a 8-core machine you would need this batch file:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0x70 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

Hope this helps. Any kind donations for the tip here to XMG 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX please.

This is very interesting.  I noted similar results when I was testing using a central wallet server like a solo pool.  It turned out that this was because each thread was starved of getwork data due to network latency.  Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true.  Conclusion: don't believe the hashrate results unless you are running at 100%. 

I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value)

Paul, the hash rate reported here by Spexx is the hps (not network hash rate) in a run, that is calculated in a loop by counting hashes within a time. I would say that's basically correct.
Understand that Joe - when I was testing using a remote VPS connecting to my local wallet at home, each thread was running at much higher hashrate than it should have been but the CPU was low - remember we had that conversation on IRC and said it was weird?  It turned out that each thread was starved of getwork due to latency.  Once I changed minerd to use a scantime of 3-5s the hashrate went back down to normal and CPU usage up to 100%.  So something isn't right with the per-thread hashrate calculation
legendary
Activity: 1260
Merit: 1000
Guys....apologies for the question but I have not been able to keep up with this thread the past few days and am low on time.

Is the mining software available now to allow pool mining?  If so, is it easy to setup and can you share the link to the software?

Thanks!

We have the pool mining now; many posts just coming up today, will summarize and include details into the OP.

Much appreciated brother!!  This has been a very tough one to keep with, at least for me being new to this tech I have understood very little that has been discussed here the past few weeks.

Will check back on OP later this evening.

Thanks again!!
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!
Guys....apologies for the question but I have not been able to keep up with this thread the past few days and am low on time.

Is the mining software available now to allow pool mining?  If so, is it easy to setup and can you share the link to the software?

Thanks!

We have the pool mining now; many posts just coming up today, will summarize and include details into the OP.
legendary
Activity: 1190
Merit: 1009
Coin of the Magi!
Tip of the day

Observations using Windows 7 64 bit, AMD 3100 quad-core processor as a testing rig.

magi.conf

addnode=66.55.90.58
addnode=107.107.52.31
addnode=162.243.219.192
daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=spexx
rpcpassword=stratocaster

Wallet mining solo with 4 threads generates approx 21 Kh/s or 5.25 Kh/s per thread.

Using any one of the 32 bit minerd.exe compilations for Windows that are currently available.

Solo mining using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 22 Kh/s or 5.5 Kh/s per thread.
Only 4.8 percent improvement on wallet mining.

Now, using the 64 bit minerd.exe from https://drive.google.com/file/d/0B9cvOfoOekSdQktZN1I2SVhnNUk/edit?usp=sharing

Using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 28 Kh/s or 7 Kh/s per thread.
Not bad with a 33 percent improvement on wallet mining.

OK so here is the clever bit

Using either the wallet mining or the 32 bit minerd.exe ensured that CPU time used was 100%
but the 64 bit minerd.exe only used 87 percent CPU time despite generating 33 percent more hashes.

Funny that. Smiley The CPU also seemed to be spending a lot of time in Kernel mode. So after a lot
of mucking about I found that starting minerd.exe with only 1 thread four times made a
big difference.

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 38 Kh/s or 9.25 Kh/s per thread.
An impressive 81 percent improvement on wallet mining. CPU time now up to around 98 percent
with very little time spent in Kernel mode. Result. How can we tweak the last 2 percent out now?

OK so here is the second clever bit

Now assign each minerd process to a fixed subset of three processors. On a four-core machine thus:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 41 Kh/s or 10.25 Kh/s per thread.
An impressive 95 percent improvement on wallet mining. CPU time now up to around 100 percent.

There is something here in the way a single minerd process handles multiple threads using this M7M algo.
Having multiple minerd processes running a single thread each uses processor time more efficiently.

On a 8-core machine you would need this batch file:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0x70 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

Hope this helps. Any kind donations for the tip here to XMG 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX please.

This is very interesting.  I noted similar results when I was testing using a central wallet server like a solo pool.  It turned out that this was because each thread was starved of getwork data due to network latency.  Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true.  Conclusion: don't believe the hashrate results unless you are running at 100%. 

I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value)

Paul, the hash rate reported here by Spexx is the hps (not network hash rate) in a run, that is calculated in a loop by counting hashes within a time. I would say that's basically correct.
hero member
Activity: 820
Merit: 1000
Tip of the day

Observations using Windows 7 64 bit, AMD 3100 quad-core processor as a testing rig.

magi.conf

addnode=66.55.90.58
addnode=107.107.52.31
addnode=162.243.219.192
daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=spexx
rpcpassword=stratocaster

Wallet mining solo with 4 threads generates approx 21 Kh/s or 5.25 Kh/s per thread.

Using any one of the 32 bit minerd.exe compilations for Windows that are currently available.

Solo mining using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 22 Kh/s or 5.5 Kh/s per thread.
Only 4.8 percent improvement on wallet mining.

Now, using the 64 bit minerd.exe from https://drive.google.com/file/d/0B9cvOfoOekSdQktZN1I2SVhnNUk/edit?usp=sharing

Using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 28 Kh/s or 7 Kh/s per thread.
Not bad with a 33 percent improvement on wallet mining.

OK so here is the clever bit

Using either the wallet mining or the 32 bit minerd.exe ensured that CPU time used was 100%
but the 64 bit minerd.exe only used 87 percent CPU time despite generating 33 percent more hashes.

Funny that. Smiley The CPU also seemed to be spending a lot of time in Kernel mode. So after a lot
of mucking about I found that starting minerd.exe with only 1 thread four times made a
big difference.

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 38 Kh/s or 9.25 Kh/s per thread.
An impressive 81 percent improvement on wallet mining. CPU time now up to around 98 percent
with very little time spent in Kernel mode. Result. How can we tweak the last 2 percent out now?

OK so here is the second clever bit

Now assign each minerd process to a fixed subset of three processors. On a four-core machine thus:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 41 Kh/s or 10.25 Kh/s per thread.
An impressive 95 percent improvement on wallet mining. CPU time now up to around 100 percent.

There is something here in the way a single minerd process handles multiple threads using this M7M algo.
Having multiple minerd processes running a single thread each uses processor time more efficiently.

On a 8-core machine you would need this batch file:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0x70 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

Hope this helps. Any kind donations for the tip here to XMG 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX please.

This is very interesting.  I noted similar results when I was testing using a central wallet server like a solo pool.  It turned out that this was because each thread was starved of getwork data due to network latency.  Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true.  Conclusion: don't believe the hashrate results unless you are running at 100%. 

I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value)
sr. member
Activity: 350
Merit: 250
Mining Co-operative
Tip of the day

Observations using Windows 7 64 bit, AMD 3100 quad-core processor as a testing rig.

magi.conf

addnode=66.55.90.58
addnode=107.107.52.31
addnode=162.243.219.192
daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=spexx
rpcpassword=stratocaster

Wallet mining solo with 4 threads generates approx 21 Kh/s or 5.25 Kh/s per thread.

Using any one of the 32 bit minerd.exe compilations for Windows that are currently available.

Solo mining using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 22 Kh/s or 5.5 Kh/s per thread.
Only 4.8 percent improvement on wallet mining.

Now, using the 64 bit minerd.exe from https://drive.google.com/file/d/0B9cvOfoOekSdQktZN1I2SVhnNUk/edit?usp=sharing

Using a batch file mineit.bat to start miner thus:-

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4

This configuration generates approx 28 Kh/s or 7 Kh/s per thread.
Not bad with a 33 percent improvement on wallet mining.

OK so here is the clever bit

Using either the wallet mining or the 32 bit minerd.exe ensured that CPU time used was 100%
but the 64 bit minerd.exe only used 87 percent CPU time despite generating 33 percent more hashes.

Funny that. Smiley The CPU also seemed to be spending a lot of time in Kernel mode. So after a lot
of mucking about I found that starting minerd.exe with only 1 thread four times made a
big difference.

start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 38 Kh/s or 9.25 Kh/s per thread.
An impressive 81 percent improvement on wallet mining. CPU time now up to around 98 percent
with very little time spent in Kernel mode. Result. How can we tweak the last 2 percent out now?

OK so here is the second clever bit

Now assign each minerd process to a fixed subset of three processors. On a four-core machine thus:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

This configuration generates approx 41 Kh/s or 10.25 Kh/s per thread.
An impressive 95 percent improvement on wallet mining. CPU time now up to around 100 percent.

There is something here in the way a single minerd process handles multiple threads using this M7M algo.
Having multiple minerd processes running a single thread each uses processor time more efficiently.

On a 8-core machine you would need this batch file:-

start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0x70 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xb0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xd0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1
start /min /low /affinity 0xe0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1

Hope this helps. Any kind donations for the tip here to XMG 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX please.
legendary
Activity: 1260
Merit: 1000
Guys....apologies for the question but I have not been able to keep up with this thread the past few days and am low on time.

Is the mining software available now to allow pool mining?  If so, is it easy to setup and can you share the link to the software?

Thanks!
Jump to: