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

badman74

hero member

Activity: 658

Merit: 500

Quote from: rudarSRB on July 10, 2014, 08:11:05 AM

Could someone share his config and speeds for 290x cards?

scrypt : 600kh/s
nscrypt : 325kh/s
x11 : 5.4mh/s
x13 : 4mh/s
x15 : 3.5mh/s
keccak : 350mh/s
nist5 : 16.5mh/s
this is with default clocks

Code:

{
"pools" : [
	{
		"name" : "NH x13 multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4337",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=.01;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"algorithm" : "marucoin-mod",
		"intensity" : "18",
		"gpu-threads" : "2",
		"worksize": "256"
	},
	{
		"name" : "NH x11 multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4336",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=.01;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"algorithm" : "darkcoin-mod",
		"intensity" : "17",
		"gpu-threads" : "2",
		"worksize": "128"
	},
	{
		"name" : "NH x15 multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4339",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=.01;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"algorithm" : "bitblock",
		"intensity" : "16",
		"gpu-threads" : "2",
		"worksize": "256"
	},
	{
		"name" : "NH NIST5 multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4340",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=.01;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"algorithm" : "talkcoin-mod",
		"intensity" : "16",
		"gpu-threads" : "2",
		"worksize": "256"
	},
	{
		"name" : "NH keccak multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4338",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=.01;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"intensity" : "12",
		"worksize" : "256",
		"gpu-threads": "4",
		"algorithm" : "maxcoin"
	},
	{
		"name" : "NH scrypt multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4333",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=64;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"intensity" : "16",
		"worksize" : "64",
		"lookup-gap" : "2",
		"gpu-threads": "1",
		"algorithm" : "alexkarnew",
		"nfactor" : "10"
	},
	{
		"name" : "NH nscrypt multi",
		"url" : "stratum+tcp://stratum.nicehash.com:4335",
		"user" : "1AHDnxrDrPkP7mPNPbhx3LsQTXZuXvbFAA",
		"pass" : "d=64;f0=1.3;f2=.65;f3=10.5;f4=8;f5=700;f6=7;f7=33",
		"intensity" : "16",
		"worksize" : "64",
		"lookup-gap" : "2",
		"gpu-threads": "2",
		"algorithm" : "zuikkis",
		"nfactor" : "11"
	},
	{
		"name" : "Xpool Dark Multipool",
		"url" : "stratum+tcp://mine.xpool.ca:8888",
		"user" : "XvRs67Wnw1n1Kwtq4ihhTpv699DdJpxdnt",
		"pass" : "x",
		"algorithm" : "darkcoin-mod",
		"intensity" : "17",
		"gpu-threads" : "2",
		"worksize": "128"
	}
],
"hamsi-expand-big" : "1",
"hamsi-short" : true,
"gpu-map" : "0:1,1:0",
"gpu-fan" : "30-100",
"gpu-engine": "750-1000",
"gpu-memdiff" : "300",
"failover-only" : true,
"temp-cutoff" : "96",
"temp-overheat" : "94",
"temp-target" : "90",
"auto-fan" : true,
"auto-gpu" : true,
"api-allow" : "W:127.0.0.1",
"api-listen" : true,
"api-port" : "4028",
"expiry" : "1",
"gpu-dyninterval" : "7",
"hotplug" : "5",
"log" : "5",
"queue" : "0",
"scan-time" : "1",
"temp-hysteresis" : "2",
"shares" : "0",
"no-submit-stale" : true,
"no-restart" : false,
"failover-switch-delay" : "30",
"show-coindiff" : true,
"remove-disabled" : true
}

rudarSRB

full member

Activity: 220

Merit: 100

Could someone share his config and speeds for 290x cards?

unityrkjs

newbie

Activity: 14

Merit: 0

Can anyone recommend me the best driver/sgminer versions to use with my 5970s?

I'm currently on sgminer 4.1 and 14.4 drivers. I've heard that the 14.6 drivers / newer sgminer versions don't affect older cards?

Ale-x

newbie

Activity: 36

Merit: 0

Quote from: platinum4 on July 09, 2014, 12:36:04 AM

Quote from: Ale-x on July 08, 2014, 04:02:24 PM

Quote from: badman74 on July 08, 2014, 03:57:58 PM

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.

Sorry for my mistake. Mix up with djm34 topic. Also I have seen than all changes by aznoboy84 have been merged to official sgminer v5.0 beta.

atomicchaos

hero member

Activity: 630

Merit: 500

Ok, follow-up to my above message. It appears that the issue is related to the on-board intel video card in the systems I am mining with. I had to completely remove the device in the control panel for SGminer 5.0 to recognize my AMD cards. I even tried -d options to make it so sgminer didn't look for it, but that didn't work either. Once I disabled it, SGminer 5 worked fine. Why wouldn't SGminer 5 look beyond the intel video card, as other version did?

Edit: The work-around is to add: --gpu-platform 1 to the start of my config line in order for it to ignore the Intel card. No idea what changed and why this is now needed when it never was previously, but I'm thrilled it is working thanks to Tex81 on Github!

atomicchaos

hero member

Activity: 630

Merit: 500

A bit perplexed... I'm a long time miner, with 50 machines, mostly Windows 7 64-bit, and all have 14.6 RC drivers loaded, and are mining fine with a version of SGminer 4.1. I'm using the nicehash compiled versions, and have not compiled myself yet.

I went to upgrade to SG5, and I cannot get it to launch at all on all the different rigs I attempted the upgrade on (5+).

The error:

Code:

C:\sgminer-5.0-pre-release-2014-07-08-win32>sgminer -n
[11:04:31] CL Platform vendor: Intel(R) Corporation
[11:04:31] CL Platform name: Intel(R) OpenCL
[11:04:31] CL Platform version: OpenCL 1.1
[11:04:31] Error -1: Getting Device IDs (num)
[b][11:04:31] clDevicesNum returned error, no GPUs usable
[11:04:31] 0 GPU devices max detected[/b]

C:\sgminer-5.0-pre-release-2014-07-08-win32>

Yet, same machine, using 4.1 version:

Code:

C:\sgminer_x11x13mod_01_07_2014>sgminer -n
[11:06:11] CL Platform 0 vendor: Intel(R) Corporation
[11:06:11] CL Platform 0 name: Intel(R) OpenCL
[11:06:11] CL Platform 0 version: OpenCL 1.1
[11:06:11] Error -1: Getting Device IDs (num)
[11:06:11] CL Platform 1 vendor: Advanced Micro Devices, Inc.

[11:06:11] CL Platform 1 name: AMD Accelerated Parallel Processing

[11:06:11] CL Platform 1 version: OpenCL 1.2 AMD-APP (1526.3)

[11:06:11] Platform 1 devices: 3
[11:06:11]      0       Tahiti
[11:06:11]      1       Tahiti
[11:06:11]      2       Tahiti
[11:06:11] Number of ADL devices: 3
[11:06:11] ATI ADL Overdrive5 API found.
[11:06:11] ATI ADL Overdrive6 API found.
[11:06:11] Found 21 ADL adapters
[11:06:11] ADL index 0, id 93288320 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] GPU 0 assigned: iAdapterIndex:0 iPresent:1 strUDID:PCI_VEN_1002&DEV_6
798&SUBSYS_3000174B&REV_00_4&10C350E0&0&00E0A iBusNumber:2 iDeviceNumber:0 iFunc
tionNumber:0 iVendorID:1002 name:AMD Radeon HD 7900 Series
[11:06:11] ADL index 1, id 93288320 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 2, id 93288320 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 3, id 93288320 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 4, id 93288320 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 5, id 93288320 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 6, id 94101760 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] GPU 1 assigned: iAdapterIndex:6 iPresent:1 strUDID:PCI_VEN_1002&DEV_6
798&SUBSYS_3000174B&REV_00_4&15001D53&0&0008A iBusNumber:1 iDeviceNumber:0 iFunc
tionNumber:0 iVendorID:1002 name:AMD Radeon HD 7900 Series
[11:06:11] ADL index 7, id 94101760 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 8, id 94101760 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 9, id 94101760 - BIOS partno.: 113-2104XTHY-OB6, version: 0
15.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 10, id 94101760 - BIOS partno.: 113-2104XTHY-OB6, version:
015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 11, id 94101760 - BIOS partno.: 113-2104XTHY-OB6, version:
015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 12, id 100127744 - BIOS partno.: 113-2104XTHY-OB6, version:
 015.025.000.099, date: 2012/09/25 23:22
[11:06:11] GPU 2 assigned: iAdapterIndex:12 iPresent:1 strUDID:PCI_VEN_1002&DEV_
6798&SUBSYS_3000174B&REV_00_4&443610C&0&00E6A iBusNumber:7 iDeviceNumber:0 iFunc
tionNumber:0 iVendorID:1002 name:AMD Radeon HD 7900 Series
[11:06:11] ADL index 13, id 100127744 - BIOS partno.: 113-2104XTHY-OB6, version:
 015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 14, id 100127744 - BIOS partno.: 113-2104XTHY-OB6, version:
 015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 15, id 100127744 - BIOS partno.: 113-2104XTHY-OB6, version:
 015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 16, id 100127744 - BIOS partno.: 113-2104XTHY-OB6, version:
 015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 17, id 100127744 - BIOS partno.: 113-2104XTHY-OB6, version:
 015.025.000.099, date: 2012/09/25 23:22
[11:06:11] ADL index 18, id 100127744 - FAILED to get BIOS info

[11:06:11] Failed to ADL_Adapter_ID_Get. Error -1
[11:06:11] ADL index 19, id 100127744 - FAILED to get BIOS info

[11:06:11] Failed to ADL_Adapter_ID_Get. Error -1
[11:06:11] ADL index 20, id 100127744 - FAILED to get BIOS info

[11:06:11] Failed to ADL_Adapter_ID_Get. Error -1
[11:06:11] GPU 0 AMD Radeon HD 7900 Series hardware monitoring enabled

[11:06:11] ADL GPU 0 is Adapter index 0 and maps to adapter id 93288320

[11:06:11] GPU 0 BIOS partno.: 113-2104XTHY-OB6, version: 015.025.000.099, date:
 2012/09/25 23:22
[11:06:11] GPU 1 AMD Radeon HD 7900 Series hardware monitoring enabled

[11:06:11] ADL GPU 1 is Adapter index 6 and maps to adapter id 94101760

[11:06:11] GPU 1 BIOS partno.: 113-2104XTHY-OB6, version: 015.025.000.099, date:
 2012/09/25 23:22
[11:06:11] GPU 2 AMD Radeon HD 7900 Series hardware monitoring enabled

[11:06:11] ADL GPU 2 is Adapter index 12 and maps to adapter id 100127744

[11:06:11] GPU 2 BIOS partno.: 113-2104XTHY-OB6, version: 015.025.000.099, date:
 2012/09/25 23:22
[11:06:11] 3 GPU devices max detected

C:\sgminer_x11x13mod_01_07_2014>

I have a bad feeling that I'm missing something very obvious, such as needing to copy files into the SGminer 5 directory from the AMD driver, but I couldn't find anything on that and haven't had to do that for other versions. Any ideas would be greatly appreciated!

nicehashdev

sr. member

Activity: 280

Merit: 250

Quote from: phzi on July 08, 2014, 10:34:12 PM

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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

This one is not problematic at all, because it would be turned on per pool - "multi-algorithm" : true and additional parameters to define supported algorithms, factors and costs.
Without this flag, miner does not subscribe to algorithm changes.

Gargo

sr. member

Activity: 585

Merit: 251

do you plan to make a build for mac os?

hotrock

newbie

Activity: 31

Merit: 0

Quote from: badman74 on July 08, 2014, 09:08:12 AM

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"
}

platinum4

sr. member

Activity: 547

Merit: 250

Quote from: Ale-x on July 08, 2014, 04:02:24 PM

Quote from: badman74 on July 08, 2014, 03:57:58 PM

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.

phzi

hero member

Activity: 700

Merit: 500

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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

langes01x

newbie

Activity: 17

Merit: 0

Quote from: badman74 on July 08, 2014, 08:08:11 PM

Quote from: langes01x on July 08, 2014, 07:59:22 PM

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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://bitcointalksearch.org/topic/ann-trademybit-algorithm-switchermonitor-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.

badman74

hero member

Activity: 658

Merit: 500

Quote from: langes01x on July 08, 2014, 07:59:22 PM

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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://bitcointalksearch.org/topic/ann-trademybit-algorithm-switchermonitor-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

newbie

Activity: 17

Merit: 0

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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://bitcointalksearch.org/topic/ann-trademybit-algorithm-switchermonitor-661827

badman74

hero member

Activity: 658

Merit: 500

Quote from: xIIImaL on July 08, 2014, 06:11:41 PM

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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

xIIImaL

legendary

Activity: 1372

Merit: 1005

Quote from: nicehashdev on July 08, 2014, 04:50:47 PM

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?

nicehashdev

sr. member

Activity: 280

Merit: 250

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.

badman74

hero member

Activity: 658

Merit: 500

Quote from: Ale-x on July 08, 2014, 04:02:24 PM

Quote from: badman74 on July 08, 2014, 03:57:58 PM

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

Ale-x

newbie

Activity: 36

Merit: 0

Quote from: badman74 on July 08, 2014, 03:57:58 PM

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

hero member

Activity: 658

Merit: 500

Quote from: ?? on ??

To developers:
Can you add X15 core from this miner: https://bitcointalksearch.org/topic/ann-sgminer-with-x11x13nist5quarkanime-kernels-compatible-146-amd-drivers-658438

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

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