Dropping in once a week and answering all unanswered questions is much better for my sanity than what I was doing before  |
|
|
|
sam: install 11.9 if your using win7 with 5xxx series cards - it does not get better than that and believe me I have done the testing
Well, I'll run it up the flagpole and see what happens. Thanks, Sam I just ran it up the flag pole. Catalyst 11.9 which has SDK 2.5 still has the 100% CPU utilization bug, which was what I kind of thought. I'll do some benchmarking to compare with what I was getting with the 11.6 and 100% CPU Utilization. Sam Win7 and WinXP (and vista lol) had different magic combinations of catalyst driver to not cause the 100% CPU bug. The 100% CPU bug is never the SDK. |
|
|
|
Not sure if this has been covered in previous posts, but MAN, 227 pages of posts to read, and searches don't turn up anything, so what the hey.
Just went from 2.2.6 to 2.3.1 and went from mid 500s on each 7970 and dropped to... 25.
At first I assumed it was to do with the new GPU interval setting it was annoying me about, but after wasting an hour playing with that to no avail I started looking for other causes. The first thing I noticed was it seemed to be taking 99% of each GPU to turn up 25 Mhash/sec. I tried phatk and went to 150 per GPU. POCLBM came in first with 552 at 12 intensity (I don't want the fans offensively loud).
So, not sure what's changed. I have not tried other kernels in the past so I can't tell if phatk has always sucked or, like Diablo, has just started sucking.
Anyway, I hope this helps anyone else with a 7970 confused by a sudden performance hit after an update!
outsidefactor
Yes the diablo kernel and 79x0 only works with the latest sdk included in driver 12.2 onwards. The earlier 2.6 sdk completely and utterly does an AMD on the kernel and produces massive fail instead of good performance. If you did not specify a kernel, by default cgminer detects what sdk you are on and should be giving you my custom poclbm kernel instead for sdk 2.6, which is what you concurred gives the best performance for a 7970  |
|
|
|
con, kano
Have you guys considered web user interface instead of console?
You are already providing a lot of the info via APIs so the switch
from console to http/html might not be that hard to do.
I'm not adding interfaces to the main cgminer code any more. As others have suggested, cgminer is for the engine side of things, not the interface side. The current interface is "enough" and the API makes it easy to add whatever interface you like. I'm not an interface designer. |
|
|
|
its not in the latest windows version, I have a linux binary from the git with it compiled in to show temps but it wasnt compiled with openGL - so I cant run the Bitforce on the same machine as GPUs which I need to do in this situation.
I'll be releasing a new version with the most minor of changes once my own mining rig is back online again. Smoked a PSU so I can't test anything yet again. |
|
|
|
ckvolias:using latest cgminer 2.3.1-2 win7 64x
after awhile I loose temps and fan speed displays both on screen and from API - a cgminer reboot fixes the issue
Windows driver ATI Display Library fsckage. I can't do anything about it. Does restarting cgminer fix it or rebooting the machine fix it? I could probably try working around the former by detecting "losing adl support" and re-initialising it. |
|
|
|
There you go: cgminer -n[2012-03-09 12:59:20] CL Platform 0 version: OpenCL 1.1 AMD-APP (898.1)
[2012-03-09 12:59:20] Platform 0 devices: 2 AMD APP 898.1 is the sdk 2.6 that is distributed with catalyst driver 12.2 on 64 bit windows so that explains your slowdown. You've already figured out a workaround. |
|
|
|
I don't know why did I miss this miner earlier, I started to use, it's very practical, now I don't have to use clocktweak and 4 phoenix miners. And, it's even giving me 20 MH/s more per card with 12.1 than phoenix with 12.1. I think this gem needs more advertising to newbies.
Thanks  Enjoy. What sort of advertising exactly could I possibly do to promote it? |
|
|
|
Hm, alright, thanks for all this information. I grabbed the old phatk110817.cl and phatk110817Cypressbitalignv2w128long4.bin from my cgminer 2.0.6, renamed them to phatk120223.cl and phatk120223Cypressv2w128l4.bin and this did restore my hashrate.  Judging from their date, they were built either under Catalyst 11.9 or 11.10. Should I expect any additional benefit from messing with my drivers as you describe? The changelog doesn't seem to mention performance improvements, "just" tons of features, bugfixes, and tweaks for newest GPUs. I'm surprised that worked, actually. At some point on 2.3.0 or 2.3.1, someone tried that and it didn't work at all. I thought ck subsequentsy posted that the old binaries weren't compatible with 2.3 and that was why he did the minor vesion change from 2.2.x. I guess somewhere along the way to 2.3.1-2 he did some major reverting. Exactly. In version 2.3.1-2 the phatk kernel is identical to the much older "good" phatk kernel that was used for months; only with the new version number. |
|
|
|
any plans to support the x6500 fpgas?
Alas no one has said they're working on support and no one has sent me one to work on to provide support. So that would be a no. |
|
|
|
I have not checked the source code, but it seems that CGMINER keeps getting work from all defined pools, regardless if it mines on them or not. I am on very slow line (GPRS), so this hogs it the line a lot. Can it be run in "no poll" mode, just being switched on failure of primary pool?
BTW, i already use --failover-only, but it has no effect on amount of work being downloaded.
This is a gross exaggeration. It asks for precisely one work item (about 100 bytes) from pools that are not in use with --failover-only when starting up to see if those pools are alive and then never communicates with them again unless your primary pool fails. If you are having network trouble then almost certainly the problem is the rate the requests are sent out rather than the total amount of requests because often multiple requests are sent at exactly the same time. Try --net-delay to cope with that. |
|
|
|
Current cgminer includes the diablo kernel so it should be identical.
Oops ! I not know this. Last version of CGMiner I check is several weeks old. Thank you ! edit: i download 2.3.1-2 and use -k diakgcn and still get better performance with Diablominer. Not sure why cgminer run slower for me. cgminer give me 40-50mhash less than Diablo on 7xxx series using 12.2pre I said it includes the diablo kernel -k diablo |
|
|
|
|
Smoking...
Looks like I picked a good time for a break from cgminer code, since I smoked my PSU the other day and my mining rig is back in the workshop. Thank goodness for warranties lol.
|
|
|
|
I really appreciate your work ckolivas!! CGMiner is AWESOME! Congrat!!! Thanks =) |
|
|
|
On a side note, on series 5xxx and 6xxx, using poclbm with any sdk above 2.1 is a performance loss, as is using phatk with anything below 2.4.
Really? Using 960/300 clocks on a 5870, -g 1 -I 8 (p2pool), tried with and without -w 256 -v 2, I get much worse performance on poclbm + 2.1 compared to phatk + 2.1. Phatk + 2.1 and phatk + 2.4 is about the same though, with 2.4 taking a very slight lead (<1%) . What would you recommend as settings for poclbm? I do remember it being better back in the day too, but haven't played much with 2.1 lately. Also, keeping memory speeds low is a must  Any recollection you have about poclbm kernel is irrelevant I'm afraid. Note that the so-called poclbm kernel in cgminer has been DRASTICALLY rewritten by myself to be optimal with sdk 2.6+. So that even though it's called poclbm it really has very little in common with the original poclbm kernel. It appears to work well with 79xx and 69xx cards and sdk 2.6+ only. |
|
|
|
I know it'll compile fine without CPU mining, but I want to do some testing with it enabled... I want to see how Anubis handles it. If it's more trouble to get it working than it's worth, I'll forget about supporting CPUs in Anubis.
CPU mining is deprecated and the code will be completely removed in the future. Do not try to port or get anything working with it. |
|
|
|
I'm trying to use the 2.1 SDK for the 5xxx and 2.6 for the 6xxx. Everything works fine using the 2.6 sdk, but it obviously isnt efficient for the 5xxx series.
Phoenix 2.0 lets me use the setup I want, but it lacks lots of features.
I also tried making cgminer use bins compiled for 2.1 while using the 2.6 sdk but it just recompiles them again. The ideal would be making --gpu-platform a per device option, something like --gpu-platform 0,0,1
You can only specify one gpu platform, but you can force it to use whatever combination by starting it a couple of times if you specify exactly the kernel, vectors and worksize. Eg start with --gpu-platform 0 (if that is sdk 2.1) --kernel phatk,diablo -v 2,1 -w 256,128 Then you will get two bins. Delete the one that you don't want running with sdk 2.1 and start again with the same commands except for --gpu-platform 1 (if that's sdk 2.6) and it will build a bin only the one that doesn't exist. |
|
|
|
Is anyone already doing ztex boards support for cgminer? I'm not sure about timeframes but I'm considering taking a stab at it seeing as I have the protocol "fresh" in my mind from the initial implementation for MPBM, but I'd hate to start it just to find out someone else is almost done with it No one has started, but see here: http://bountychest.com/bountychest/ztex-support-for-cgminer/ |
|
|
|
CGMiner is not better for 7xxx series. I test both Diablo and CGMiner on 7970 and 7950 and Diablo always faster.
Current cgminer includes the diablo kernel so it should be identical. |
|
|
|
I don't think cgminer splits 1 single getwork across cards. I am pretty sure it does 1 getwork per thread (so if you are running 8 GPU w/ 2 threads each it pulls 16 getworks). That would be one useful optimization in cgminer.
Correct. cgminer really needs a work splitting engine, badly. This is not remotely true. The only time you may have difficulty getting enough work is immediately after a longpoll, and that is precisely when cgminer splits work. Furthermore, with p2pool, your local p2pool node can generate enough work for 100s of GPUs and cgminer is not remotely a rate limiting component. |
|
|
|
|
Show Posts
