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

[badman74]

@badman74, can you compile an x64 build of the latest commits to sgminer5 repo, the one that adds in log-file capabilities in the .conf files?

unfortunately i have broken my mingw so until i can fix that i cant build anything

Gah, in the same boat as me now huh!

this whole problem makes me to wonder how i got it to work in the first place

[platinum4]

@badman74, can you compile an x64 build of the latest commits to sgminer5 repo, the one that adds in log-file capabilities in the .conf files?

unfortunately i have broken my mingw so until i can fix that i cant build anything

Gah, in the same boat as me now huh!

this whole problem makes me to wonder how i got it to work in the first place

Dude, I've tried both ways, mingw and MSVC way too, no dice, can't do it.

mingw fails on autoreconf -fvi

forgot the error message for the other way

[unlock.mk]

With HD5970 HD5850 HD5870 getting lower hashrate by  10%

Copied those files in sgminer folder and hashrate lowered.

Delete the files you copied, and delete the .bin files again, and you will be back to normal.  Did you delete the .bin files after copying the driver files and before launching sgminer?

I wouldnt expect them to boost older cards. As far as I can tell, it really only boosts performance of the R7/R9 GPUs

I am back to normal, and yes i deleted bin file, to render new one, but that was result.
I can't make it to boost, however, i can;t make it to setup miner to mine X15 also.
sgminer v5 as soon as started, it freezes my pc completly, so i have to restart it.
If anyone has experience for HD5XXX cards and X15 please write a full config here.

using 64bit Windows 7,

[hotrock]

So I finally got things figured out enough to get 5.0 (already compiled from NH website) to work and produce expected hash rates for both scrypt and X11.

I was wanting to try the updated version because what I originally had running seemed to lock up when switching algos. I downloaded and compiled the latest version from github. Everything seemed to compile just fine (I used the directions from the NiceHash FAQ, replacing file paths accordingly). However, when I run the compiled version it fails to load the card temps and fan rpms while also having a tiny hash rate.

If I understand this correctly the miner isn't loading the drivers, is that correct? If this is incorrect what is it that is wrong?

Thanks in advanced!

[kenshirothefist]

Fresh sgminer builds: https://www.nicehash.com/software/#sgminer

We have also established daily nightly builds, so you'll be able to get fresh sgminer builds each day here: https://www.nicehash.com/software/nightly/ (uploaded each day at 04:30 UTC).

[badman74]

So I finally got things figured out enough to get 5.0 (already compiled from NH website) to work and produce expected hash rates for both scrypt and X11.

I was wanting to try the updated version because what I originally had running seemed to lock up when switching algos. I downloaded and compiled the latest version from github. Everything seemed to compile just fine (I used the directions from the NiceHash FAQ, replacing file paths accordingly). However, when I run the compiled version it fails to load the card temps and fan rpms while also having a tiny hash rate.

If I understand this correctly the miner isn't loading the drivers, is that correct? If this is incorrect what is it that is wrong?

Thanks in advanced!

Sounds like you failed to put the ad files in ADL_SDK folder before compiling

[jkminkov]

Code:

{
"pools" : [
        {
 		"name" : "am02 x15 multi",
		"url" : "stratum+tcp://am02.eu.trademybit.com:4012",
		"user" : "user.1",
		"pass" : "xyz",
                "profile":"x15"
	},
        {
 		"name" : "am02 x11 multi",
		"url" : "stratum+tcp://am02.eu.trademybit.com:4010",
		"user" : "user.1",
		"pass" : "xyz",
                "profile":"x11"
	},
        {
		"name" : "am02 x13 multi",
		"url" : "stratum+tcp://am02.eu.trademybit.com:4011",
		"user" : "user.1",
		"pass" : "xyz",
                "profile":"x13"
	}
],
"include" : "profiles.conf"
}

Code:

{
"profiles" : [
	{
		"name" : "x11",
		"algorithm" : "darkcoin-mod,darkcoin-mod",
		"intensity" : "19,19",
		"gpu-threads" : "1",
		"worksize": "64,64",
		"gpu-engine": "600-870,600-870",
		"gpu-memclock": "1000,1000",
		"gpu-fan": "50-100,50-100"
	},
	{
		"name" : "x13",
		"algorithm" : "marucoin-modold,marucoin-modold",
		"intensity" : "19,19",
		"gpu-threads" : "1",
		"worksize": "64,64",
		"gpu-engine": "600-870,600-870",
		"gpu-memclock": "1000,1000",
		"gpu-fan": "50-100,50-100"
	},
	{
		"name" : "x15",
		"algorithm" : "bitblockold,bitblockold",
		"intensity" : "16,16",
		"worksize" : "64,64",
		"gpu-threads": "1",
		"gpu-engine" : "600-850,600-850",
		"gpu-memclock" : "900,900",
		"gpu-fan" : "50-100,50-100"
	}
],	

"extranonce-subscribe" : true,
"remove-disabled" : false,
"expiry" : "10",
"failover-only" : true,
"kernel-path" : "d:\\sgminer_v5_0_30062014",
"log" : "5",
"queue" : "1",
"scan-time" : "5",
"shares" : "0",
"failover-switch-delay" : "10",
"gpu-dyninterval" : "7",
"gpu-platform" : "0,0",
"gpu-memdiff" : "0,0",
"gpu-powertune" : "0,0",
"gpu-vddc" : "1.163,1.163",
"auto-fan" : true,
"auto-gpu" : true,
"temp-target" : "75",
"temp-overheat" : "85",
"temp-cutoff" : "95",
"temp-hysteresis" : "3",
"vectors" : "1,1",
"lookup-gap" : "2,2",
"shaders" : "1600,1600",
"thread-concurrency" : "8000,8000",
"show-coindiff" : true,
"device" : "0,1",
"no-pool-disable" : true
}

what's wrong with trying to use profiles, it shows compilying ckolivas kernel and then freezes

[platinum4]

Fresh sgminer builds: https://www.nicehash.com/software/#sgminer

We have also established daily nightly builds, so you'll be able to get fresh sgminer builds each day here: https://www.nicehash.com/software/nightly/ (uploaded each day at 04:30 UTC).

GREAT FUCKING IDEA.

HUGE THANKS TO NICEHASH ON THIS.

[badman74]

To developers:
Can you add X15 core from this miner: https://bitcointalk.org/index.php?topic=658438.0

X15 speed:
7950 (1080/1400) - 2.8 Mhash/s
280x (1060/1500) - 3.2 Mhash/s
270 (1100/1500) - 1.8 Mhash/s

are you saying that the x15 kernel from that miner is faster the the one from this one?
i get 3.5 mh/s on 290x with 1000/1250 clock

[Ale-x]

are you saying that the x15 kernel from that miner is faster the the one from this one?
i get 3.5 mh/s on 290x with 1000/1250 clock

Yes. It is faster. With this miner speed is same as X13 algo and even more bit faster.

[badman74]

are you saying that the x15 kernel from that miner is faster the the one from this one?
i get 3.5 mh/s on 290x with 1000/1250 clock

Yes. It is faster. With this miner speed is same as X13 algo and even more bit faster.

you can go here and open a new issue to try to get the devs to look at it
https://github.com/sgminer-dev/sgminer/issues?state=open

[nicehashdev]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

[xIIImaL]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

Can anyone show the configuration file for this release?

[badman74]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

Can anyone show the configuration file for this release?

its not a release.... its a proposal to make a change in stratum code and miner code

[langes01x]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

There is no need to have the server do this. It would be just as easy to create a client-side switcher that can figure out when it should switch between different algorithms. I've created a switcher like this for the TradeMyBit pool that uses sgminer v5 no-restart switching (and the old method of switching for backwards compatibility). As long as the NiceHash pool has an API that returns the profitability of each algorithm then it's just a matter of deciding if or when you want to switch.

See https://bitcointalk.org/index.php?topic=661827

[badman74]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

There is no need to have the server do this. It would be just as easy to create a client-side switcher that can figure out when it should switch between different algorithms. I've created a switcher like this for the TradeMyBit pool that uses sgminer v5 no-restart switching (and the old method of switching for backwards compatibility). As long as the NiceHash pool has an API that returns the profitability of each algorithm then it's just a matter of deciding if or when you want to switch.

See https://bitcointalk.org/index.php?topic=661827

why couldn't this determine the profitability on its own, just give it your hash rates and cost and get the price info from the web then have it switch as necessary on ANY pool
i know it isn't setup that way now but that would be something i would like to see built into cgwatcher...
edit: well it looks like cgwatcher can do this as long as you pay for the coinwarz api key so you can see the profitability of more than just sha256 and scrypt coins
then again i dont want to go to the trouble of selling those coins myself so i will just stick with a service that does it for me

[langes01x]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

There is no need to have the server do this. It would be just as easy to create a client-side switcher that can figure out when it should switch between different algorithms. I've created a switcher like this for the TradeMyBit pool that uses sgminer v5 no-restart switching (and the old method of switching for backwards compatibility). As long as the NiceHash pool has an API that returns the profitability of each algorithm then it's just a matter of deciding if or when you want to switch.

See https://bitcointalk.org/index.php?topic=661827

why couldn't this determine the profitability on its own, just give it your hash rates and cost and get the price info from the web then have it switch as necessary on ANY pool

The point is that it could as long as NiceHash (or whatever multi-algo pool you want to mine at) expose the appropriate API required to get the profitability information for the algorithms they are currently mining.

Of course as it is it wouldn't work but it would only take a small number of tweaks to get it working with other pools. If that is possible (i.e. the required API exists) and people want it then I could look into it.

[phzi]

I have proposal for stratum extension to support algorithm change without reconnects.

First, we need to normalize name of the algorithms; example:

Code:

scrypt, nscrypt, x11, x13, x15

Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.

Example for 2 algorithms:

Code:

{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n

Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):

{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n

Immediately after that server sends new difficulty and new work.

How about this extension is NOT messed up like extranonce subscription the first time around?  Having a miner "subscribe" to calls that a server may or may not support makes little sense.  The pool should inform the miner during connect that it supports this extension, and then allow the miner to respond with multiple algorithms if desired.  Otherwise, when the miner sends your proposed "subscribe" command to a non-supporting pool, it is going to break pool connectivity (just like extranonce subscribe caused all kinds of problems for users).

[platinum4]

are you saying that the x15 kernel from that miner is faster the the one from this one?
i get 3.5 mh/s on 290x with 1000/1250 clock

Yes. It is faster. With this miner speed is same as X13 algo and even more bit faster.

Looked in the source; no bitblock.cl

What mystery .cl file are you hashing with, or was this a typo?

Post a pastebin.

[hotrock]

Sounds like you failed to put the ad files in ADL_SDK folder before compiling

Okay, went back and recompiled. Looking over the command history I saw where I messed up. Put a file path to the AMDAPP when I should have done ADL_SDK. I double checked everything this time and I'm getting all the stats I'm expecting. Thank you for the suggestion but for some reason it hated my config so I went with a nightly build as kenshirothefit told me about.

Now that I have that up and running I can get X11 going as expected but Scrypt gives me hardware errors faster than you can keep track of. I'm using the same config that gave me successful and stable 1mh/s between my two 270s.

Any ideas?

edit: seems I can't get a stable scrypt has anymore no matter what version I use.

HW seem to be kernel agnostic (have tried both clov and zuik.) The nightly build produces massive HW while the standard download produces approximately 1/card per 10-20 seconds.

Code:

{
  "pools": [
    {
      "name": "nicehash_X11",
      "url": "stratum+tcp://stratum.nicehash.com:3336",
      "user": "1D4Qprjeq6AA3PZgVuMC8JnA4nbMQeDWKp",
      "pass": "d=0.04",
      "profile": "x11"
    },
    {
      "url": "stratum+tcp://eu.clevermining.com:3333",
      "user": "1D4Qprjeq6AA3PZgVuMC8JnA4nbMQeDWKp",
      "pass": "x",
      "priority": "1",
      "profile": "scrypt"
    }
  ],
  "profiles": [
    {
      "name": "x11",
      "algorithm": "darkcoin-mod",
      "intensity": "17",
      "worksize": "256",
      "gpu-engine": "1120",
      "gpu-threads": "2"
    },
    {
      "name": "scrypt",
      "algorithm": "zuikkis",
      "intensity": "17",
      "worksize": "256",
      "gpu-engine": "1140",
      "gpu-memclock": "1500",
      "gpu-threads": "1"
    }
  ],
  "failover-only": true,
  "algorithm": "zuikkis",
  "devices": "all",
  "thread-concurrency": "8193",
  "gpu-fan": "50-80,50-80",
  "gpu-powertune": "20",
  "temp-cutoff": "95,95",
  "temp-overheat": "85,85",
  "temp-target": "77,64",
  "gpu-memdiff": "0,0",
  "shares": "0",
  "kernel-path": "/usr/local/bin",
  "api-allow": "W:127.0.0.1",
  "api-listen": true,
  "api-mcast-port": "4028",
  "api-port": "4028",
  "auto-fan": true,
  "expiry": "28",
  "failover-switch-delay": "30",
  "gpu-dyninterval": "7",
  "gpu-platform": "-1",
  "hamsi-expand-big": "4",
  "log": "5",
  "no-pool-disable": true,
  "no-client-reconnect": true,
  "no-submit-stale": true,
  "queue": "0",
  "scan-time": "7",
  "temp-hysteresis": "3"
}