[ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner

[guzzzi]

Anyone else with the Problem when the Multi-Algo switch back to NScrypt that SGMiner puts all GPUs to OFF? All other Switchings seems to work, but always when comes from Scrypt/x11/x13 to NScrypt it breaks my Cards Off

If the Multi-Algo starts in the NScrypt Algo everything works fine. But when switching (example) Nscrypt (fine) => X11 (fine) => Nscrypt (GPUs OFF)

Maybe someone gives me a hint to fix this on client side?

Yes, these seems to be an either-or situation.  Either X11/X13/Keccak or Scrypt/Scrypt-N.

There's always rumors of people saying more system RAM and bullshit.  I'm not throwing 32GB of system RAM in to find out.

EDIT:  Newest build from the nicehash page the 11th is pretty stable on the X11/X13 no keccak has kicked in, but  uptime has been 8 hours - minimal rejects.

Got 8GB PC Ram on Windows 8.1 x64 in this Machine. Using the Build from 20140611 but as i wrote, nscrypt set my gpus to off when switching back.

[Starscream]

EDIT:  Newest build from the nicehash page the 11th is pretty stable on the X11/X13 no keccak has kicked in, but  uptime has been 8 hours - minimal rejects.

Thanks for that!

[KiloWatts]

I hashed N-Scrypt all night.  Woke up to a dead rig, and this in the log:

Code:

[04:32:40] Stratum connection to NiceHash_Scrypt-N interrupted
[04:32:51] Waiting for work to be available from pools.
[04:32:53] NiceHash_Scrypt-N not responding!
[04:32:53] Switching to NiceHash_Scrypt_Regular_Backup
[04:33:06] NiceHash_Scrypt_Regular_Backup not responding!
[04:33:23] NiceHash_Scrypt alive, testing stability
[04:33:25] Switching to NiceHash_Scrypt
[04:33:31] Work available from pools, resuming.
[04:33:31] Building binary ckolivasHawaiigw256l4lg2tc24550nf10.bin

Not very helpful, I know.

[platinum4]

I hashed N-Scrypt all night.  Woke up to a dead rig, and this in the log:

Code:

[04:32:40] Stratum connection to NiceHash_Scrypt-N interrupted
[04:32:51] Waiting for work to be available from pools.
[04:32:53] NiceHash_Scrypt-N not responding!
[04:32:53] Switching to NiceHash_Scrypt_Regular_Backup
[04:33:06] NiceHash_Scrypt_Regular_Backup not responding!
[04:33:23] NiceHash_Scrypt alive, testing stability
[04:33:25] Switching to NiceHash_Scrypt
[04:33:31] Work available from pools, resuming.
[04:33:31] Building binary ckolivasHawaiigw256l4lg2tc24550nf10.bin

Not very helpful, I know.

Quite clear proof of the cards being turned off when going from nf11 Scrypt-N to nf10 Scrypt

[comeonalready]

You guys really mucked up the implementation of the extranonce subscription extension.  Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default.  You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.

Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do.  But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there.  Or was sabotaging your competitors part of the original plan?

I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out).

I posted that message to the nicehash forum over a month ago (not yesterday!), and your having removed that surrounding context does indeed make that last sentence sound kinda stupid.  Nicehash devised that stratum protocol extension, with this glaring flaw, and it was so easy to get right too.  All they needed to do to make it fully compatible with other pools without having to worry whether it was enabled or disabled by default in the client was to initiate the transaction from the server side -- by sending a "mining.subscribe_extranonce" message (or something like it) to the client and have it handled in within the parse_method function of a compatible cgminer/sgminer and ignored by all the rest -- instead of sending a subscribe.extranonce message before a mining.authorize message to all other unexpecting pools.

And no, it is never too late to change something that is clearly broken.  The problem is a custom stratum protocol extension implemented by nicehash, for nicehash, and negatively effecting so many miners on other pools, including many who have no idea what is happening or how to disable it, thereby causing them to assume that there is something wrong with many other pools, when it is in fact their mining software at fault.  At the very least, it should be disabled by default!

[KiloWatts]

Sgminer should remain an all-purpose miner to be used with any pool.

[SpeedDemon13]

Will NIST5, Talkcoin, eventually be included in this miner?

[Adz]

Yep, this version doesn't work right with NScrypt and 14.1 drivers.

Here's the same config with 13.12 drivers.  Still not ideal, but better.

Yeah I'm on 13.12 drivers and I refuse to upgrade.  You might need to start looking at different TC's to tweak the speed.  I've seen a number of 290 configs using TC 32765

I used to have 24550 on my 290's, but the 2% rejects started to bother me regardless of how great the hashrate was.  I changed it to 25600 and now my reject % is below .5%.

Hey guys are you talking about the AMD Catalyst Drivers?  i'm a late scrypt-n adopter, haven't mined it outside of this multipool setup on nicehash
Thanks

[platinum4]

Yep, this version doesn't work right with NScrypt and 14.1 drivers.

Here's the same config with 13.12 drivers.  Still not ideal, but better.

Yeah I'm on 13.12 drivers and I refuse to upgrade.  You might need to start looking at different TC's to tweak the speed.  I've seen a number of 290 configs using TC 32765

I used to have 24550 on my 290's, but the 2% rejects started to bother me regardless of how great the hashrate was.  I changed it to 25600 and now my reject % is below .5%.

Hey guys are you talking about the AMD Catalyst Drivers?  i'm a late scrypt-n adopter, haven't mined it outside of this multipool setup on nicehash
Thanks

Yep 14's will drop your performance on nscrypt

[mannyg]

I've come across a new problem with my 290 rig.

When an algo switch happens like the recent one from scrypt-n to X13, sgminer stops hashing and quits.  If I restart it, one of my 290's loses control of its temp and it sky rockets way higher than the other 290's.  If I restart the rig and start sgminer, same thing keeps happening.  I've even tried to remove the 290's from device manager and have them redetect the drivers, same problem.  The temp problem only happens with algos like scrypt and scrypt-n that are very GPU intensive

Until now, the only solution around it is to power off the rig, unplug the PSU, wait a few minutes, then fire it all back up. Only then is everything mining at the same temp across all 3 GPUs.

I've never had this issue until i started using the newer sgminer v5's.  Any thoughts?

[phzi]

You guys really mucked up the implementation of the extranonce subscription extension.  Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default.  You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.

Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do.  But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there.  Or was sabotaging your competitors part of the original plan?

I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out).

I posted that message to the nicehash forum over a month ago (not yesterday!), and your having removed that surrounding context does indeed make that last sentence sound kinda stupid.  Nicehash devised that stratum protocol extension, with this glaring flaw, and it was so easy to get right too.  All they needed to do to make it fully compatible with other pools without having to worry whether it was enabled or disabled by default in the client was to initiate the transaction from the server side -- by sending a "mining.subscribe_extranonce" message (or something like it) to the client and have it handled in within the parse_method function of a compatible cgminer/sgminer and ignored by all the rest -- instead of sending a subscribe.extranonce message before a mining.authorize message to all other unexpecting pools.

And no, it is never too late to change something that is clearly broken.  The problem is a custom stratum protocol extension implemented by nicehash, for nicehash, and negatively effecting so many miners on other pools, including many who have no idea what is happening or how to disable it, thereby causing them to assume that there is something wrong with many other pools, when it is in fact their mining software at fault.  At the very least, it should be disabled by default!

comeonalready speaks the truth.

[KiloWatts]

Yes!  Flawless!   


Scrypt-N  to X13:

Code:

[18:51:16] Accepted aef2d217 Diff 374/256 GPU 1 at NiceHash_Scrypt-N 
[18:52:44] Accepted 1124f706 Diff 3.82K/256 GPU 0 at NiceHash_Scrypt-N 
[18:53:33] Accepted 97e9d35c Diff 431/256 GPU 0 at NiceHash_Scrypt-N 
[18:54:04] Accepted 7fd25f61 Diff 512/256 GPU 1 at NiceHash_Scrypt-N 
[18:54:26] Stratum connection to NiceHash_Scrypt-N interrupted
[18:54:36] Waiting for work to be available from pools.
[18:54:40] NiceHash_Scrypt-N not responding!
[18:54:40] Switching to NiceHash_X13
[18:54:40] NiceHash_X13 difficulty changed to 0.040
[18:54:46] Work available from pools, resuming.
[18:54:46] Building binary marucoin-modHawaiigw256l4big4.bin
[18:55:13] Initialising kernel marucoin-mod.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[18:55:13] NiceHash_Scrypt_Regular_Backup extranonce change requested
[18:55:13] Initialising kernel marucoin-mod.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[18:55:45] Accepted 0bfc38c3 Diff 0.083/0.040 GPU 1 at NiceHash_X13 
[18:57:30] Accepted 0234fd59 Diff 0.453/0.040 GPU 1 at NiceHash_X13 
[18:58:19] Accepted 1533d1b6 Diff 0.047/0.040 GPU 1 at NiceHash_X13 
[18:58:35] Accepted 05732ed5 Diff 0.183/0.040 GPU 1 at NiceHash_X13 

X13 to Scrypt-N

Code:

[19:13:21] Accepted 0f733c31 Diff 0.065/0.040 GPU 0 at NiceHash_X13 
[19:13:36] Accepted 064edf7b Diff 0.159/0.040 GPU 0 at NiceHash_X13 
[19:13:37] NiceHash_Scrypt-N alive, testing stability
[19:13:40] Accepted 0e8566c8 Diff 0.069/0.040 GPU 1 at NiceHash_X13 
[19:13:52] Accepted 15fd453d Diff 0.045/0.040 GPU 0 at NiceHash_X13 
[19:14:11] NiceHash_Scrypt-N stable for 30 seconds
[19:14:11] Switching to NiceHash_Scrypt-N
[19:14:12] Initialising kernel zuikkis.cl with bitalign, unpatched BFI, nfactor 11, n 2048
[19:14:12] Initialising kernel zuikkis.cl with bitalign, unpatched BFI, nfactor 11, n 2048
[19:14:26] Stratum connection to NiceHash_X13 interrupted
[19:15:18] Accepted fd2487d2 Diff 258/256 GPU 1 at NiceHash_Scrypt-N 
[19:15:23] NiceHash_Scrypt-N stale share detected, discarding
[19:15:51] Accepted 7d121b05 Diff 523/256 GPU 1 at NiceHash_Scrypt-N 
[19:16:18] Accepted 08c921f6 Diff 7.46K/256 GPU 0 at NiceHash_Scrypt-N 

[KiloWatts]

You guys really mucked up the implementation of the extranonce subscription extension.  Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default.  You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.

Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do.  But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there.  Or was sabotaging your competitors part of the original plan?

I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out).

I posted that message to the nicehash forum over a month ago (not yesterday!), and your having removed that surrounding context does indeed make that last sentence sound kinda stupid.  Nicehash devised that stratum protocol extension, with this glaring flaw, and it was so easy to get right too.  All they needed to do to make it fully compatible with other pools without having to worry whether it was enabled or disabled by default in the client was to initiate the transaction from the server side -- by sending a "mining.subscribe_extranonce" message (or something like it) to the client and have it handled in within the parse_method function of a compatible cgminer/sgminer and ignored by all the rest -- instead of sending a subscribe.extranonce message before a mining.authorize message to all other unexpecting pools.

And no, it is never too late to change something that is clearly broken.  The problem is a custom stratum protocol extension implemented by nicehash, for nicehash, and negatively effecting so many miners on other pools, including many who have no idea what is happening or how to disable it, thereby causing them to assume that there is something wrong with many other pools, when it is in fact their mining software at fault.  At the very least, it should be disabled by default!

comeonalready speaks the truth.

Yeah...  just change:

"no-extranonce-subscribe" : true

to

"extranonce-subscribe" : true

and set default to false.

Problem solved.

[mannyg]

I've come across a new problem with my 290 rig.

When an algo switch happens like the recent one from scrypt-n to X13, sgminer stops hashing and quits.  If I restart it, one of my 290's loses control of its temp and it sky rockets way higher than the other 290's.  If I restart the rig and start sgminer, same thing keeps happening.  I've even tried to remove the 290's from device manager and have them redetect the drivers, same problem.  The temp problem only happens with algos like scrypt and scrypt-n that are very GPU intensive

Until now, the only solution around it is to power off the rig, unplug the PSU, wait a few minutes, then fire it all back up. Only then is everything mining at the same temp across all 3 GPUs.

I've never had this issue until i started using the newer sgminer v5's.  Any thoughts?

Figured out my own problem... GPU had a lazy fan... had to set gpu-fan to 100 to keep it going

[W0rkH0rse]

I really would rather see the switching happen on the server end rather than the client...

That would be impossible...  the miners are on the client side.  The server just rents the hash speed out.

It might be possible with a whole new algorithm dedicated to giving hashrate to the server on the backend. It would need to be designed from the ground up just for this sole purpose.

Hmm...  That still seems insanely impossible...  For instance, you're essentially talking about trying to 'convert' Scrypt hashes to X11 hashes, or vice versa...  Trying to match a hash with 1 algorithm is already difficult enough, yeah?

mmmm yeahh something like that.  If it is possible, it opens up the door to a whole new world of possibilities... ESPECIALLY if you can do it with sha-256 to x11 or scrypt ... hell or whatever actually works.  My ASIC miners for SHA run like clockwork for weeks straight, .. the GPU rigs are quickly taking up all of my time again now with the multi-algo switching.

*edit*
Think of a mining algo in which a GPU rig connects to, mines, and its work gets automatically converted to the X11, X13, etc. etc. hell, name the kernel nicehash.cl ... it would need to be a proprietary design

Guys, think about it, it's just impossible.  SHA256, X11, X13, nFactor, Scrypt are all algorithms, what we submit to the pool is the result of that algorithm (mathematical operation).  What you are asking is basically for the server to do the job for you (hence mine for you).  

You can't take a SHA256 (or whatever else) hash and convert it to X11, X13, etc.  The reason why they come up with those algos is in part to make them asic resistant (for a while at least), so that GPUs remain somewhat profitable.

For a server to "convert" a hash into another algo's hash would literally imply that the server would have to do the work for you which defeats the purpose of mining (you're supposed to be doing the work yourself, not the server).

So the data contained in the share that your GPU hashed and submitted cant be translated and converted into a different share?  Maybe in a scenario of miner to miner on both ends? In the end, isnt it just data of 1's and 0's?

Suggest that you can convert hash from one algo to another: fuck cryptography in this case. For example "blablabla" without quotes in sha256:

Code:

892cd4be79b2bea361b51a472ef8a587730ca3c95816e1a2a8761a82a787bbdf

and same in sha-3 256:

Code:

0744ea4be0f20ad77cace16010f20019a126a4fd1e07cc5f9d2e59c316cbcf02

No link between them, except encrypted word inside. Hashing algorithms are one-way i.e. They cannot be reversed unlike Encryption-Decryption algorithms. You can use with same probability random number generator for mining.

What if you attached some sort of trigger to the pool share difficulty change command received which would force the program to switch to a different config/kernel?
Also, you are a rockstar and I've nominated you and benmagro for the nobel prize in the (requested but not yet existent) bitcoin category. So far no response from the Queen/committee.

[guzzzi]

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed

Any solution for this? Missing 6 Hours every Day hurts.

[KiloWatts]

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed

Any solution for this? Missing 6 Hours every Day hurts.

Have you tested X13 on its own first to see if it's stable?  (non-multiswitch port 3337)

I think it's wise with this multiswitching to be a little more conservative with how hard you push the GPUs, since you add the variable of switching.  Keep your engine, clock, intensity, slightly lower than you would if you're mining only 1 algorithm.  After you find settings that allow smooth switching, slowly tweak from there.

[Elun]

For everyone who have issues with sgminer_5 and "device" option, you can use this option in configure file, until it is not fixed:
"remove-disabled" : true

[guzzzi]

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed

Any solution for this? Missing 6 Hours every Day hurts.

Have you tested X13 on its own first to see if it's stable?  (non-multiswitch port 3337)

I think it's wise with this multiswitching to be a little more conservative with how hard you push the GPUs, since you add the variable of switching.  Keep your engine, clock, intensity, slightly lower than you would if you're mining only 1 algorithm.  After you find settings that allow smooth switching, slowly tweak from there.

Yes working 100%. Switching between Scrypt/X11/X13 working perfect everythink runs stable. But NScrypt kills my GPU as soon there was a switch back to NScrypt.
Ok will try to set the Settings a little bit lower. But isnt it possible for SGMiner to start Algos slower? So reduce the Speed for the first minute to a minimum of speed, after that start to raise to the final configuration in full speed?

[platinum4]

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed

Any solution for this? Missing 6 Hours every Day hurts.

Have you tested X13 on its own first to see if it's stable?  (non-multiswitch port 3337)

I think it's wise with this multiswitching to be a little more conservative with how hard you push the GPUs, since you add the variable of switching.  Keep your engine, clock, intensity, slightly lower than you would if you're mining only 1 algorithm.  After you find settings that allow smooth switching, slowly tweak from there.

Yes working 100%. Switching between Scrypt/X11/X13 working perfect everythink runs stable. But NScrypt kills my GPU as soon there was a switch back to NScrypt.
Ok will try to set the Settings a little bit lower. But isnt it possible for SGMiner to start Algos slower? So reduce the Speed for the first minute to a minimum of speed, after that start to raise to the final configuration in full speed?

Yep I think we need a full 60 seconds at least for a memory flush to avoid those -4 Errors but I am not a chip designer.