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

[platinum4]

idk man, if you had something working before, then try that again.

if you have it all fucked up, save your conf files, and blast it all, then recompile and try again.

Ya, this is what's messing with me...  I nuked sgminer, cloned from v5_0 git, re-compiled, and... 3.11MH/s.  Exact same config as was giving me 4.5MH/s.

Boggling my mind... nothing else has changed that I can think of.

I dropped 2 cl files in to test, and each time I launched sgminer after the hashrate dropped (as if there were memleaks or something).  Rebooting, re-compiling, hard reboot (shutdown, wait a while, start again)... still 3.11MH/s.

clone from mrdbro_testing or _develop, report back if you can

[1714728295]

1714728295

[phzi]

clone from mrdbro_testing or _develop, report back if you can

Just pulled and compiled from mrbrdo_testing and develop branches.  ~3.1MH/s from both (although they do seem to both provide a very very marginal hashrate increase, in the order of a few KH/s).

Only other thing I can think of is that my 4.5MH/s bin was generated on an older version of sgminer.  I'll start stepping back along the revisions to see if I can get the hashrate up again.


Interestingly, hashrate is dropping to ~2.8MH/s after running for a short period.  I ran into this a lot (hashrate drops until you reboot) until I found the settings above which offered 4.5MH/s stable (with an occasional card seemingly randomly deciding to run at 4.6+MH/s).  

When xI 256 and worksize 128 was giving me 4.5MH/s, changing xI or worksize slightly (up or down 1 or 2) or a lot (to say worksize 64) killed hashrate (below 4MH/s).  Now, adjusting either barely affects hashrate (remains somewhere around 3MH/s).

[platinum4]

clone from mrdbro_testing or _develop, report back if you can

Just pulled and compiled from mrbrdo_testing and develop branches.  ~3.1MH/s from both (although they do seem to both provide a very very marginal hashrate increase, in the order of a few KH/s).

Only other thing I can think of is that my 4.44MH/s bin was generated on an older version of sgminer.  I'll start stepping back along the revisions to see if I can get the hashrate up again.


Interestingly, hashrate is dropping to ~2.8MH/s after running for a short period.  I ran into this a lot (hashrate drops until you reboot) until I found the settings above which offered 4.5MH/s stable (with an occasional card seemingly randomly deciding to run at 4.6+MH/s).  

When xI 256 and worksize 128 was giving me 4.5MH/s, changing xI or worksize slightly (up or down 1 or 2) or a lot (to say worksize 64) killed hashrate (below 4MH/s).  Now, adjusting either barely affects hashrate (remains somewhere around 3MH/s).

idk, i use Windows binaries, wait til badman74 wakes up he may have some guidance for you.

[yaamp]

Spouting off some random thinking here, how about a stratum protocol amendment -- introducing an algo definition on connection and allowing algo changes to be initiated from the remote stratum.. that'd be fantabulous for us multipools who run multiple algos

That would be great to let the pool decide which algorithm is the best to mine without having to reconnect. Either using a new function like mining.set_algorithm or directly as a extra parameter to the mining.notify method.

[Bojcha]

Why i cannot put this in my conf ?

"kernel" : "bitblock,bitblock,bitblockold,bitblockold"
or
"algorithm" : "bitblock,bitblock,bitblockold,bitblockold"

it crates wrong kernel/bin. >

[platinum4]

Why i cannot put this in my conf ?

"kernel" : "bitblock,bitblock,bitblockold,bitblockold"
or
"algorithm" : "bitblock,bitblock,bitblockold,bitblockold"

it crates wrong kernel/bin. >

Not available yet.
https://github.com/sgminer-dev/sgminer/issues/311

[badman74]

clone from mrdbro_testing or _develop, report back if you can

Just pulled and compiled from mrbrdo_testing and develop branches.  ~3.1MH/s from both (although they do seem to both provide a very very marginal hashrate increase, in the order of a few KH/s).

Only other thing I can think of is that my 4.44MH/s bin was generated on an older version of sgminer.  I'll start stepping back along the revisions to see if I can get the hashrate up again.


Interestingly, hashrate is dropping to ~2.8MH/s after running for a short period.  I ran into this a lot (hashrate drops until you reboot) until I found the settings above which offered 4.5MH/s stable (with an occasional card seemingly randomly deciding to run at 4.6+MH/s).  

When xI 256 and worksize 128 was giving me 4.5MH/s, changing xI or worksize slightly (up or down 1 or 2) or a lot (to say worksize 64) killed hashrate (below 4MH/s).  Now, adjusting either barely affects hashrate (remains somewhere around 3MH/s).

idk, i use Windows binaries, wait til badman74 wakes up he may have some guidance for you.

My suggestion would be to try replacing your darkcoin-mod.cl and groestl.cl with the ones I posted last night and see if it will work
I am getting 5mh/s on my non x 290's on my pimp miner
If that doesn't work for you, try cloning aznboy84's miner from https://github.com/aznboy84/sgminer/tree/v5_0-x15 and see if it works
Edit: git clone --recursive -b v5_0-x15 git://github.com/aznboy84/sgminer/sgminer.git

[Eastwind]

ok i think i have the fix
modded the groestl.cl file a little and set #define SPH_LUFFA_PARALLEL 1, and re-enabled #include "aes_helper.cl"  in darkcoin-mod.cl
getting 6mh/s no real changes in the other algo's that i can see
darkcoin-mod.cl
https://www.dropbox.com/s/gqv2m7y62olfzbs/darkcoin-mod.cl
groestl.cl
https://www.dropbox.com/s/9ugaly2utnwbda2/groestl.cl
EDIT: there is still a little something different as i am only getting 5.96 instead of the 6.04 i was getting with the other kernel

I tried those two files.

There are 20% increase of nist5 hash with 10% increase of power consumption.
But for X11, there is only 1-3% increase of hash, with 10% increase of power consumption.

This is compared to the sgminer 4.1 by djm34.

I use 7990, 7970 and 7950.

[phzi]

<snip quotes>
My suggestion would be to try replacing your darkcoin-mod.cl and groestl.cl with the ones I posted last night and see if it will work
I am getting 5mh/s on my non x 290's on my pimp miner
If that doesn't work for you, try cloning aznboy84's miner from https://github.com/aznboy84/sgminer/tree/v5_0-x15 and see if it works
Edit: git clone --recursive -b v5_0-x15 git://github.com/aznboy84/sgminer/sgminer.git

Copying your cl files was my first step that led to this mess in the first place.

aznboy's v5_0-x15 branch is working great tho - 4.56MH/s with:

Code:

"gpu-threads" : "1",
"xintensity" : "256",
"worksize" : "128",
"lookup-gap" : "2",
"algorithm" : "darkcoin-mod",
"gpu-fan" : "60",
"gpu-memclock" : "1325",
"gpu-engine" : "980",
"gpu-powertune" : "2"

Exact same config has horrible performance on all the current sgminer-dev branches (stabilizes to 2.77MH/s).


Edit: copying the BIN file compiled by the aznboy branch to run on the latest v5_0 sgminer-dev branch produces the best result: 4.62MH/s with the above settings.

So, it's pretty clear that recent changes to sgminer-dev branches break the ability to compile a performant opencl kernel.

I'll do some compiling today to see if I can track down the culprit commits.  In the meantime, thank-you badman, at least this rig is back up to speed again.

[platinum4]

<snip quotes>
My suggestion would be to try replacing your darkcoin-mod.cl and groestl.cl with the ones I posted last night and see if it will work
I am getting 5mh/s on my non x 290's on my pimp miner
If that doesn't work for you, try cloning aznboy84's miner from https://github.com/aznboy84/sgminer/tree/v5_0-x15 and see if it works
Edit: git clone --recursive -b v5_0-x15 git://github.com/aznboy84/sgminer/sgminer.git

Copying your cl files was my first step that led to this mess in the first place.

aznboy's v5_0-x15 branch is working great tho - 4.56MH/s with:

Code:

"gpu-threads" : "1",
"xintensity" : "256",
"worksize" : "128",
"lookup-gap" : "2",
"algorithm" : "darkcoin-mod",
"gpu-fan" : "60",
"gpu-memclock" : "1325",
"gpu-engine" : "980",
"gpu-powertune" : "2"

Exact same config has horrible performance on all the current sgminer-dev branches (stabilizes to 2.77MH/s).

I think you are using xintensity without specifying shaders.

Please try with I:17 worksize 64, no fancy shit, and remove lookup-gap 2

[phzi]

I think you are using xintensity without specifying shaders.

Please try with I:17 worksize 64, no fancy shit, and remove lookup-gap 2

Awesome; found my best config yet, and v5_0 seems to be building a good kernel now!

Code:

"gpu-threads" : "1",
"intensity" : "17",
"shaders" : "2560",
"worksize" : "64",
"algorithm" : "darkcoin-mod",
"gpu-memclock" : "1325",
"gpu-engine" : "980",
"gpu-powertune" : "2",

= 4.4MH/s.

But if I use xI 256, I get 4.72MH/s!  (Awesome for these fairly gentle overclocks).


Conclusion after messing with configs: 
Setting shaders globally is insufficient right now.  When using profiles, I MUST set shaders within the profile, or performance is horrible.

[platinum4]

Here's how to nick up to 18M on nist5

Take your shaders and multiply by 5

For me was 2816x5 = 14080, this is your base thread concurrency if you specify an algo that doesn't exist, and it builds ckolivas with that TC

Next multiply this value by the total number of threads you are passing through your entire rig.

For me was 3 cards X 2 gpu-threads = 6 x 14080 = 84480 = xI: 30 as opposed to I:16=65536

Code:

{
		"name" : "nist5",
		"algorithm" : "talkcoin-mod",
		"rawintensity" : "84480",
		"worksize": "64",
		"gpu-engine": "1040",
		"gpu-memclock": "1500",
		"gpu-fan" : "80-100"
	},

Works better on a 3 card rig with xI: 30 as it's an even shader division; for some reason, I have a 2-card rig on X58 platform that runs better with I:16 (gets 18M on that setting, worse performance with xI), so this may have to do with mobo northbridges.

[platinum4]

6M on x11 on xI:48 (2816x48=131568) as opposed to I:17=131072

Code:

{
		"name" : "x11",
		"algorithm" : "darkcoin-mod",
		"xintensity" : "48",
		"worksize": "64",
		"gpu-engine": "1040",
		"gpu-memclock": "1500",
		"gpu-fan" : "80-100"
	},

6M across all cards on rawintensity: 140800 = [2816x5x10] which, I'm a dumbass, is the same as xI:50

Code:

	{
		"name" : "x11",
		"algorithm" : "darkcoin-mod",
		"rawintensity" : "140800",
		"worksize": "64",
		"gpu-engine": "1040",
		"gpu-memclock": "1500",
		"gpu-fan" : "80-100"
	},

[badman74]

looks like we need a "sph-luffa-parallel" : "1", option since this was set to 0 due to causing some cards to crash (i think this was the reason anyway...)
and maybe look at if the change in the groestl.cl file was necessary or desirable
i don't know enough about how all this works to do more than compare and copy/paste....

[platinum4]

looks like we need a "sph-luffa-parallel" : "1", option since this was set to 0 due to causing some cards to crash (i think this was the reason anyway...)
and maybe look at if the change in the groestl.cl file was necessary or desirable
i don't know enough about how all this works to do more than compare and copy/paste....

setting this to 1 on aggressive overclocks causes some hung rigs for me, and used to cause HW errors back in aznboy84's miner
bullus's bin just wrecks my drivers, I can't use it anymore it kills cards and have to reboot every 15 mins
testing once again with regular intensities; it does not like my xI's for long-term stability

only my Tri-X OC cards go sick, never my standard Sapphires... same clocks as the Tri-X OCs

[badman74]

looks like we need a "sph-luffa-parallel" : "1", option since this was set to 0 due to causing some cards to crash (i think this was the reason anyway...)
and maybe look at if the change in the groestl.cl file was necessary or desirable
i don't know enough about how all this works to do more than compare and copy/paste....

setting this to 1 on aggressive overclocks causes some hung rigs for me, and used to cause HW errors back in aznboy84's miner

testing once again with regular intensities; it does not like my xI's for long-term stability

only my Tri-X OC cards go sick, never my standard Sapphires... same clocks as the Tri-X OCs

mine have been running almost 24 hours now with no sick so long as i dont go over 1040/1500 for my sapphire 290x (6.03mh/s) and 1075/1375 on my gigabyte 290's (5.31mh/s)

[cooltobe]

is it normal for my CPU temps to rise after few minutes while using sgminer x11 .
xeon 3520
1x7950
win 8.1

[Hippie Tech]

is it normal for my CPU temps to rise after few minutes while using sgminer x11 .
xeon 3520
1x7950
win 8.1

No. I'm now seeing 10-20% cpu usage where as before it was only 2-5%.

[gringo_cz]

Hello, i have a little bit off topic questions. Sorry for it, but in this topic someone could actualy know whats going on
1) Is there a difference between amd64/i386 drivers? On Debian i386 i got this X11,13 boost with 14.6 drivers, but cant replicate it on 64bit Debian... On 32 bit PIMP,BAMT,SMOS the 14.6. driver is working also OK, i get the 3,6MHs (7950), 2,6MHs  (7870). On amd64 debian i got only 2,6MHs and 1,8Mhs - those numbers are exactly the same I got using driver 13.12. Same hashrate problem on sgminer_5 and djm34 miner - it is truly distro specific problem - I reinstalled debian64 many times, nothing i tryed helped - on debian32 i did exactly the same and i got 14.6. boost hashrate on first install.

I used exactly same "flow" for installation of 64/32bit debian, only difference is APP_SDK 64/32. Catalyst and ADL_SDK is for both arch, (using linux-amd-catalyst-14.6-beta-v1.0-may23) ... Im using this guide for installation of debian mining rig: https://bitsharestalk.org/index.php?topic=2980.0 (I had to remove all snd_* modules coz kernel error sometimes appeared)

2) Windows users can copy some 14.6 driver files into miners folder, and generated kernels (bin) and hashrate is like on 14.6. drivers even the older catalyst is installed. Is something like this possible on linux? (or I misunderstood and those driver dll files are needed for transfered bin files to work?)

Thank you very much for any hints, informations and sorry for my written english

P.S. im dwelling on 64b debian coz of RAM limitations on 32b systems... Does amount of RAM really matter? (could you spawn more gpu-threads with more RAM? currently using just 2 point something GB ram of total 2x2 RAM installed)

[phzi]

Hello, i have a little bit off topic questions. Sorry for it, but in this topic someone could actualy know whats going on
1) Is there a difference between amd64/i386 drivers? On Debian i386 i got this X11,13 boost with 14.6 drivers, but cant replicate it on 64bit Debian... On 32 bit PIMP,BAMT,SMOS the 14.6. driver is working also OK, i get the 3,6MHs (7950), 2,6MHs  (7870). On amd64 debian i got only 2,6MHs and 1,8Mhs - those numbers are exactly the same I got using driver 13.12. Same hashrate problem on sgminer_5 and djm34 miner - it is truly distro specific problem - I reinstalled debian64 many times, nothing i tryed helped - on debian32 i did exactly the same and i got 14.6. boost hashrate on first install.

I used exactly same "flow" for installation of 64/32bit debian, only difference is APP_SDK 64/32. Catalyst and ADL_SDK is for both arch, (using linux-amd-catalyst-14.6-beta-v1.0-may23) ... Im using this guide for installation of debian mining rig: https://bitsharestalk.org/index.php?topic=2980.0 (I had to remove all snd_* modules coz kernel error sometimes appeared)

2) Windows users can copy some 14.6 driver files into miners folder, and generated kernels (bin) and hashrate is like on 14.6. drivers even the older catalyst is installed. Is something like this possible on linux? (or I misunderstood and those driver dll files are needed for transfered bin files to work?)

Thank you very much for any hints, informations and sorry for my written english

P.S. im dwelling on 64b debian coz of RAM limitations on 32b systems... Does amount of RAM really matter? (could you spawn more gpu-threads with more RAM? currently using just 2 point something GB ram of total 2x2 RAM installed)

I saw huge performance boosts when moving to 14.6 on 64-bit Gentoo linux.  I am running the 3.15.0 kernel, with xorg-server 1.15.1, and ati-drivers 14.6_beta1.

RAM doesn't matter at all (at least on linux, can't say for sure with Windows).  I don't know who started that rumour, but it's bullshit.  I have run all of my rigs on 2GB of ram, and I've never seen any performance loss or inability to mine an algorithm as a result.