[ANN] Yet another GPU miner release! [YAC]

[pallas]

You're fast - I updated my analysis when I looked at the code

you forgot --enable-scrypt in your configure statement

you could just run autogen.sh too (unless you don't like things easy )

thanks!
it's working now, about the same hashrate than 3.4 but I need to tweak a little bit to see if I can get better.
the problem I'm having now is that every time I change the xintensity the corresponding gpu halts and I must reboot.
changing the legacy intensity value doesn't seem to suffer the same issue, though.

[Thirtybird]

You're fast - I updated my analysis when I looked at the code

you forgot --enable-scrypt in your configure statement

you could just run autogen.sh too (unless you don't like things easy )

thanks!
it's working now, about the same hashrate than 3.4 but I need to tweak a little bit to see if I can get better.
the problem I'm having now is that every time I change the xintensity the corresponding gpu halts and I must reboot.
changing the legacy intensity value doesn't seem to suffer the same issue, though.

Are you specifying shaders in the command line?  If so, try not doing that.  I can't think of any reason why it would do that other than your card having a shader count that is not a multiple of worksize (primarily on older drivers I believe).  For instance, on my 5770, it has 800 shaders, and at optimal it should be xI = 4 (for 3200 threads).  3200 is not a multiple of 256, so if my worksize is 256, the GPU gets disabled.  In fact, unless you set the worksize to 64 on that card, none of the xI settings work.  Any -I based intensity 8 or higher is always going to be a multiple of 256, so there's no danger there, but I think xI and rI are much more precise.

tl;dr - try worksize =64 ; also, maybe catalyst 13.12 with OpenCL 1.2 - on my machine I was able to set values for rI and xI that were not multiples of worksize after I installed that driver.  The worksize change is easier though

[pallas]

Thanks for the extensive explanation!
I mistyped, I'm using raw intensity and I'm on 13.12.
The same values, if set on the command line, work fine.
It hangs only when set live.
Currently I'm getting 3.350 Kh from a 7950 and 3.730 from an r9 290.

[Thirtybird]

Thanks for the extensive explanation!
I mistyped, I'm using raw intensity and I'm on 13.12.
The same values, if set on the command line, work fine.
It hangs only when set live.
Currently I'm getting 3.350 Kh from a 7950 and 3.730 from an r9 290.

Can you post your exact command line, and then examples of what fails?  also, how much memory your cards and system have as well as the number of shaders being reported by HWInfo or GPU-z (alternatively, you could launch yacminer with -D and -T and comb through the output, but that's messy - it will eventually get added to pretty output somewhere, sometime.)

rI has a similar limitation to xI - multiples of worksize are known to work, in-between values are questionable.  I haven't been able to nail down what is affected and what is not - there are just too many variables.  I thought it was just R7/R9 that was exempt, then thought it was driver - I know my R7 240, and R7 250 aren't limited, both on 13.12.  My 7850M (unknown driver version) is not, but my 7850 desktop on 12.10 (I think) is limited.   Also, no clue about what values can be valid under what driver version of linux...

However, in none of the cases has the computer or software hung (I compile and run for Windows only though).  For me, if it finds a value it doesn't like, and can't enqueue it onto the openCL kernel, it disables the GPU.  Setting rI back to a valid value and then re-enabling the GPU always gets it back to work for me.

[restless]

[2014-03-19 11:12:42] Started yacminer 3.5.0-yac2
 [2014-03-19 11:12:42] Probing for an alive pool
 [2014-03-19 11:12:43] Pool 0 difficulty changed to 2
 [2014-03-19 11:12:49] GPU 0: bufsize for thread @ 1664MB based on buffer-size
 [2014-03-19 11:12:49] Network diff set to 1.42K
 [2014-03-19 11:12:49] Error -4: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
 [2014-03-19 11:12:49] GPU 0 failure, disabling!
 [2014-03-19 11:12:49] Thread 0 being disabled
 [2014-03-19 11:13:13] Stratum from pool 0 detected new block

using buffer-size
yacminer --scrypt-chacha --worksize 64 --lookup-gap 8 -g 1 -R 1856 --buffer-size 1664  -o stratum+tcp://yac.m-s-t.org:3333

Using "auto mode" - gives same error and produces
scrypt-chachaCaymanglg4tc50432w64l4.bin

"old settings" work ok

[pallas]

Thanks for the extensive explanation!
I mistyped, I'm using raw intensity and I'm on 13.12.
The same values, if set on the command line, work fine.
It hangs only when set live.
Currently I'm getting 3.350 Kh from a 7950 and 3.730 from an r9 290.

Can you post your exact command line, and then examples of what fails?  also, how much memory your cards and system have as well as the number of shaders being reported by HWInfo or GPU-z (alternatively, you could launch yacminer with -D and -T and comb through the output, but that's messy - it will eventually get added to pretty output somewhere, sometime.)

rI has a similar limitation to xI - multiples of worksize are known to work, in-between values are questionable.  I haven't been able to nail down what is affected and what is not - there are just too many variables.  I thought it was just R7/R9 that was exempt, then thought it was driver - I know my R7 240, and R7 250 aren't limited, both on 13.12.  My 7850M (unknown driver version) is not, but my 7850 desktop on 12.10 (I think) is limited.   Also, no clue about what values can be valid under what driver version of linux...

However, in none of the cases has the computer or software hung (I compile and run for Windows only though).  For me, if it finds a value it doesn't like, and can't enqueue it onto the openCL kernel, it disables the GPU.  Setting rI back to a valid value and then re-enabling the GPU always gets it back to work for me.

here is the command line:
-R 6144,1856 --lookup-gap 3 --buffer-size 3264,2496 --gpu-engine 1100,1100 --gpu-memclock 1250,1250

what fails is changing -R "on the fly".
the first card is an r9 290 with 4GB and the second is a 7950 with 3GB (both failing), system has 8GB ram.
how can I see the number of shaders on linux?
when a card fails that way, if I try restarting, it goes "sick" and I need to reboot.
at this point, I believe it might be a driver issue (I'm using xedgers repository, which usually has beta drivers, but with ubuntu default ones it was much worse).

[Thirtybird]

[2014-03-19 11:12:42] Started yacminer 3.5.0-yac2
 [2014-03-19 11:12:42] Probing for an alive pool
 [2014-03-19 11:12:43] Pool 0 difficulty changed to 2
 [2014-03-19 11:12:49] GPU 0: bufsize for thread @ 1664MB based on buffer-size
 [2014-03-19 11:12:49] Network diff set to 1.42K
 [2014-03-19 11:12:49] Error -4: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
 [2014-03-19 11:12:49] GPU 0 failure, disabling!
 [2014-03-19 11:12:49] Thread 0 being disabled
 [2014-03-19 11:13:13] Stratum from pool 0 detected new block

using buffer-size
yacminer --scrypt-chacha --worksize 64 --lookup-gap 8 -g 1 -R 1856 --buffer-size 1664  -o stratum+tcp://yac.m-s-t.org:3333

Using "auto mode" - gives same error and produces
scrypt-chachaCaymanglg4tc50432w64l4.bin

"old settings" work ok

It just looks like you don't have the ability to allocate that much GPU ram - guessing only 2 GB of system memory too? 

[Thirtybird]

Thanks for the extensive explanation!
I mistyped, I'm using raw intensity and I'm on 13.12.
The same values, if set on the command line, work fine.
It hangs only when set live.
Currently I'm getting 3.350 Kh from a 7950 and 3.730 from an r9 290.

Can you post your exact command line, and then examples of what fails?  also, how much memory your cards and system have as well as the number of shaders being reported by HWInfo or GPU-z (alternatively, you could launch yacminer with -D and -T and comb through the output, but that's messy - it will eventually get added to pretty output somewhere, sometime.)

rI has a similar limitation to xI - multiples of worksize are known to work, in-between values are questionable.  I haven't been able to nail down what is affected and what is not - there are just too many variables.  I thought it was just R7/R9 that was exempt, then thought it was driver - I know my R7 240, and R7 250 aren't limited, both on 13.12.  My 7850M (unknown driver version) is not, but my 7850 desktop on 12.10 (I think) is limited.   Also, no clue about what values can be valid under what driver version of linux...

However, in none of the cases has the computer or software hung (I compile and run for Windows only though).  For me, if it finds a value it doesn't like, and can't enqueue it onto the openCL kernel, it disables the GPU.  Setting rI back to a valid value and then re-enabling the GPU always gets it back to work for me.

here is the command line:
-R 6144,1856 --lookup-gap 3 --buffer-size 3264,2496 --gpu-engine 1100,1100 --gpu-memclock 1250,1250

what fails is changing -R "on the fly".
the first card is an r9 290 with 4GB and the second is a 7950 with 3GB (both failing), system has 8GB ram.
how can I see the number of shaders on linux?
when a card fails that way, if I try restarting, it goes "sick" and I need to reboot.
at this point, I believe it might be a driver issue (I'm using xedgers repository, which usually has beta drivers, but with ubuntu default ones it was much worse).

So, if you aren't specifying --worksize, it defaults to 256, and I wouldn't use -R 1856 (try -R 6144,1792 or throw a --worksize 256,64).

I really can't answer questions about linux - you'll have to google it, or, as I said, run it with -T -D and look through the output, it does get output somewhere in there.

So, the AMD supplied linux drivers don't work for mining?  That really surprises me.  I know Ubuntu is Debian based, and a colleague is running numerous machines on debian using YACMiner, and has been quite successful, even while still learning what he was doing.

[pallas]

So, if you aren't specifying --worksize, it defaults to 256, and I wouldn't use -R 1856 (try -R 6144,1792 or throw a --worksize 256,64).

I really can't answer questions about linux - you'll have to google it, or, as I said, run it with -T -D and look through the output, it does get output somewhere in there.

So, the AMD supplied linux drivers don't work for mining?  That really surprises me.  I know Ubuntu is Debian based, and a colleague is running numerous machines on debian using YACMiner, and has been quite successful, even while still learning what he was doing.

I'm not using the amd supplied ones (which cause trouble when upgrading, I avoid them as much as I can) but the ones supplied by the standard ubuntu distribution (do not work as well as xedger's).

[Thirtybird]

So, if you aren't specifying --worksize, it defaults to 256, and I wouldn't use -R 1856 (try -R 6144,1792 or throw a --worksize 256,64).

I really can't answer questions about linux - you'll have to google it, or, as I said, run it with -T -D and look through the output, it does get output somewhere in there.

So, the AMD supplied linux drivers don't work for mining?  That really surprises me.  I know Ubuntu is Debian based, and a colleague is running numerous machines on debian using YACMiner, and has been quite successful, even while still learning what he was doing.

I'm not using the amd supplied ones (which cause trouble when upgrading, I avoid them as much as I can) but the ones supplied by the standard ubuntu distribution (do not work as well as xedger's).

Well, if you determine the drivers are the root cause, please let me know - you're in an area I really don't have the time to explore.

[restless]

[2014-03-19 11:12:42] Started yacminer 3.5.0-yac2
 [2014-03-19 11:12:42] Probing for an alive pool
 [2014-03-19 11:12:43] Pool 0 difficulty changed to 2
 [2014-03-19 11:12:49] GPU 0: bufsize for thread @ 1664MB based on buffer-size
 [2014-03-19 11:12:49] Network diff set to 1.42K
 [2014-03-19 11:12:49] Error -4: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
 [2014-03-19 11:12:49] GPU 0 failure, disabling!
 [2014-03-19 11:12:49] Thread 0 being disabled
 [2014-03-19 11:13:13] Stratum from pool 0 detected new block

using buffer-size
yacminer --scrypt-chacha --worksize 64 --lookup-gap 8 -g 1 -R 1856 --buffer-size 1664  -o stratum+tcp://yac.m-s-t.org:3333

Using "auto mode" - gives same error and produces
scrypt-chachaCaymanglg4tc50432w64l4.bin

"old settings" work ok

It just looks like you don't have the ability to allocate that much GPU ram - guessing only 2 GB of system memory too? 

Damn! I was pretty sure that my "testbed machine" is with 4GB... but after checking it has only 2Gb atm , will try after increasing

[Beave162]

[2014-03-19 11:12:42] Started yacminer 3.5.0-yac2
 [2014-03-19 11:12:42] Probing for an alive pool
 [2014-03-19 11:12:43] Pool 0 difficulty changed to 2
 [2014-03-19 11:12:49] GPU 0: bufsize for thread @ 1664MB based on buffer-size
 [2014-03-19 11:12:49] Network diff set to 1.42K
 [2014-03-19 11:12:49] Error -4: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
 [2014-03-19 11:12:49] GPU 0 failure, disabling!
 [2014-03-19 11:12:49] Thread 0 being disabled
 [2014-03-19 11:13:13] Stratum from pool 0 detected new block

using buffer-size
yacminer --scrypt-chacha --worksize 64 --lookup-gap 8 -g 1 -R 1856 --buffer-size 1664  -o stratum+tcp://yac.m-s-t.org:3333

Using "auto mode" - gives same error and produces
scrypt-chachaCaymanglg4tc50432w64l4.bin

"old settings" work ok

It just looks like you don't have the ability to allocate that much GPU ram - guessing only 2 GB of system memory too? 

Damn! I was pretty sure that my "testbed machine" is with 4GB... but after checking it has only 2Gb atm , will try after increasing

You can just google the card to get the number of shaders. Looks like 2560 for the R9 290? I'd be surprised if your setup works without the amd drivers.

Download the latest AMD Catalyst driver here:
http://support.amd.com/en-us/download

Download the latest AMD APP SDK here:
http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/

Also, you may find these guides to be useful:

http://www.cryptobadger.com/2013/04/build-a-litecoin-mining-rig-linux/
https://litecoin.info/Debian_Linux_cryptocoin_mining_rig_setup_guide


I believe when a card goes "Sick," your --gpu-engine and/or --gpu-memclock is/are too high. I don't think any other setting would cause that to happen.

[Thusith]

YAC is dead.

[Thirtybird]

YAC is dead.

Love your optimism, but I'm not sure how it's relevant to mining software that's capable of mining a dozen scrypt-chacha coins, vertcoin, and 100+ scrypt coins.

Keep contributing your expert opinion though - it's very insightful!

[canonsburg]

[ivanlabrie]

Long live yac

The original scrypt-chacha coin.

[MP5KU]

Gonna check it out..

[Thirtybird]

Nice - looks like 6 R7 240 4GB cards hashing away! 

hCan you tell us How much system ram does the machine have?  People have asked if 8 GB is enough for 6x4GB cards, and I wasn't sure if it was.

[canonsburg]

8GB RAM, Win 8.1

[ivanlabrie]

Be nice to see if nvidia could do this. Of course I can not get this to work with my cards to test :/

What cards?

I can mine yac just fine on nvidia but using cudaminer, naturally.
Nvidia cards are quite decent at it. (except for fermi or older)