The cgminer window closes really fast on Windows, you really need to put an #ifdef win getch() at the end of execution, since piping the output doesn't work either  Anyway, by a screen grab, it shows Platform version: OpenCL 1.1 AMD-APP-SDK-v2.5 (793.1), with 1 platform device (GPU 0 ATI Radeon HD 5800 Series), and my settings for engine (970) and mem (150). The default kernel is phatk120222Cypressv2w128l4. |
|
|
|
New version: Version 2.3.0 - February 23, 2012
Thanks for the update mate, but this version doesn't compile a bitalign kernel for my cards (5850's), it's the non-bitalign kernel which is much slower (~320MH/s vs ~400MH/s). Copying over the bin from the previous version and renaming it from "phatk120213Cypressbitalignv2w256long4" to "phatk120222Cypressv2w256l4" doesn't work also (HW failures). Woah now there is nothing that should stop it compiling a bitalign kernel. It just stops CALLING it bitalign. You're not doing the SDK 2.6 dance are you? Yeah, I just read the changelog carefully. Nope, no dance, jumping back to 2.2.7 immediately gets back to ~400MH/s (I always unpack each cgminer version to a fresh folder, no leftovers from prev vers). I'll try the other kernels to see how they go. |
|
|
|
New version: Version 2.3.0 - February 23, 2012
Thanks for the update mate, but this version doesn't compile a bitalign kernel for my cards (5850's), it's the non-bitalign kernel which is much slower (~320MH/s vs ~400MH/s). Copying over the bin from the previous version and renaming it from "phatk120213Cypressbitalignv2w256long4" to "phatk120222Cypressv2w256l4" doesn't work also (HW failures). |
|
|
|
Sapphire 5830 here, using newest drivers. Cgminer works exactly the same as it did on the old driver, hash speed and all (besides the BIG WARNING suggesting I use a previous driver when you start it, anyway)
Interesting. You're finding 5830 as fast on the new SDK as the old one? What clock speeds and what hashrate? Thanks. Just downloaded and installed newest driver, and downloaded and ran newest cgminer. No compiling, since I'm on Windows. Overclocked to 950 Mhz, memory underclocked to 300 Mhz, intensity at 9. Used to average 270 Mhash, and still do. I don't know what kind of bad issues I was supposed to experience, but just letting you know there aren't any issues with mine. Did you delete the .bin inside cgminer's folder? |
|
|
|
Yes I remember this old graph. It would appear to me that cgminer's defaults of v2 w128 are the most robust for all tunings unless the user goes out of his way to tweak things manually, in which case he'll be choosing his own settings, thanks.
Yeah, exactly. Just updated my post to reflect that too.  |
|
|
|
Hmm what do the 58xx report their name as? Cypress? It sounds like cgminer should default them to worksize 256 instead of 128. Would that be a fair assessment?
Yeah, it's Cypress. The best worksize really depends on the user correctly setting the ram clock; on the default (1GHz), it's best 64 or 128 with 4 vectors. V2-W128 is the "safe" bet, since it's almost constant through ram speeds. V2-W256 is always better than V2-W128 for ram speeds <~425MHz, because even on dips (bad gpu/mem ratio) it's always faster. Gonna link again the graphic I like so much  (from phatk thread)  |
|
|
|
You can install driver & SDK independently.
So you can install driver 11.12 to get the no CPU bug and then SDK 2.1 to maximize performance of 5000 series cards. Be sure to delete any existing bins and run cgminer to compile bins with SDK 2.1.
Know how to do this on Linux ? Or shall I just stick with 11.6 and 2.1 ? Have you tested the difference between 2.4 and 2.1 on your 5970s ? Is it really that much better compared with 2.4/2.5 ? I have 5870s only. Thanks ! For my 5850's I'm getting ~400MH/s (Core ~975, Mem 150MHz) with 12.1 driver and SDK 2.5.793.1 (comes with the 11.11 driver), with phatk kernel, vectors 2, worksize 256 and intensity 9. It's much faster for me than SDK 2.1 and poclbm, especially because you can clock down ram so much and bump gpu core speed. |
|
|
|
Well the good news is that on static 2.2.5 has significantly lower rejects than any prior version I have used. 5128 shares accepted. 7 shares rejected. 0 SS (stale shares discarded locally) I second that, less 1-1.5% rejects here also. |
|
|
|
Quote from: Phateus on May 11, 2011, 05:05:55 PM
... so nothing has changed since then?
Hmmm... Tough question there mate! To the best of my knowledge, we still have a kernel made for the 2.4 SDK having the best performance today on BFI_INT cards. Hmmm... so anyone here saying that 2.5 is what everyone uses might be wrong then ... That graph was done with 2.4 I presume? It's also only done for a 5870. Obviously would be worth seeing how it differs on 2.5 and 2.6 As for 69xx and 79xx cards - the graph actually means nothing. I use 2.4, but I did use 2.6 last night for a few hours (linux of course) It's the 2 new libraries (libaticalcl.so libaticalrt.so) that replace those 2 fglrx libraries, that actually cause most of the 2.6 suckage. The 2.6 bin files are smaller and only a few % slower when run on a true 2.4 with 11.6/4, however 2.6 bins on 2.6 ... well yep - that is unbelievably bad (due to those libraries which I don't even know what the real versions of them are except the README.txt implies they are before 12.1 coz it tells you to install 12.1+ after the SDK - obviously for that reason) Yep, the graph was made for a VLIW5 card, showing that you can get good performance on low mem clocks with a big worksize vs high mem clocks and a small worksize. It suggests using lesser vectors (2) and a big worksize (256/128) for ram clocks below 800MHz (on a 5870); and more vectors (4) and small worksizes (64/128) for faster ram clocks. 69xx cards are VLIW4, so they should have a similar graph (ofc with the clock restriction on linux of abs(core-ram)<150MHz, worksize 64/128 and vectors 4/2 seems the way to go). 79xx cards are GCN which "should" adapt to VLIW4 when needed, but as it stands now, AMD wants us to reinvent the wheel again. SDK 2.5 is very very similar to SDK 2.4 in terms of compiler performance and optimizations, you can try the latest versions of each to see what gains you get (latest 2.4 is in 11.6 driver (v.2.4.650.9), latest 2.5 is in 11.11 driver (v.2.5.793.1)). Still, the phatk kernel was made for 2.4, and, luckily for us, SDK 2.5's compiler seems to like the same performance tweaks (glitches?) as 2.4. SDK 2.6 is a really different beast, the phatk kernel will most certainly need to be somewhat rewritten as some performance tweaks in it are no longer useful on the latest compiler. |
|
|
|
Quote from: Phateus on May 11, 2011, 05:05:55 PM
... so nothing has changed since then?
Hmmm... Tough question there mate! To the best of my knowledge, we still have a kernel made for the 2.4 SDK having the best performance today on BFI_INT cards. |
|
|
|
From https://bitcointalk.org/?topic=7964.0Below is a graph I came up with for my 5870 with the core clocked at 950.
V1 is the speed with no VECTORS option enabled, V2 is with using the standard "VECTORS" and V4 is using the new "VECTORS4" command line option. The numbers with them show the WORKSIZE.
The phatk kernel still has one huge advantage over poclbm, which is being able to achieve peak performance at very low mem speeds (I'm using 150MHz myself on two 5850's), and which saves alot of $$$$ on the long run and allows for better o/c on the gpu core. Until someone develops a kernel that gets same/better results with a low mem clock (big worksize), people will be reluctant to change. |
|
|
|
|
I had two rigs today with "dead" status on the gpu's (5850's on win x64), with error messages saying "Failed to reinit GPU thread" and "Thread <#> no longer exists" on 2.2.1. The strange thing is that it seems to have actually happened at the same time in both rigs (they were mining on the same pool, different workers, reported both dead for 10h). Could this be related to some pool communication bug?
|
|
|
|
So, I've just experimented with setting my maximum processor state down to 50%, and, as expected, when testing CGMINER at intensities higher than 9 (up to 12 so far), and my processor now no longer scales up to 1600 MHz in CPU-Z. My thinking is that this should allow me to squeeze a few more megahashes out of this setup without raising my overall wattage quite as much, if at all.
Your only metric should be U/W mate, MH/W may show better results with increased intensity but in most cases you will be lowering U, and only U matters. * Vbs bows to U! |
|
|
|
Maybe this a stupid question, I don't know.. I tried searching quite a bit but didn't find anything regarding special settings. I just began mining again after a long break and I made the switch from guiminer to cgminer. My computer has 2x 5850's. With guiminer and the tags -v -w256, I get about 340mh/s per card with 875/300. With cgminer, I get 305-310mh/s. I'm running Catalyst 12.1 drivers. I've played with the intensity and checked the clock speed with Afterburner, and the cards are running at about 60*C each. Is there something I should be doing differently?
You need -v 2 for low mem clocks, no if's or but's here! Please check the graph for vector and work sizes at http://bitcointalk.org/index.php?topic=7964.0For a worksize of 256 on a 5870 at 300MHz ram, the difference between v1 and v2 is ~85MH/s! |
|
|
|
thank you for posting that information, thats quite useful info, I have tested them all and the best for mining with 5xxxx in windows is 11.9 without a doubt
The 11.9 driver or the SDK that comes with it? Or both? Remember that you can use any combination of driver/sdk, for example you could install 12.1 and afterwards install SDK 2.5.732.1 (which comes packed with the 11.9 driver). |
|
|
|
This is tricky. It's very hard rolling back on such a big change. However I do think it was not the best idea to do it by default and the release has only been out one day. I suspect going to 2.2.0 will break far more people's configurations than going from 2.2.0 to 2.2.1, and then using the --gpu-reorder option will fix it (which is what I decided to call it). So, sorry, I've pretty much decided to make it default to off.
I am sorry to hear that but I understand. BTW. I have an interesting error. Because of BSOD when trying to update my drivers I reinstalled windows. I installed 11.12 but not SDK. Then installed SDK 2.5 from driver version 11.7. 2.1.12 works flawlessly. No reduction in hashrate, and no CPU bug. 2.2.0 bombs out when starting w/ error (and yes I should have quoted it exactly ) about OpenCL compiled 0 byte binary. It then loads the display w/ all cards listed as "off" and then promptly hard faults (Windows: cgminer.exe has encountered an error and will be closed). Haven't done any investigating because 2.1.12 works fine and after upgrading my entire Linux farm to BAMT (working flawless w/ cgminer now BTW) and reinstalling windows I am done with upgrades for a few days. Did you try other versions of the 2.5 SDK, aside from 11.7? Any performance differences? I just did a quick review of SDK versions from driver 11.6 to 12.1 and this is what I got: (In bold are the highest minors for each major version) SDK2.4 - SDK 2.4.595.10 11.6 - SDK 2.4.650.911.7 - SDK 2.5.684.213 SDK2.5 - SDK 2.5.684.213 11.8 - SDK 2.5.709.2 11.9 - SDK 2.5.732.1 11.10 - SDK 2.5.775.2 11.11 - SDK 2.5.793.1SDK2.6 - SDK 2.6.831.4 11.12 - SDK 2.6 (10.0.831.4) 12.1 - SDK 2.6 (10.0.851.4)I'm currently on 11.6 (driver & sdk 2.4.650.9) with 2x5850's but I think I'll try 12.1 with SDK 2.5.793.1 from the 11.11 driver to see how it goes! Cheers! |
|
|
|
You can see the differences here http://en.bitcoin.it/wiki/Mining_hardware_comparison6950 vs 6970 is worth ~30MH/s. 1GB vs 2GB is worthless for mining (but useful for gaming at 1920+ with high/ultra details) You will typically underclock your memory to ~1/3 of your card's gpu clock, when using a phatk kernel with vectors 2 and worksize 256. |
|
|
|
With pics like that in this thread I think I could happily stay a Newbie forever!
+1! xD |
|
|
|
Intel will probably only support OpenCL on integrated graphics on the upcoming Ivy Bridge architecture. Atm it only supports OpenCL in processor programming. As for quadro mining, try rpcminer-cuda, and also check http://en.bitcoin.it/wiki/Mining_hardware_comparison |
|
|
|
Electronics ftw! |
|
|
|
|
Show Posts
