Hmm well dynamic could be the culprit then indeed. And that won't really have anything to do with the 2nd thread being disabled, but perhaps because the worksize is constantly changing, it might not be offsetting the right amount and repeating work. That will need fixing...
I was noticing higher rejects with 2.2.x also, and upon searching, found this same problem with dynamic intensity. Switched to a static intensity, and the problem went away. I recommend everyone stop using dynamic till it's fixed then. |
|
|
|
|
Hmm well dynamic could be the culprit then indeed. And that won't really have anything to do with the 2nd thread being disabled, but perhaps because the worksize is constantly changing, it might not be offsetting the right amount and repeating work. That will need fixing...
|
|
|
|
Kernel is "phatk120213.cl"
I didn't specify vectors or worksize but based bin file name I am guessing this is vector 2, work size 128
"phatk120213Cypressbitalignv2w128long4.bin"
Interesting, I can't reproduce it here, but can you try starting with -k poclbm just to see if it goes away? |
|
|
|
Interesting. It is only recently that cgminer has been reporting the reject reason. This is the same GPU each time as well, which suggests more a bug in the (new) kernel code rather than from the pool. This may be related to vectors code. What kernel is in use on this and are vectors enabled? I'm guessing poclbm+2 vectors on the GPU in question.
Further question: You're not using old kernels or kernel bins just renamed are you? |
|
|
|
Has anyone else been noticing rejects due to "duplicate work"? Never seen them before and now I get a whole bunch  [2012-02-13 19:12:06] Accepted 00000000.f2ee24c9.e04e32cb GPU 0 thread 0
[2012-02-13 19:12:17] Rejected 00000000.f2ee24c9.e04e32cb GPU 0 thread 0 (Duplicate proof of work)
[2012-02-13 19:13:19] Accepted 00000000.1a280744.98022220 GPU 0 thread 0
[2012-02-13 19:13:31] Rejected 00000000.1a280744.98022220 GPU 0 thread 0 (Duplicate proof of work)
[2012-02-13 19:14:39] Accepted 00000000.f7ef4cdb.7e200dc7 GPU 0 thread 0
[2012-02-13 19:14:51] Rejected 00000000.f7ef4cdb.7e200dc7 GPU 0 thread 0 (Duplicate proof of work)
Just recently upgraded to cgminer 2.2.5 so maybe that has something to do with it It might be the pool but I am only seeing it on the rig running 2.2.5 (11.2 driver, 2.5 SDK) Normally have about 0.2% reject rate on this one rig I am hitting >5% and 98 or 99 are duplicate work errors. Interesting. It is only recently that cgminer has been reporting the reject reason. This is the same GPU each time as well, which suggests more a bug in the (new) kernel code rather than from the pool. This may be related to vectors code. What kernel is in use on this and are vectors enabled? I'm guessing poclbm+2 vectors on the GPU in question. |
|
|
|
|
cgminer mines fine on nvidia (if not the fastest)
python-pyopencl is the package you need on ubuntu
cgminer -n shows this:
[2012-02-14 13:27:59] CL Platform 0 vendor: NVIDIA Corporation
[2012-02-14 13:27:59] CL Platform 0 name: NVIDIA CUDA
[2012-02-14 13:27:59] CL Platform 0 version: OpenCL 1.1 CUDA 4.1.1
Presumably the most basic of cuda tools will work also on windows.
|
|
|
|
I have a question regarding the SDKs..
For HD5xxx users the SDK 2.1 is the fastest and I would like to use it.
Does it already contain all the functions we need for CGMINER, supporting GPUClock, Memory and Fan settings?
Is this related to SDK or driver version?
Driver has those functions. 11.6 or greater driver. SDK 2.1 should be fine. |
|
|
|
Hi Con,
in be8ad579 you fixed some missing includes in the modularized logging module. Was this required for Windows or OS/X builds?
I'm asking because I always perform full builds of all potential configuration combinations on my Linux system before I commit and never saw a problem with that missing include. Do you have some automated build scripts to check commits for regressions and QA? I'd like to ensure that my future modifications do not break anything before I issue a pull request.
Thanks,
Zefir
Windows. Manual build just before release usually  |
|
|
|
Likely has nothing to do w/ cgminer and everything to do w/ updated drivers / SDK.
I think your assumption is correct, I recall upgrading drivers/SDK/something about a month ago. So what you are saying is I should downgrade the drivers / SDK and upgrade CGminer? ckolivas: You could try including "you are running sdk 2.6 SDK which sucks dicks" as a flashing warning in the actual program :-)  How often should this flashing warning be said?  If for whatever reason you need to run sdk2.6, it sucks lesser dicks on cgminer 2.2.5. |
|
|
|
I tried upgrading from 2.0.8 to 2.2.5 but my 5s average dropped from 715 Mh/s to 600 Mh/s.
Dual 5850, one at 850, the other at 900 Mhz, memory at 300 Mhz on both. Windows 7, intensity 9.
Likely has nothing to do w/ cgminer and everything to do w/ updated drivers / SDK. To Conman: I really think including the SDK in the product title is a good idea. This scenario keeps happening over and over. a) person is running one version of cgminer and one version of SDK (say 2.1) b) they upgrade drivers but cgminer caches the bin files (SDK 2.1) so they see no change in performance. "wow 12.1 w/ SDK 2.6 works great on my 5970". c) some time later person upgrades cgminer = no bin files d) on first run bin files are created (SDK 2.6) and performance is lower. wow cgminer 2.2.x really sucks. e) to confirm they try running older version of cgminer (w/ cached SDK 2.1 bin) and performance is good again. It really complicates troubleshooting as I am sure you are aware. Would it be possible to modify bin files so they contain "metadata like SDK version at time of compilation"? Then it might be more obvious to users. cgminer 2.1.2 (w/ SDK 2.1 binaries) = 715 MH/s. cgminer 2.1.2 (w/ SDK 2.6 binaries) = 600 MH/s. cgminer 2.2.5 (w/ SDK 2.6 binaries) = 600 MH/s. Pretty obvious there where the problem lies.  Containing "metadata like SDK" is just as useful as asking for the output of -n which tells you the same thing. It won't stop people from asking and it won't make them read the readme which has lots about hashrate dropping... but then it's TOO WELL DOCUMENTED now since there's so much in the readme... Short of a loud message repeatedly saying "you are running sdk 2.6 SDK which sucks dicks" I don't think anyone is gonna get the message =( |
|
|
|
|
export DISPLAY=:0
before running, and try latest cgminer only please
|
|
|
|
The problem, I believe, is that the GCN cards are built to take large vector counts and perform a single instruction on them all at once. This is in contrast to the small vector count of VLIW which can perform large instructions quickly. So, a straight-forward 16-vector miner with simple instructions should work better than a 4-vector miner with multiple instructions. Granted, this is speculation, but from what I've seen of the hardware specs, it should hold true.
I tried it, and a 16 vector simplest possible mining kernel had performance which was, unfortunately, appalling. GCN with SDK 2.6 (the only one it works with) really does not want any vectors at all. Hmm, interesting. Did you drop the worksize in your tests as well? Absolutely. I tried all sorts of combinations. Specifically the optimum, as always, is using the card's reported max_work_size and then dividing that by the vector size. It gave the least worst performance... but we're talking 20% of the performance of running no vectors. |
|
|
|
Con, Kano,
Is there a readme somewhere on how to compile for Windows?
Actually - it's in the README (well that's what I used to do it) Someone else is trying to make a detailed one at the moment that may or may not work well. Stay tuned ... for a few more weeks maybe? Hehe ;-) I actually read over that in the README... I'll see whether I can get it build as well ;-) It's a disaster, don't waste your time. It just happened to build with certain versions of all the necessary packages when I got it working at one time in the past approximately 6 months ago, and if you get the latest versions of all the packages, it won't build. One day we'll slowly shake out that mess, but given windows users are not used to compiling their own software, it has priority zero at the moment. |
|
|
|
Since you're not doing the --donation any more is just sent you 1 BTC.
Thanks a lot! Looking at the numbers from --donation, the most I got was about 400Mhash which amounts to about .2BTC per day... not really worth the effort, plus the flaming I got for setting it up and suggesting it was on by default. Strangely, a lot of people haven't noticed nor care that p2pool has donation enabled by default. Anyway it's gone now so I don't need to stress over it. |
|
|
|
The problem, I believe, is that the GCN cards are built to take large vector counts and perform a single instruction on them all at once. This is in contrast to the small vector count of VLIW which can perform large instructions quickly. So, a straight-forward 16-vector miner with simple instructions should work better than a 4-vector miner with multiple instructions. Granted, this is speculation, but from what I've seen of the hardware specs, it should hold true.
I tried it, and a 16 vector simplest possible mining kernel had performance which was, unfortunately, appalling. GCN with SDK 2.6 (the only one it works with) really does not want any vectors at all. |
|
|
|
|
New release of cgminer 2.2.5 with fresh kernel and no more zero binary error, coping with multiple different cards at last and working well with sdk 2.6.
7970 running at 1200/1050+5% is getting 714 Mhash with -I 11 and cgminer 2.2.5 defaults.
|
|
|
|
New version: 2.2.5
Finally fixed the opencl created zero sized binary bug.
Hey, I finally have a brand spanking new set of .bin files for Windoze. Sam Excellent. I could cry seeing you say that  Especially since the kernel filenames and format has changed and it's essential that it can actually create the binaries. In fact it was this bug that made me reluctant to try and make any new kernels in the past. Just for the record, I'm now getting 714Mhash out of the 7970 clocked at 1200/1050+5% with default cgminer 2.2.5 settings. |
|
|
|
|
New version: 2.2.5
Finally fixed the opencl created zero sized binary bug.
Faster kernels for both phatk and poclbm.
Detection of sdk2.6 and using poclbm if no phatk binary available.
Full changelog:
- Make output buffer write only as per Diapolo's suggestion.
- Constify nonce in poclbm.
- Use local and group id on poclbm kernel as well.
- Microoptimise phatk kernel on return code.
- Adjust engine speed up according to performance level engine setting, not the
current engine speed.
- Try to load a binary if we've defaulted to the poclbm kernel on SDK2.6
- Use the poclbm kernel on SDK2.6 with bitalign devices only if there is no
binary available.
- Further generic microoptimisations to poclbm kernel.
- The longstanding generation of a zero sized binary appears to be due to the
OpenCL library putting the binary in a RANDOM SLOT amongst 4 possible binary
locations. Iterate over each of them after building from source till the real
binary is found and use that.
- Fix harmless warnings with -Wsign-compare to allow cgminer to build with -W.
- Fix missing field initialisers warnings.
- Put win32 equivalents of nanosleep and sleep into compat.h fixing sleep() for
adl.c.
- Restore compatibility with Jansson 1.3 and 2.0 (api.c required 2.1)
- Modularized logging, support for priority based logging
- Move CPU chipset specific optimization into device-cpu
|
|
|
|
|
Thanks very much!
I guess I could whitelist the SDK and when cgminer detects sdk 2.6 it could default to poclbm instead of always. On linux it is "OpenCL 1.1 AMD-APP (844.4)". Can anyone tell me what "cgminer -n" tells them on windows with sdk 2.6 please?
edit: I guess I can install it into my windows VM and see for myself what 32 bit sdk2.6 is
edit: I have them all now. (does anyone use osx?)
|
|
|
|
Thanks for that. The question was about the poclbm kernel being default, not the SDK being default. How does poclbm perform on 2.5 sdk for you?
thats easy POCLBM IS ABSOLUTE GARBAGE ON 2.5 ! seriously, I lose 100-150 Mhash per GPU using -k poclbm with 2.5 SDk (tested with multiple 5870 and 6990) that what I was trying to say it is premature to make poclbm the default kernel because most miners are using 2.5 the only people that want 2.6 and poclbm are people who want to do mining and gaming with the same machine Woho. That's more definitive testing. Just for my comfort, can you confirm that's the latest poclbm in 2.2.4 you're talking about? Thanks! |
|
|
|
|
Show Posts
