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#1282913user 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.... |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
This is horrible for me. 2 5850's. [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. |
|
|
|
This is horrible for me. 2 5850's. [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. |
|
|
|
Under Ubuntu 12.04 with 12.6 drivers and sdk with the latest build of cgminer the highest you can set the thread concurrency is 2048 I'm trying to figure why I guess that is the limit in cgminer and not reaper if the kernels are similar?
four 5850s
"intensity" : "11,11,11,11",
"vectors" : "1,1,1,1",
"worksize" : "128,128,128,128",
"kernel" : "scrypt,scrypt,scrypt,scrypt",
"gpu-engine" : "0-750,0-700,0-700,0-700",
"gpu-memclock" : "1000,1000,1000,1000",
"gpu-vddc" : "1.000,0.950,0.950,0.950",
"gpu-threads" : "2",
"scrypt" : true,
this works perfectly at -I 11 ~675 kh
at -I 12 start errors miss-target
I get the same exact results under reaper
worksize 128
aggression 11
threads_per_gpu 2
sharethreads 18
lookup_gap 2
gpu_thread_concurrency 2048
aggression 11 works great no errors ~ 675 kh
aggression 12 throws errors
Ok the best results for reaper for me seems to be
worksize 128
aggression 12
threads_per_gpu 2
sharethreads 18
lookup_gap 2
gpu_thread_concurrency 5760
this works great no errors ~1030kh pool reports roughly same
I don't have any 5850s running under windows to seem if the results are the same. The same settings that work on both give nearly identical khs in both programs, but the difference is the thread concurrency maximum of 2048 in cgminer vs. 5760 in reaper? this even make sense lol?
I have a couple 5870s I'm need to test this out on but I'm thinking 4 x shader count is the optimum?
I just noticed that reaper builds the buffer at 360mb @ 5760tc 4 x 360 = 1440
cgminer's buffer build, thread concurrency, gap lookup and intensity/aggression work identically to raper so you will get identical buffer results, base performance etc with the same settings. The only thing I do differently is I check for errors when submitting the requests to opencl. You CAN override the upper limit for thread concurrency by just putting it in manually. However what likely happens is the error from the kernel running happens randomly. cgminer does not ignore the errors, whereas raper doesn't even check for them, it just keeps sending the kernel over and over ignoring whether it's working or not. Why linux has lower reported memory limits on this occasion to windows I don't know but I'm guessing it's just the driver differences. I could go in and make it ignore the results of failed kernel queueing, but that's so counter to good programming it's ridiculous. However it seems I have no choice... |
|
|
|
|
This thread is not the forum for that discussion.
|
|
|
|
Added the --shaders option now - Make the thread concurrency and lookup gap options hidden on the command line and autotune parameters with a newly parsed --shaders option. So you should only need to try --shaders and -I now. Note that any intensity above 13 is a gamble and highly dependent on hardware/software combination as to whether it's better, so -I 13 is a good start. Here's the table again: GPU Processing Elements
7750 512
7770 640
7850 1024
7870 1280
7950 1792
7970 2048
6850 960
6870 1120
6950 1408
6970 1536
6990 (6970x2)
6570 480
6670 480
6790 800
6450 160
5670 400
5750 720
5770 800
5830 1120
5850 1440
5870 1600
5970 (5870x2)
And for those who need me to spell it out, let's say you have a 5830, try this first: --shaders 1120 -I 13 |
|
|
|
I assume you read my long post about intensity, maximum buffer size, valid shares, trampled memory, thread concurrency and so on? I mined for half hour on coinotron and it returned valid shares for that half hour and coinotron reported back the same rate I was hashing at.
I readed that post but I don't undestend why: cgminer with Nvidia GF 560 OC (--scrypt --lookup-gap 2 --thread-concurrency 8192 -w 256 -g 1 -I 20) say
[2012-07-23 21:48:33] Maximum buffer memory device 0 supports says 268353536, your scrypt settings come to 536870912
but continues work
but with ATI 6930 and 6870 (--scrypt -I 10 -w 256 --lookup-gap 2 --thread-concurrency 4096 -g 2) with the same message
[2012-07-23 21:58:43] Maximum buffer memory device 0 supports says 134217728, your scrypt settings come to 268435456
says the following
[2012-07-23 21:58:43] Error -61: clCreateBuffer (padbuffer8), decrease CT or increase LG
[2012-07-23 21:58:43] Failed to init GPU thread 0, disabling device 0
1. it reports you are over the limit and the device merrily goes away trashing data 2. it reports you are over the limit and you try to set it over that limit and the device just refuses Devices respond differently to different invalid values. That's why it's a warning. |
|
|
|
I've updated the target difficulty testing in the git tree. I'm reasonably sure it wasn't working properly before.
tested on coinotron works fine now what internal difficulty on coinontron? with internal difficulty 256 dont work on intensivity >10 on old and updated git's I assume you read my long post about intensity, maximum buffer size, valid shares, trampled memory, thread concurrency and so on? I mined for half hour on coinotron and it returned valid shares for that half hour and coinotron reported back the same rate I was hashing at. coinotron difficulty is "target": "000000000000000000000000000000000000000000000000000000c0cc0c0000" default is 0xffff Edit: There is an upper limit to difficulty it will accept, but that's only relevant to solo mining magnitudes, and then it will safely submit more attempts at solving it than necessary, not the other way around, so you should never miss a share unless you screw up your tc/lg settings making for invalid work. |
|
|
|
I've updated the target difficulty testing in the git tree. I'm reasonably sure it wasn't working properly before.
tested on coinotron works fine now |
|
|
|
Has anyone gotten decent hashrates with a 5970?
The highest multiple I can set thread-concurrency is 1600. With intensity 11, I get about 130kh/s per gpu. At intensities 12 and over, the best I can get is 250kh/s from each gpu on the first card the both gpus on the second 5970 get "SICK".
How are you guys able to use such high thread-concurrency settings?
Your system ram matters as well as your OS with this. |
|
|
|
New FPGA miner here with a request for some knowledge help...My config (detailed below) is averaging 1420MHs on cgminer but deepbit is only reporting 1/2 that, ~700MHs. Any ideas on;
1. Why this is happening
2. How can I fix this - mine 1600 and have the pool report 1600?
My FPGA config is
2 * Cairnsmore 1 boards running the Icarus bitstream
Mining using cgminer 2.4.3. -phatk
My GPU miners are disabled
2 * 6770s
Thanks for your insightfulness
Cranky
Try a different pool first to see if it's deepbit at fault... and then stay away from them for your own sake as you're losing bucketloads of profit due to high fees and hoppers stealing your share of the rewards. |
|
|
|
|
I've updated the target difficulty testing in the git tree. I'm reasonably sure it wasn't working properly before.
|
|
|
|
There seems to be a problem with pools on higher share difficulty. cgminer reports the hashrate fine but what gets recognized by the pool is not. Neither invalids or stales are detected they seem just to disappear in a black hole.  I can't tell if I am the only one having this problem or if it is just cgminer - reaper doesn't really work for me, it always tries to use my cpu as well. What higher difficulty pool is that? On ozcoin difficulty is set to 20 and shares are returned fine and the pool reports the same hashrate. There is a change I do need to make to share difficulty checking as this code is as yet still incomplete so it's entirely possible you have just the right combination of difficulty and pool. |
|
|
|
|
There may be a 150 difference limit between the engine and memory clocks, just like on the 79x0 cards. Try adding --gpu-memdiff -150
to your cgminer parameters.
|
|
|
|
Okay I've thought about it some more and I think the best way forwards is to do away with the --lookup-gap and --thread-concurrency options and just get the user to input the shader count of their device and let cgminer choose. This will always set lookup gap to 2 and set the thread concurrency to the highest it can be that is a multiple of the shader count which would be much easier for users to configure. This then leaves you with the choice of gpu threads and intensity still. Otherwise there is far too much to configure, and most people won't be able to figure out how to do it. I plan to include a readme with the shader count of the various hardware like in that earlier post. What do people think of this?
Eg for a 6850 and 5770:
cgminer --shaders 960,800
Could you set those as the defaults and have the options to change them via command line or in the .conf file. Which? The shader value or the tc or the lg or some combination? I can always leave the tc and lg values configurable but all that does is lead to MORE BUG REPORTS AND CONFUSION since the shader multiple and lg2 are best. So perhaps hidden options... |
|
|
|
I'm receiving reports that cgminer doesn't work fine with Coinotron. I checked it out myself and indeed there seems to be some kind of incompatibility. I'm wondering what could be source of the issue. Does cgminer support getworks with lower than base share targets ? Does it support LP messages from different port than mining port? Yes and yes. |
|
|
|
802 Khash/s. Two 5850's. cgminer --scrypt -o http://server -u username -p password --worksize 256 --lookup-gap 2 --thread-concurrency 5600 -g 1 --intensity 18
 Image link broken. On 5850s you should try a multiple of 1440. So try 7200. |
|
|
|
|
Show Posts
