I dont mind mining on 2.0.6, i had performance simmilar to that i had with sdk 2.4 & cat 11.6. so for me gold spot - i can run oclhashcat  Edit: Last post have been edit with this: cgminer version 2.3.1 - Started: [2012-03-23 08:16:21]
-------------------------------------------------------------------------------
(5s):2137.6 (avg):2085.5 Mh/s | Q:9271 A:7769 R:10 HW:199890 E:84% U:29.50
TQ: 5 ST: 7 SS: 12 DW: 240 NB: 25 LW: 0 GF: 2 RF: 3
Connected to http://pit.deepbit.net:8332 with LP as user ummas@op.pl_GNG
Block: 0000000d14a8a028262dab4904b4ddb8... Started: [12:36:35]
-------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 62.0C 100% | 222.0/245.6Mh/s | A: 897 R:1 HW:23123 U:3.41/m I: 4
GPU 1: 51.5C 1549RPM | 304.1/303.0Mh/s | A:1091 R:1 HW:27984 U:4.14/m I: 9
GPU 2: 52.5C 1549RPM | 305.4/302.8Mh/s | A:1146 R:1 HW:29428 U:4.35/m I: 9
GPU 3: 57.5C 960RPM | 309.9/309.3Mh/s | A:1182 R:3 HW:30351 U:4.49/m I: 9
GPU 4: 60.5C | 310.9/308.2Mh/s | A:1155 R:1 HW:29722 U:4.39/m I: 9
GPU 5: 60.5C 960RPM | 307.7/308.7Mh/s | A:1146 R:2 HW:29581 U:4.35/m I: 9
GPU 6: 58.5C 960RPM | 312.4/308.4Mh/s | A:1152 R:1 HW:29701 U:4.37/m I: 9
------------------------------------------------------------------------------- Conclusion: You wont get performance loss using sdk 2.6 on 5xxx series if you use old software? Delete the .bin files from your beloved 2.0.6 installation and try again. You are NOT using the new sdk on the old installation if you still have old .bin files there. I did NOT spend 6 months and hundreds of hours coding upgrades to cgminer to make it slower. |
|
|
|
As a follow up... I decided to try a different pool aside from gpumax. I've ran stable with overclocks for about 5 hours now. Seems like some problem with cgminer and gpumax, but only on my 5970 rigs. I have the same version of cgminer running on the same linux version on my two 7970 rigs and it seems to work fine.... so it appears to be isolated to my dual gpu 5970 rigs...
Auto fan control was known broken in the last release of cgminer for 5970 and this was causing problems for people on 5970s with spontaneous restarts due to unexpected overheats. I don't think I released a newer release version with the fix for it. If you download and build the latest git tarball and build from that you can get that fix. Alternatively, disabling auto fan control should have the same effect. |
|
|
|
How do identify issues in cgminer if they don't get labeled sick or dead? Do I just need to filter the output something like -m idle to see only idle messages? Go into the GPU menu while it's running, it shows the last initialised time. If it's not about the same time that you started cgminer (listed at the top) then you know it's been re-initialised. |
|
|
|
Interesting data. Nice to see cgminer be the most popular client. Just a heads up, it's "paid" not "payed". Dunno why just about every single miner and pool seems to misspell it this spastic way. |
|
|
|
|
I'm not really back. I come once a week to answer questions. I'll be back when my hardware is back online (PSU death).
|
|
|
|
They are all 5970's (dual gpu) so those temps are okay. I was actually using Phoenix until I just recently started with cgminer and had those clocks stable on phoenix for several weeks. Not sure how often BAMT requests via API. I have BAMT running on 2 rigs with 3 7970's each with same version of cgminer and do not see the issue on there. I'll try running stock for awhile and see what happens.
58x0 are amazing hashing beasts for so many reasons, and this is one of them - they're one of the few GPUs that actually recovers after dying a "soft" death and cgminer restarts their threads a short while later. Nonetheless, you should try and find clocks that don't make the GPUs ever crash as I'm pretty certain this is your problem. |
|
|
|
Going idle can be for two reasons, as you suggested if GPUMax isn't providing you with any work, but of course the normal reason is as ckolivas said, if your setting are too high. Going idle can only be for ONE reason and that is the GPU not responding. Waiting on work from a server or network lag/outage does NOT register a mining thread as being idle. It makes no sense restarting a thread that is just waiting on work. |
|
|
|
I've been watching and I think every-time a thread is idle for 60 seconds and is restarted, it increases overall RAM usage (like the previous thread isn't getting removed from RAM). I use gpumax, which can have high idle times occasionally.... cgminer starts at 174 meg of RAM for me and currently its using 800 meg, so I think adding another stick of RAM would help, but only by delaying the time it takes for the system to run out of RAM. If I restart cgminer, then its back to normal mem usage and slowly increases again.
Then you're onto something. It is dangerous to try and delete the ram used by the old threads because that just leads to a crash, so I specifically made the threads' ram not get cleaned up - so it is expected that ram usage will go up. However, you're doing something horribly wrong if your GPUs are going idle all the time. That's supposed to ONLY happen if your GPUs wedge because you're overclocking them too much and the GPU stops responding. I highly recommend reviewing your temperatures and clock speeds. |
|
|
|
Thanks... I don't use the submit-stale option... When i start it uses about 174 meg of mem, then a couple hours later, its using closer to 400 meg this is my start script /usr/bin/screen -dmS cgminer /opt/miners/cgminer/cgminer -Q 2 --api-listen --gpu-engine 700-780,700-780,700-810,700-805,700-820,700-815 --gpu-memclock 240 --auto-gpu --auto-fan --temp-target 75 -I 10 -o http://x:8332 -u x-p x -o http://x:80 -u x -p z I'm not sure whats going on... Neither am I. But I can recommend dropping intensity since 10 does not help anything less than a 7970 and consumes more CPU and makes hashrate more unstable. 7-9 depending on card is optimal. There is a value, beyond which, the hashrate does not go up. 8 for most cards, 9 for 69x0s and 11 for 79x0s (only with export GPU_USE_SYNC_OBJECTS=1 on linux, otherwise again 9). |
|
|
|
|
Driver versions 11.7 to 11.10 on linux have high CPU usage of their own. Use either 11.6 or 11.11+ but be aware of the performance loss that comes with upgrading to a 12.x driver and the new SDK that comes with it.
|
|
|
|
I think I maybe download Polish version of cgminer. I try English version and see if faster.
Wow I didn't know I made a Polish version of cgminer... oh yeah I didn't so I'm not sure what you're talking about. |
|
|
|
I found a new version of OpenCL (AMD APP, Stream SDK, whatever they want to call it) in a leaked version of a beta driver. This driver supposedly gives Windows 8 support. Anyway, I don't give a bleep about the driver, just the OpenCL versions.
amdocl(64).dll 10.0.898.1
opencl.dll 1.2.1.0
898.1 is the sdk that's distributed from driver version 12.2 onwards, but it depends on which OS/combo etc. Having a different opencl.dll I'm not sure what it means. |
|
|
|
cgminer just stopped for me sometime last night... This was the start of a long set of logs at this time: <snip>
Mar 16 04:10:40 skynet kernel: [13242.684124] cgminer invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
Mar 16 04:10:40 skynet kernel: [13242.684129] cgminer cpuset=/ mems_allowed=0
Mar 16 04:10:40 skynet kernel: [13242.684133] Pid: 4022, comm: cgminer Tainted: P C 2.6.32-5-686 #1
Mar 16 04:10:40 skynet kernel: [13242.684135] Call Trace:
Mar 16 04:10:40 skynet kernel: [13242.684143] [<c1089a74>] ? oom_kill_process+0x60/0x201
Mar 16 04:10:40 skynet kernel: [13242.684148] [<c1089ff1>] ? __out_of_memory+0xf4/0x107
<snip> I can post all the rest if needed, but figured I would start with the above. Yep you really have run out of ram. The only time I've seen cgminer itself waste lots of ram is when people have the submit-stale feature enabled and it caches lots of old work and keeps trying to submit them for extensive outages, creating more and more network threads since there is no upper limit to how long it will hold onto this work and try repeatedly to send them. I guess I should make them all time out and give up in a future version. I don't ever suggest using the submit-stale feature and I also recommend enabling the --net-delay feature. Why does the submit stale feature exist then? Because people asked for it. Nowadays it's redundant in my opinion. |
|
|
|
Is it possible to lower the memory clocks on the 7970. Mine keep going up every time I try and reset them lower.
You can only set the 7970 memory 150 lower than the engine clock speed. That's precisely why the memdiff feature exists in cgminer, so add this to your commands: --gpu-memdiff -150 |
|
|
|
Con, Kano
Do you know if anything can be done in cgminer to prevent this crash in aticaldd.dll? I keep getting these from time to time, but it is always the same offset.
-------------------------------------------------------------------------------
Faulting module name: aticaldd.dll, version: 6.14.10.1703, time stamp: 0x4f3b188e
Exception code: 0xc0000005
Fault offset: 0x001671fa
Faulting process id: 0xb04
Faulting application start time: 0x01cd02bc779abfc0
Faulting application path: C:\Users\admin\Desktop\cgminer\cgminer.exe
Faulting module path: C:\Windows\system32\aticaldd.dll
Report Id: dea2867e-6eaf-11e1-b01a-8c89a5566fbd
-------------------------------------------------------------------------------
It's a crash in the driver or sdk code, therefore I can't do a thing about it apart from recommend a different driver version. |
|
|
|
con (or anybody with 7970),
Can you undervolt your 7970 with --gpu-vddc setting?
Thanks
Nope, they never respond. |
|
|
|
Is there a way to run the -na command when using diablo kernel?
No. That's a workaround for the diablo kernel when you're using it on a 2.6 SDK that performs terribly (like 25mhash) by default. The poclbm kernel is actually faster than diablo with -na so there is no point. |
|
|
|
Since I've had a few cgminer updates waiting for quite a while, and I've also added another update to the miner.php that some might consider useful, I'll post about it here: The latest version in my git waiting to be pulled: https://github.com/kanoi/cgminer/blob/master/miner.hThis adds 3 changes to ckolivas git: 1) Split the devs output tables if there is more than 1 device type 2) A PHP deprecated update for 1) 3) A new option at line 10 "$readonly" that when set to true will force the script to not show any buttons to change cgminer If it is set to false then it will use the cgminer API command 'privileged' to determine if it should show buttons Change 3) is useful to force it to read only with true if you want to give public access to the web page but ensure it always is readonly no matter what API access level you set in cgminer Will merge all this stuff whenever my mining rig is back online and I can actually test any code I commit. |
|
|
|
thanks for your work on this tool. it is just what i was looking for as i've developed in the bitcoin arena. having total control in one app is great.
my experience did get off to a bad start though and was about to give up. the system i decided to try it on first would not work. i tried the compiled windows version, then tried to compile myself - oh that was fun.
i just could not get it to initialize the GPU so i moved it over to another system and bam worked right off. it turns out that my first attempt was on a pc that i was messing with the Intel OpenCL SDK earlier. i removed that SDK then CGMINER worked. this may not be news or unexpected but figured i would share in case someone else is in the same boat.
thanks again ckolivas, and all contributing members. now off to research centralized monitoring........
You're most welcome. Enjoy. |
|
|
|
|
Error number -6 :
#define CL_OUT_OF_HOST_MEMORY -6
|
|
|
|
|
Show Posts
