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

[lbr]

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.

Not a BS at least for Win rigs. To reproduce - set large enough TC on a rig with a lot of GPUs, f.e. 6x290 with TC 32768 or 6x7950 with TC 40960/24000. On rigs with less than 8GB?(depends) of RAM some cards will report -4 kernel error. Stick some more ram - issue will go away. Imo that's only for scrypt/scryptn/scrypt-jane(and other memory intensive algos), cause for those algos higher TC means higher GPU RAM usage. Prly thats cause of DMA or maybe OCL or Win maps GPU RAM into system RAM or something like that..
But RAM does not affect performance, only lack of it prevents some GPUs starting up.

[1714729280]

1714729280

[1714729280]

1714729280

[1714729280]

1714729280

[BrewCrewFan]

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.

Not a BS at least for Win rigs. To reproduce - set large enough TC on a rig with a lot of GPUs, f.e. 6x290 with TC 32768 or 6x7950 with TC 40960/24000. On rigs with less than 8GB?(depends) of RAM some cards will report -4 kernel error. Stick some more ram - issue will go away. Imo that's only for scrypt/scryptn/scrypt-jane(and other memory intensive algos), cause for those algos higher TC means higher GPU RAM usage. Prly thats cause of DMA or maybe OCL or Win maps GPU RAM into system RAM or something like that..
But RAM does not affect performance, only lack of it prevents some GPUs starting up.

The key is the algos you listed... for all the rest like X11 and whatnot, TC does nothing to boost speed one way or another.... in fact I just leave that blank now or dont even put it in.

[badman74]

I'm currently getting a virtual TON of "stale shares detected, discarding."  Which variable(s) should I add or tweak to try and fix this problem?  Is this normally an Intensity issue?

Thank you ahead of time!

try to dial back you intensity till your hashrate starts to drop
sometimes if you set it too high you will get stale shares
also can be caused by latency to the pool server
if you are on a p2pool try to find one with the lowest latency

[opet]

try to dial back you intensity till your hashrate starts to drop
sometimes if you set it too high you will get stale shares

that worked! It seems that sg5 doesn't necessarily work well with all the settings I've used in the past with the older 4.0.1.

thank you!  

[cgladue]

why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?

its a Pitcairn Gigabyte R9 270 GPU

is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?

[badman74]

why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?

its a Pitcairn Gigabyte R9 270 GPU

is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?

don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think
you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=open
you will be more likely to get info on that from there
edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build

[cgladue]

why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?

its a Pitcairn Gigabyte R9 270 GPU

is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?

don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think
you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=open
you will be more likely to get info on that from there
edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build

thank you badman, i am exploring an idea, i see somehow intel openCL drivers got installed and when i doo sgminer -n it shows Inten Open CL 1.2  but on my other rig it correctly lists AMD OpenCL ...

so im blowing away the windows install and doing a fresh install and trying again... still weird why the older 4.x branch would still be able to identify my card but the 5.0 cant.

[badman74]

why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?

its a Pitcairn Gigabyte R9 270 GPU

is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?

don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think
you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=open
you will be more likely to get info on that from there
edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build

thank you badman, i am exploring an idea, i see somehow intel openCL drivers got installed and when i doo sgminer -n it shows Inten Open CL 1.2  but on my other rig it correctly lists AMD OpenCL ...

so im blowing away the windows install and doing a fresh install and trying again... still weird why the older 4.x branch would still be able to identify my card but the 5.0 cant.

v5_0 has a massive amount of changes from the original...
also if you have onboard video on your MB it might be detecting it instead of your amd cards, this has been an issue in the past
usually you can get by it by specifying "gpu-platform" : "1", in the config or --gpu-platform 1 in command line (platform 0 being the onboard video)

[phzi]

I'm currently getting a virtual TON of "stale shares detected, discarding."  Which variable(s) should I add or tweak to try and fix this problem?  Is this normally an Intensity issue?

Thank you ahead of time!

try to dial back you intensity till your hashrate starts to drop
sometimes if you set it too high you will get stale shares
also can be caused by latency to the pool server
if you are on a p2pool try to find one with the lowest latency

Expiry has a significant effect on "stale shares".  I say this in quotes, because the "stale shares detected, discarding" you were seeing are very likely not actual stale shares.  To see if the shares were really stale, use

Code:

"no-submit-stale" : false,

Increase your expiry (and potentially scan-time if you have it set low too) first.  Only decrease intensity if you're getting REAL stale shares.

I'm willing to bet that opet has expiry set to 1 or something equally silly.

[jgauthier]

Just started using this with my 5x7950 rig.  It seems whenever the pool is set to X13, one of my GPU goes sick.  X11 seemed stable for a while.
I've been running this rig in scrypt mode for months.  I have a GPU go sick about once every 2 weeks. I simply reboot.

However, mining X13 it's going dead in a couple minutes.

Any suggestions?    I've tried lowering the GPU clock for it, but that didn't make any difference.

[platinum4]

Just started using this with my 5x7950 rig.  It seems whenever the pool is set to X13, one of my GPU goes sick.  X11 seemed stable for a while.
I've been running this rig in scrypt mode for months.  I have a GPU go sick about once every 2 weeks. I simply reboot.
However, mining X13 it's going dead in a couple minutes.
Any suggestions?    I've tried lowering the GPU clock for it, but that didn't make any difference.

Nope, allow me to introduce you to hamsi, it's an unforgiving bitch.

[rldep]

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

Hi, platinum4!

My level of knowledge does not allow to understand this magic completely :-)

If I have a different cards in the rig (7950 + 7850 + 7850), how can I to calculate intencity/rawintencity?

Total number of threads will be 1792*5 + 1024*5 + 1024*5 = 8960 + 5120 + 5120 = 19200. How it should be distributed to cards?

And a second question: is the method above suitable for nist5 only, or for x11/x13/x15 too?

[Vampiro4L]

anyone got a full 280x config to share?

[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

Hi, platinum4!

My level of knowledge does not allow to understand this magic completely :-)

If I have a different cards in the rig (7950 + 7850 + 7850), how can I to calculate intencity/rawintencity?

Total number of threads will be 1792*5 + 1024*5 + 1024*5 = 8960 + 5120 + 5120 = 19200. How it should be distributed to cards?

And a second question: is the method above suitable for nist5 only, or for x11/x13/x15 too?

idk, did you just try rawintensity: 84480 and see if it increased your results?

[kingscrown]

is this the best x11 and x13 miner right now?

[rldep]

Hi, platinum4!

My level of knowledge does not allow to understand this magic completely :-)

If I have a different cards in the rig (7950 + 7850 + 7850), how can I to calculate intencity/rawintencity?

Total number of threads will be 1792*5 + 1024*5 + 1024*5 = 8960 + 5120 + 5120 = 19200. How it should be distributed to cards?

And a second question: is the method above suitable for nist5 only, or for x11/x13/x15 too?

idk, did you just try rawintensity: 84480 and see if it increased your results?

Yes. It is no significant rate changes from "intensity" : "17,20,20"...

[KiloWatts]

try this
http://www.reddit.com/r/vertcoin/comments/298gqc/greenpool_x11_amd_144146_drivers_trick_for_extra/

Wow.  Confirmed, this works.

A little shaky on x15 though...

[KiloWatts]

try this
http://www.reddit.com/r/vertcoin/comments/298gqc/greenpool_x11_amd_144146_drivers_trick_for_extra/

Wow.  Confirmed, this works.

A little shaky on x15 though...

I'm behind...  is this unnecessary now that we have 14.7

[phzi]

try this
http://www.reddit.com/r/vertcoin/comments/298gqc/greenpool_x11_amd_144146_drivers_trick_for_extra/

Wow.  Confirmed, this works.

A little shaky on x15 though...

I'm behind...  is this unnecessary now that we have 14.7

You should get the same performance by fully installing 14.6 Beta (on Linux) or 14.7 RC (on Windows).  The multi-driver setups, as far as I have seen, are only beneficial if you're still trying to scrypt mine (because scrypt performance is horrid on 14.x), but nobody with GPUs is scrypt mining anymore.

[KiloWatts]

Cool...  slowly testing.

Able to get 5.4MH stable with RI:225280 and 1025/1250, as well as the Luffa_Parallel trick.  Will nudge it up from here and see if I can get the fabled 6MH.