ATTN Litecoin GPU Miners - Scrypt support for cgminer

[pekv2]

This is horrible for me. 2 5850's.

Code:

 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  43.0C 3581RPM |  13.4/ 15.1Kh/s | A:1 R:0 HW:0 U:1.73/m I:13
 GPU 1:  46.0C 3410RPM |  50.4/ 53.6Kh/s | A:1 R:0 HW:0 U:1.73/m I:13

cgminer --scrypt -o http://site:port -u username -p password --shaders 1440 --intensity 13

vs

809 khash/s


cgminer --scrypt -o http://site:port -u username -p password --worksize 256 --lookup-gap 2 --thread-concurrency 7200 -g 1 --intensity 19

What debugging do you get running it with -D -T and then stopping it before it starts mining about size when you start it with --shaders 1440? Look for messages about buffer, lookup gap and thread concurrency.

I don't know what debugging is. I'll just stick to

ckolivas-cgminer-3a0d60c
&
cgminer --scrypt -o http:// -u  -p  --worksize 256 --lookup-gap 2 --thread-concurrency 7200 -g 1 --intensity 19

Seems to work the best.

[1714020014]

1714020014

[1714020014]

1714020014

[1714020014]

1714020014

[1714020014]

1714020014

[1714020014]

1714020014

[-ck]

This is horrible for me. 2 5850's.

Code:

 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  43.0C 3581RPM |  13.4/ 15.1Kh/s | A:1 R:0 HW:0 U:1.73/m I:13
 GPU 1:  46.0C 3410RPM |  50.4/ 53.6Kh/s | A:1 R:0 HW:0 U:1.73/m I:13

cgminer --scrypt -o http://site:port -u username -p password --shaders 1440 --intensity 13

vs

809 khash/s


cgminer --scrypt -o http://site:port -u username -p password --worksize 256 --lookup-gap 2 --thread-concurrency 7200 -g 1 --intensity 19

What debugging do you get running it with -D -T and then stopping it before it starts mining about size when you start it with --shaders 1440? Look for messages about buffer, lookup gap and thread concurrency.

I don't know what debugging is. I'll just stick to

ckolivas-cgminer-3a0d60c
&
cgminer --scrypt -o http:// -u  -p  --worksize 256 --lookup-gap 2 --thread-concurrency 7200 -g 1 --intensity 19

Seems to work the best.

Guys come on... how exactly do you expect me to move forward without your help? I already said start it with "-D -T" added to your command line.

[dellech]

After a very good experience mining BTC with cgminer on p2pool for a few months I decided to try the scrypt version on one of my machines.

my experience with a 5850 is worse than what others report:

$ cgminer -o http://my_local_p2pool:9327 -u x -p y --scrypt --shaders 1440 -I 10

is doing only about 83 Kh/s

GPU 0: 83.5 / 83.6 Mh/s | A:129  R:3  HW:0  U:27.80/m  I:10
69.5 C  F: 34% (1819 RPM)  E: 900 MHz  M: 1000 Mhz  V: 1.118V  A: 99% P: 0%
Last initialised: [2012-07-25 02:24:44]
Intensity: 10
Thread 0: 41.6 Mh/s Enabled ALIVE
Thread 1: 41.9 Mh/s Enabled ALIVE


any higher intensity does not really work. p2pool logs many messages like this:

2012-07-25 02:32:18.484973 Worker x submitted share with hash > target:
2012-07-25 02:32:18.485073     Hash:   5a417c48970ce4d87e9b4c082f855a656a90a0e8e0e50a3c62c0dc6273e03b97
2012-07-25 02:32:18.485106     Target: 6b8bd775c948180000000000000000000000000000000000000000000000


at intensity 13 the hash rate estimate of p2pool stays way below 100, but cgminer reports about 250Kh/s and no rejected shares !

GPU 0: 242.5 / 93.2 Mh/s | A:270  R:3  HW:0  U:34.04/m  I:13
70.5 C  F: 60% (3633 RPM)  E: 900 MHz  M: 1000 Mhz  V: 1.118V  A: 99% P: 0%
Last initialised: [2012-07-25 02:24:44]
Intensity: 13
Thread 0: 123.9 Mh/s Enabled ALIVE
Thread 1: 126.5 Mh/s Enabled ALIVE


my configuration:
Linux 3.1.10-1.9 x86_64 GNU/Linux
AMD SDK V2.7
fglrx driver 12.6
cgminer commit bff58c3bed937bd027e46907acd1eab7327e838b compiled from git


cgminer -D -T reports

 [2012-07-25 02:11:38] Preferred vector width reported 4
 [2012-07-25 02:11:38] Max work group size reported 256
 [2012-07-25 02:11:38] Max mem alloc size is 134217728
 [2012-07-25 02:11:38] Selecting scrypt kernel
 [2012-07-25 02:11:38] GPU 0: selecting lookup gap of 2
 [2012-07-25 02:11:38] GPU 0: selecting thread concurrency of 1440
 [2012-07-25 02:11:38] Loaded binary image scrypt120724Cypressglg2tc1440w256l8.bin
 [2012-07-25 02:11:38] Initialising kernel scrypt120724.cl with bitalign, 1 vectors and worksize 256   
 [2012-07-25 02:11:38] Creating scrypt buffer sized 134217728
 [2012-07-25 02:11:38] initCl() finished. Found Cypress


any ideas what is wrong here ?

[-ck]

my configuration:
Linux 3.1.10-1.9 x86_64 GNU/Linux
AMD SDK V2.7
fglrx driver 12.6
cgminer commit bff58c3bed937bd027e46907acd1eab7327e838b compiled from git


cgminer -D -T reports

 [2012-07-25 02:11:38] Preferred vector width reported 4
 [2012-07-25 02:11:38] Max work group size reported 256
 [2012-07-25 02:11:38] Max mem alloc size is 134217728
[2012-07-25 02:11:38] Selecting scrypt kernel
 [2012-07-25 02:11:38] GPU 0: selecting lookup gap of 2
[2012-07-25 02:11:38] GPU 0: selecting thread concurrency of 1440
[2012-07-25 02:11:38] Loaded binary image scrypt120724Cypressglg2tc1440w256l8.bin
 [2012-07-25 02:11:38] Initialising kernel scrypt120724.cl with bitalign, 1 vectors and worksize 256   
 [2012-07-25 02:11:38] Creating scrypt buffer sized 134217728
 [2012-07-25 02:11:38] initCl() finished. Found Cypress


any ideas what is wrong here ?

Unfortunately this is nowhere near as logical as btc mining. Yes for some reason on linux the amd drivers aren't allowing larger buffer sizes. How much system ram do you have? You'll see it's setting concurrency to 1440 whereas something like 7200 is best, but that will ONLY work if the driver allows you to allocate ram. As for the reported hashrate, you are right in that once you go over the optimal values, it either starts doing work that returns less shares or starts creating invalid shares.

[dellech]

system RAM is 2GB ... no other hungry processes running

I know that Linux drivers from AMD are not very good - with more than 1 card it can be a lottery to get the X server up without freezing the system ...

is there any chance another driver version has a higher memory buffer limit ?

[-ck]

system RAM is 2GB ... no other hungry processes running

I know that Linux drivers from AMD are not very good - with more than 1 card it can be a lottery to get the X server up without freezing the system ...

is there any chance another driver version has a higher memory buffer limit ?

Not sure. I'm on 12.6 which gives me a decent buffer size but then I'm also running 7970s and it does appear to be affecting 5/6x and not 7x on linux. Also sdk2.6+ is mandatory with this. You could try making it ignore the reported limits and forcing higher values manually as well by --thread-concurrency and giving it higher multiples of 1440. Try with -g 1 to begin with so that you take that out of the equation at least. There are still far too many variables to know what's best with this FPOS.

[dellech]

thanks for the hints ... I will try them ... after having some sleep and a day at work :-)

[VelvetLeaf]

There's no official binary build yet ?

[-ck]

There's no official binary build yet ?

Nope, only tittiez's builds. I'd still consider the software beta quality which is why there's no official release. None of this is making much sense and raper's performance seems almost fortuitous that it's coded without normal sanity checks so matching its performance is proving nothing short of a pain.

[Graet]

sent tittiez a small thank you for his contribution

[ThiagoCMC]

I need some help to compile CGMiner with Scrypt under Ubuntu 12.04 64 bits, 1 7970, Catalyst 12.6, AMDAPP v2.6...

What is the procedure?

Basically: git clone, checkout newscrypt, autogen, configure --enable-scrypt ... ?

Thanks!
Thiago

[dellech]

AMD Buffer size problem  (cause of my performance woes with 5850)

I found an interesting thread on AMD Developer Central today: "Large buffers"  http://devgurus.amd.com/message/1282913#1282913

user drallan presents a workaround for the low maximum allocation: allocating several memory chunks and addressing everything as one block ...


maybe the thread will go on and bring more ideas

I am going to try setting "GPU_MAX_ALLOC_PERCENT" when I get at my machine after work

[-ck]

AMD Buffer size problem  (cause of my performance woes with 5850)

I found an interesting thread on AMD Developer Central today: "Large buffers"  http://devgurus.amd.com/message/1282913#1282913

user drallan presents a workaround for the low maximum allocation: allocating several memory chunks and addressing everything as one block ...


maybe the thread will go on and bring more ideas

I am going to try setting "GPU_MAX_ALLOC_PERCENT" when I get at my machine after work

Most interesting....

[-ck]

AMD Buffer size problem  (cause of my performance woes with 5850)

I found an interesting thread on AMD Developer Central today: "Large buffers"  http://devgurus.amd.com/message/1282913#1282913

user drallan presents a workaround for the low maximum allocation: allocating several memory chunks and addressing everything as one block ...


maybe the thread will go on and bring more ideas

I am going to try setting "GPU_MAX_ALLOC_PERCENT" when I get at my machine after work

Most interesting....

Woah it works!... for linux people, just start with
export GPU_MAX_ALLOC_PERCENT=40

or other values and try again I was able to allocate whopping buffers on my 7970....

[rav3n_pl]

Can someone compile it w/CPU ?
My "work" machine I can use gets 15kh from gpu and close to another 15kh from 3 threads on CPU (using reaper+minerd).
cgminer uses alot less memory than reaper

[-ck]

Okay I've experimented some more and
export GPU_MAX_ALLOC_PERCENT=100
will obviously cause a problem, but it gives me massive scope for trying different tc, etc since I can theoretically allocate 3GB on a 7970. However the code would try to allocate the largest buffer by default which is not right with this value now, so I've committed a change (to git) that will find the nearest buffer size that is a power of 2 between the thread concurrency buffer requirement and the maximum allocable ram.

Playing some more with my 7970s I found the values it was already running were pretty close to optimal. The only thing I found useful with the increased ram available was that I am now able to increase threads a little more (5 instead of 4) which afforded another 5kh per device.

The good news is that this should be what the 5x/6x miners were looking for on linux. I suggest you download the latest changes from git and start experimenting with TCs that are a multiple of your shader count after setting the above variable to 100%.

[Tittiez]

Okay I've experimented some more and
export GPU_MAX_ALLOC_PERCENT=100
will obviously cause a problem, but it gives me massive scope for trying different tc, etc since I can theoretically allocate 3GB on a 7970. However the code would try to allocate the largest buffer by default which is not right with this value now, so I've committed a change (to git) that will find the nearest buffer size that is a power of 2 between the thread concurrency buffer requirement and the maximum allocable ram.

Playing some more with my 7970s I found the values it was already running were pretty close to optimal. The only thing I found useful with the increased ram available was that I am now able to increase threads a little more (5 instead of 4) which afforded another 5kh per device.

The good news is that this should be what the 5x/6x miners were looking for on linux. I suggest you download the latest changes from git and start experimenting with TCs that are a multiple of your shader count after setting the above variable to 100%.

Should I rebuild it now or are you going to commit more right now?

[-ck]

Build away.

I don't have any other immediate change planned. I'm not sure this will ever be a simple start it and it will find optimum settings. Scrypt on GPU is half programming, half witchcraft.

[Tittiez]

win32: http://www.mediafire.com/?enp2jnw2et4ie3p
+ Commits ea10b08 & 5148502

 

[dellech]

Okay I've experimented some more and
export GPU_MAX_ALLOC_PERCENT=100
will obviously cause a problem, but it gives me massive scope for trying different tc, etc since I can theoretically allocate 3GB on a 7970. However the code would try to allocate the largest buffer by default which is not right with this value now, so I've committed a change (to git) that will find the nearest buffer size that is a power of 2 between the thread concurrency buffer requirement and the maximum allocable ram.

Playing some more with my 7970s I found the values it was already running were pretty close to optimal. The only thing I found useful with the increased ram available was that I am now able to increase threads a little more (5 instead of 4) which afforded another 5kh per device.

The good news is that this should be what the 5x/6x miners were looking for on linux. I suggest you download the latest changes from git and start experimenting with TCs that are a multiple of your shader count after setting the above variable to 100%.

Wow - I am leaving work and was planning to try the parameter at home - and now I see that you already did my homework :-)


many thanks !!!