Author

Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 233. (Read 877843 times)

Adz
newbie
Activity: 24
Merit: 0
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
hero member
Activity: 518
Merit: 500
Will NIST5, Talkcoin, eventually be included in this miner?
member
Activity: 119
Merit: 10
Sgminer should remain an all-purpose miner to be used with any pool.
full member
Activity: 168
Merit: 100
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!
sr. member
Activity: 547
Merit: 250
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
member
Activity: 119
Merit: 10
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.
sr. member
Activity: 364
Merit: 250
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!
newbie
Activity: 53
Merit: 0
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 Sad

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.
sr. member
Activity: 547
Merit: 250
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 Sad

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.
member
Activity: 119
Merit: 10
Mine don't switch off, but I do get driver crashes with NScrypt in general.  I can stop and start and fiddle with X11/X13 all day long with no crashes.  If I even glance at NScrypt the wrong way, it gives me trouble.
newbie
Activity: 53
Merit: 0
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 Sad

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?
member
Activity: 117
Merit: 10
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.
full member
Activity: 142
Merit: 101
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?
sr. member
Activity: 372
Merit: 250
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).
lbr
sr. member
Activity: 423
Merit: 254
Anyone know how to enable logging in the batch file that doesn't overwrite itself each time it starts?  I want to be able to check the log after a crash, but sometimes I don't catch it in time, and the evidence is lost.

Code:
@echo off
for /F "usebackq tokens=1,2 delims==" %%i in (`wmic os get LocalDateTime /VALUE 2^>NUL`) do if '.%%i.'=='.LocalDateTime.' set ldt=%%j
rem set ldt=%ldt:~0,4%-%ldt:~4,2%-%ldt:~6,2% %ldt:~8,2%:%ldt:~10,2%:%ldt:~12,6%
set ldt=%ldt:~0,4%-%ldt:~4,2%-%ldt:~6,2%_%ldt:~8,2%-%ldt:~10,2%

cgminer  2>"c:\log\cgminer_jane_%ldt%.log"
member
Activity: 119
Merit: 10
Anyone know how to enable logging in the batch file that doesn't overwrite itself each time it starts?  I want to be able to check the log after a crash, but sometimes I don't catch it in time, and the evidence is lost.
member
Activity: 119
Merit: 10
Problem is, that would eventually normalize all the different coins/algorithms.  Everything would be just one big coin, meaning us lowly GPU-miners would be SOL.

*edit* But it'd be great for a few months before everyone else finds out!
full member
Activity: 142
Merit: 101
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
member
Activity: 119
Merit: 10
Oh, unless you mean like, the server accepting everyone's hashes, and then scrambling them to match the format of each particular algorithm, and THEN passing it onto the node.  I guess that could be done.  That'd be pretty sweet actually.
member
Activity: 119
Merit: 10
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?
Jump to: