[ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay]

[peerson51888]

where can i download the 64 bit miner for win? thanks!

[SamWalters]

Coin Magi Video Teaser - Introduction to the First Hybrid: PoW/PoS-II

I'm still working on the pool to get it to support the network
In the mean time, I came up with this to help spread magi around



Video link: https://www.youtube.com/watch?v=W71FVD6YWM8 (2:04)

Special Thanks to developers of Coin Magi for giving us an opportunity of fair mining!
Credits go to my team who helped me make this video possible with their editing.

Please let me know what you all think, Magi community

[joelao95]

AMD FX-8350 4.00GHz = 96kh/s (ubuntu 14) at 100% CPU usage which I'm not actually doing. I'm just doing 6 cores. I wouldn't want to kill my sexy processor.

Your one is nice. Same here: AMD FX-8350 Black Edition Vishera 8-Core 4.0GHz, but with 6 core, I only got 70kh/s, ~90kh/s 8 cores (Xubuntu).

This cpu came with my AMD GPU rig, never used for mining. (I promise my AMD GPU is not mining XMG right now).

[IMJim]

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!

[Spexx]

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

[paulthetafy]

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

[joelao95]

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

[joelao95]

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.

[IMJim]

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!!

[paulthetafy]

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

[DarkWolf]

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

[joelao95]

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.

[joelao95]

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

[Spexx]

Oh wow! Thanks Joe. I just saw that in my wallet. I am very glad to be of help.

[Bojcha]

from where comes 100MH/s!

[joelao95]

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.

[nrg_wolf]

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

[peerson51888]

from where comes 100MH/s!

Maybe from claymore's GPU miner!

[nrg_wolf]

from where comes 100MH/s!

Maybe from claymore's GPU miner!

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

[joelao95]

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.