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

[platinum4]

The big difference is that I only use 1 gpu, u both uses 3 or more cards. Is that causing the instability of your rigs?
Maybe try 1 gpu for test with xI=64?

Could be, is your 1 GPU a Sapphire 290X, red box or BF4 edition?

Asus dcII for the win

xI=30 =6050kh/s
xI=64 =6160kh/s

Oh that's right, how could I have forgotten, you've been bragging about that old boy for a few pages in the thread now

Those Asus cards are chop-chop my friend!

[1714720354]

1714720354

[platinum4]

Also, I don't know what it is about the most recent 7-25 builds of sgminer5, but I CANNOT seem to get a card to go SICK.

I've got uptimes of 24 hours plus, and even with CGWatcher, it has not even had to restart once.  My clocks are 1040/1325.

I don't understand it.

But, not complaining!!

[badman74]

The big difference is that I only use 1 gpu, u both uses 3 or more cards. Is that causing the instability of your rigs?
Maybe try 1 gpu for test with xI=64?

Could be, is your 1 GPU a Sapphire 290X, red box or BF4 edition?

both BF4 bought at the same time

edit: broke out the sapphire trixx and boosted my vddc by +25, now running 1050/1500 xI 64 lets see if it will stay stable
edit 2: this gives me 6.221 on the first card but the second swings between 6.220 and 5.700.....

[bullus]

The big difference is that I only use 1 gpu, u both uses 3 or more cards. Is that causing the instability of your rigs?
Maybe try 1 gpu for test with xI=64?

Could be, is your 1 GPU a Sapphire 290X, red box or BF4 edition?

both BF4 bought at the same time

edit: broke out the sapphire trixx and boosted my vddc by +25, now running 1050/1500 xI 30 lets see if it will stay stable

I rather suggest u lower ur memclocks..I was running at 1500, but after several hours it wasn't stable anymore, even at idle (booting into windows at 1060/1500)..

[badman74]

The big difference is that I only use 1 gpu, u both uses 3 or more cards. Is that causing the instability of your rigs?
Maybe try 1 gpu for test with xI=64?

Could be, is your 1 GPU a Sapphire 290X, red box or BF4 edition?

both BF4 bought at the same time

edit: broke out the sapphire trixx and boosted my vddc by +25, now running 1050/1500 xI 30 lets see if it will stay stable

I rather suggest u lower ur memclocks..I was running at 1500, but after several hours it wasn't stable anymore, even at idle (booting into windows)..

i had that problem as well untill i increased my vddc

[B.T.Coin]

About betarig. I change the no-submit-stale to false and even lowerd the intensity and use my 290x for the total of 10mh/s ,but stil fluctuate ..I did what I can so it's got to be annother issue not at my side.

The big fluctuations are caused because the pool of your renter is letting your rig hash at a very high difficulty. The average should work out OK but the graphs look shitty. Check your SGminer and you will see they are running at diff 0.5 or something in that area. Nothing you can do about it, other than asking your renter to lower the diff at the pool.

[bullus]

About betarig. I change the no-submit-stale to false and even lowerd the intensity and use my 290x for the total of 10mh/s ,but stil fluctuate ..I did what I can so it's got to be annother issue not at my side.

The big fluctuations are caused because the pool of your renter is letting your rig hash at a very high difficulty. The average should work out OK but the graphs look shitty. Check your SGminer and you will see they are running at diff 0.5 or something in that area. Nothing you can do about it, other than asking your renter to lower the diff at the pool.

Thanks for ur info.
I didn't checked the diff, will check it the next time..at tmb the diff is much lower 0.005-0.1

bullus, can you isolate the exact customized miner that built that darkcoin-mod bin that gets us 6+ ?

I can't tell if it's 6-25, -28, -39, or -30

Also, I think around that time, only 14.6RC1 was available; I'm convinced that .bin was built with different drivers.

Still copied the aznboy build bin to other miners.

No I'm with you bullus.  Hear me out though.

I have every build of aznboy84's including the very first one where he cloned the 6-25 prerelease off of nicehash and created bitblock.cl

I'm trying to isolate which version of his miners can reproduce the darkcoin-mod .bin UPON CREATION, reliably, and see if we can't track down why, with the matching source.  The problem with his github is he didn't know how to use git until about the 30th, so all of his files are LOCAL UPLOADS with no versioning.

If I'm on 14.7 and do all those mods and still have now dropped to 5.6 - 5.7, then this has to be a combination of build factors AND the drivers that were available at that time.  Since 14.6RC2 came out late during that weekend, I wasn't using it, I was using 14.6RC1; which means there may be a reason why that uploaded .bin of yours ONLY WORKS STABLY on ONE RIG.  If you put that .bin across to other cards like a Tri-X OC 290X, it wrecks them SICK in a matter of 15 minutes, or even worse -> HUNG RIG.

I want to know which version built that badass .bin, and then recreate and build bins for my 2 other rigs that contain Tri-X OC, and one that has mixed Tri-X OC and standard Sapphire 290X.

This latest build from 7-25 is rock fucking stable, but now we're barely coming up with 5.6 across 3 cards, which is a vast improvement from getting 5.4|5.4|5.0 which is why I had opened https://github.com/sgminer-dev/sgminer/issues/347

This can't be some mystery miner; one of us has to have this shit; and it's hard for you to share only your bin when it might not apply to others; I'm lucky in that I have one rig clocking in at 6.1|6.0|5.9 but 2 other rigs hodling only at 5.6|5.6|5.5 (which, is still an improvement)

Yes I've done luffa 1 and keccak unroll 6 and hamsi 7 (irrelevant to x11)

As promised..my bins are also there, so u can back them up . The date the bin was created was 16-07-2014
https://mega.co.nz/#!jIlVRDRI!5WKjkXa2n-wFX9ixhh_wlRVPQERQrmv-_-XL4heYo_c

edit
When it compile a new bin, I only have 5910kh/s with 14.7drivers..I must have use 14.6rc2 or rc1..

edit2
I finally figured it out which driver that high bin was created with ...14.6rc1 !
I already installed 14.7, so I used the ocl/opencl from rc1 and copied it to the aznboy miner and tada it was hashing >6.1mh/s.. put it on other miners en tadaa 6230kh/s

gonna upload the opencl/ocl drivers for u lazy ..

here u have it
https://mega.co.nz/#F!PdEwCb6J!Y15oi6ozLjhPnacQUeY6qw

[platinum4]

Fucking knew it; it had to be 14.6RC1

[lbr]

It spits out the error line of:

GPU xxxx failure, disabling!
Error -4 Enqueueing kernel onto command queue. <clEnqueueNDRangeKerne,>

Mind you this is just one algo, even with the X11 or NST5 algos in the miner this does not work ( well the x11 being the darkcoin-mod )

Maybe its the 1 gig ram?

Okay so I installed 2 more gig of ram... and windows...

I run the sgminer 5.0 before I install VNC and it works just great.

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.

; )

It's not about the algos it's about memory usage.
All algos use some ammount of GPU memory.
With large TC on scrypt its jsut more 'visible'.
x11 uses ~500mb of GPU RAM as far as I remember.

[BrewCrewFan]

It spits out the error line of:

GPU xxxx failure, disabling!
Error -4 Enqueueing kernel onto command queue. <clEnqueueNDRangeKerne,>

Mind you this is just one algo, even with the X11 or NST5 algos in the miner this does not work ( well the x11 being the darkcoin-mod )

Maybe its the 1 gig ram?

Okay so I installed 2 more gig of ram... and windows...

I run the sgminer 5.0 before I install VNC and it works just great.

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.

; )

It's not about the algos it's about memory usage.
All algos use some ammount of GPU memory.
With large TC on scrypt its jsut more 'visible'.
x11 uses ~500mb of GPU RAM as far as I remember.

Yeah but I think in scrypt it started with the ram in the system then dumped it onto the grafix after it ... at least that is how I understood it back then.

So in theory you still should be able to start mining with the newer algos with 512mb ram... if you can find it that is lol.

[lbr]

Yeah but I think in scrypt it started with the ram in the system then dumped it onto the grafix after it ... at least that is how I understood it back then.

Yep, something like that. But its the same process for any algo(or any OCL program).
The limitation is - OpenCL is not able to load multiple kernels with total size(or with VRAM consumption) more than available system RAM.
Proportion deffo is not 1:1, tho, if it even exists.
OpenCL does not care what kernel does. But since scrypt can use a lot of VRAM issue is more likely to appear.

"4" = CL_MEM_OBJECT_ALLOCATION_FAILURE, so that's deffo mem issue. However I was not able to pinpoint the issue, since at no point in time system memory usage spikes, my win rigs are using ~900mb of ram with miner running(~750MB win, ~200MB miner). OCL also reports available buffer size the same for rigs with 4GB/8GB RAM. GPU available VRAM obviously is the same. That's why I thought about hardware memory mappings. Tho maybe there is a bug or improper logic in cgminer ; )

And to complicate things, only some ammount of GPUs fail to init not all of them(proportionally to system RAM ammount). If I remember correctly 2 GPUs report -4 with 4GB of system RAM, scrypt and 24000tc and 1 GPU - with 6GB of system RAM.

Also there is something shady going on with maximum available buffer size in AMD OCL driver, f.e. 14.4+ apparently does not take GPU_MAX_ALLOC into account(however there is reference to it in the source code), that's why it sux for scrypt/scrypt-n/any other vram intensive algo.

So in theory you still should be able to start mining with the newer algos with 512mb ram... if you can find it that is lol.

Btw, I've checked with mining x11 with single r9 290 vram usage is 576MB, prly some ammount is being used by win.
So.. likely x11 kernel won't load on win system with 512mb of ram ; )

[phzi]

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

[platinum4]

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

Fuck, I KNEW somebody would hit us up with the Linux circlejerk.
"Why don't you just bootstrap your backports blah blah blah"

[phzi]

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

Fuck, I KNEW somebody would hit us up with the Linux circlejerk.
"Why don't you just bootstrap your backports blah blah blah"

Lol... I deserved that.  But really... if you can, try mining on linux - it's yummy. =p

[badman74]

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

Fuck, I KNEW somebody would hit us up with the Linux circlejerk.
"Why don't you just bootstrap your backports blah blah blah"

Lol... I deserved that.  But really... if you can, try mining on linux - it's yummy. =p

actually for for running miners i found pimp works fairly well
and its not too difficult to use

[lbr]

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

Fuck, I KNEW somebody would hit us up with the Linux circlejerk.
"Why don't you just bootstrap your backports blah blah blah"

It's completely understandable, that some ill-educated ppl will blame Win in the first place ; )

In this case it's either ocl or driver or cgminer or OS. Imo it's not OS, cause ppl get the same issue on BAMT https://litecointalk.org/index.php?topic=13137.msg98983#msg98983
And issue exists with any driver I've seen so far.

[bullus]

Last night I wanted to undervolt my 290x but it doesn't work..going back to 14.6rc1 and try again.

[phzi]

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

Fuck, I KNEW somebody would hit us up with the Linux circlejerk.
"Why don't you just bootstrap your backports blah blah blah"

It's completely understandable, that some ill-educated ppl will blame Win in the first place ; )

In this case it's either ocl or driver or cgminer or OS. Imo it's not OS, cause ppl get the same issue on BAMT https://litecointalk.org/index.php?topic=13137.msg98983#msg98983
And issue exists with any driver I've seen so far.

Oh god... please don't judge linux mining based on the awefully built 32bit BAMT OS running off a flash drive with no swap space...

Try a real linux install with some swap space and you'll be able to load any size opencl kernel, even with very little free RAM - this is my experience anyway.

[lbr]

Oh god... please don't judge linux mining based on the awefully built 32bit BAMT OS running off a flash drive with no swap space...

I'm not judging any OS ; )
Btw, Win runs fine from USB flash stick with no swap space.

Try a real linux install with some swap space and you'll be able to load any size opencl kernel, even with very little free RAM - this is my experience anyway.

Do you have experience with 6xGPUs, 40960 TC, scrypt on *nix?

[phzi]

Oh god... please don't judge linux mining based on the awefully built 32bit BAMT OS running off a flash drive with no swap space...

I'm not judging any OS ; )
Btw, Win runs fine from USB flash stick with no swap space.

Try a real linux install with some swap space and you'll be able to load any size opencl kernel, even with very little free RAM - this is my experience anyway.

Do you have experience with 6xGPUs, 40960 TC, scrypt on *nix?

I have run 6x R9 290s on an ASRock Pro BTC board with 2GB of RAM, and never in my testing did I hit a memory error that wasn't because of insufficient GPU memory.

(I later moved entirely to 5 card rigs, but that's quite unrelated)