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

[platinum4]

Adz does that setting always crash on Windows? Or just in some special circumstances?

I have found that       "pool-gpu-threads": "2"    under Windows
Will always cause sgminer to exit after 60sec

Correct; do not employ the use of "pool-gpu-threads"

[1715241914]

1715241914

[1715241914]

1715241914

[1715241914]

1715241914

[KiloWatts]

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

I think 27000 is the magic number for 290x and nscrypt.

Now, I wish I could get X11 to work right with The Stilt's BIOS...   It's great for Scrypt and N-Scrypt, but it really doesn't like X11 and X13 for some reason.

[kingscrown]

this is SEXY!

[crymzyn]

Hmmm, all of my nicehash pools show 'Dead'.  Anyone else having issues?  I've been running everything without issues for a couple weeks...

Update: Must have been some some sort of network issue, came back to check 30 min later and they're aliiiive

[mannyg]

Yeah this multi-algo switching thing is great, but the amount of re-working and hassle i've had to go through all over again is just plain frustrating. I'm finding that no matter how well I think my rigs are mining for a while, they always take a shit on me when im not looking, and it usually happens when a switch happens.  I really would rather see the switching happen on the server end rather than the client... i've actually given thought to scrapping the multi-algo thing and just setting up plain failover pools and switching over manually myself when i see a more profitable algorithm.

[KiloWatts]

Seriously sexy.  My miner switched from N-Scrypt to X11 while I was away without a hitch.  This is coming along very nicely.

[KiloWatts]

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.

[mannyg]

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.

[KiloWatts]

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?

[KiloWatts]

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.

[mannyg]

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

[KiloWatts]

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!

[KiloWatts]

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.

[lbr]

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"

[cryptofunk]

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

[mannyg]

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?

[Elun]

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.

[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?

[KiloWatts]

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.

[platinum4]

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.