Hi, I just wanted to report that with the latest git My Hashrate drops from 190 MH/s to 170 MH/s. When I check the git repository out from the date 3/3/2012 then I get again 190MH/s.
I use the default kernel and I use ubuntu 11.10 with a HD5770. What changes made the hashrate drop so drastically?
I'm experimenting. It looks like you are on SDK 2.6. Try -k diablo and see what that does to your hashrate. And then try -k poclbm. |
|
|
|
|
Lots of stream processors for mining - right idea. Lousy integer performance: Fail.
Darn and I hate ATI so much.
|
|
|
|
|
Be aware that the prime determinant of performance is the AMD APP SDK you have installed and not the driver. However when you install a driver, it usually installs an SDK at the same time unless you choose a custom install and choose not to install it. When running cgminer, the other thing is that the performance is linked to the SDK that was installed the very first time you ran cgminer as it generates .bin files that are used from then on. So if you change your SDK, you must delete the .bin files generated by cgminer to get the changed performance.
|
|
|
|
On Windows, can I use a driver version which does NOT officialy support the 7970 as long as the newest SDK is installed?
no |
|
|
|
|
I'm back online. So time to start rounding up a few pending patches and bring out a new version in the next few days.
Interestingly, I finally got to try the official 12.2 driver for linux with my 7970 and it actually makes my GPU go sick and then dead at clocks that were fine with that early GCN only driver release amd-driver-installer-8.921-x86.x86_64.run . Downgrading to that fixed the problem. Worth considering a different driver version if you're having apparent hardware instability it seems.
|
|
|
|
do you need to delete bins when switching kernels in the config file?
No. Only if you are changing SDKs and want the newly installed SDK to build the kernel. |
|
|
|
Using intensity of 13 for the 7970 and 9 for the 6950 the machine becomes very irresponsible (exported GPU_USE_SYNC_OBJECTS=1, CPU is used 50% by compiz/X and 50% by cgminer). Not sure if CPU is the bottleneck now or if there are better settings for this setup  Don't go over 11 for 7970 on linux with sync objects or 9 on windows. |
|
|
|
The only one that helped was setting GPU threads to 1. Since I have done that, I have been stable for 8 hours with no restarts, so looks promising, but we'll see if it lasts... Any disadvantage to only running 1 thread per gpu? Hash rates seem about the same. That's interesting and unusual. I have certainly heard that particular driver and sdk combos would make 5970s unstable, but I don't know if that's true. If you're getting good hashrates it doesn't matter what settings you particularly chose now does it? I found 2 threads simply smoothed out the hashrate rather than improved it substantially, but some cards had slightly higher hashrates with 2 instead of 1. |
|
|
|
Cgminer 2.0.6 - 2.3.1 runs slow, dunno why - yet  10 posts from people have tried to tell you why so far.  |
|
|
|
#define ADL_ERR_DISABLED_ADAPTER -10
Looks like something is wrong in your setup. I assume you have X running and have permission to access X with the user you're logged in as?
Nice to see you're back, Con. X is up and running at the machine with me being logged in. Before I started to test the 7970 it perfectly worked with 3*6950. Confused... zefir@miner0:~/work/cgminer$ aticonfig --list-adapters
* 0. 07:00.0 AMD Radeon HD 7900 Series
1. 04:00.0 AMD Radeon HD 7900 Series
* - Default adapter
Any way to explicitly enable the second card if it really is disabled? When you started experimenting with 7970 you wrote that it helped to swap PCIe-slots, right? I'll try that and test it with 7970+6950 meanwhile. Thanks. I'm not back. I drop in once a week to answer the accumulated questions. I'll be back once my PSU is replaced. Developing without hardware that can run the software ends up leading to issues which leads to more unnecessary development which leads to more issues and so on... I had to put the 7970 into the first slot and the 6970s in the rest of the slots. It doesn't even look like your first card is even working properly since it is detecting only one device and then saying it can't use it. Your xorg setup looks fine. The usual thing to point the finger at after doing the obvious things is the ati driver/sdk combo. Try an older one or different one. The first driver they released for the 7970 I hear is the least worst one so far, so try downgrading to that. |
|
|
|
Folks, anything that needs to be considered for running cgminer on a multi-7970 setup? I set up a rig with a XFX-7970 Black Edition and a Gigabyte GV7970-OC, installed the latest APP and drivers, but can't get them running. zefir@miner0:~/work/cgminer$ export DISPLAY=:0 && ./cgminer -n -D
[2012-03-23 23:32:22] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-03-23 23:32:22] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-03-23 23:32:22] CL Platform 0 version: OpenCL 1.2 AMD-APP (923.1)
[2012-03-23 23:32:22] Platform 0 devices: 1
[2012-03-23 23:32:22] Failed to ADL_Adapter_ID_Get. Error -10
[2012-03-23 23:32:22] Failed to ADL_Adapter_ID_Get. Error -10
[2012-03-23 23:32:22] GPU 0 AMD Radeon HD 7900 Series hardware monitoring enabled
[2012-03-23 23:32:22] 1 GPU devices max detected I read people driving up to 4*7970 setups with cgminer under Linux, so I must miss something really obvious Any ideas? #define ADL_ERR_DISABLED_ADAPTER -10 Looks like something is wrong in your setup. I assume you have X running and have permission to access X with the user you're logged in as? |
|
|
|
So was testing over heat protection on my water cooled farm ...
cgminer version 2.3.1 - Started: [2012-03-23 15:45:20]
--------------------------------------------------------------------------------
(10s):2507.1 (avg):2573.0 Mh/s | Q:3286 A:1932 R:26 HW:0 E:59% U:35.30/m
TQ: 8 ST: 9 SS: 21 DW: 1506 NB: 7 LW: 3806 GF: 0 RF: 0
Connected to http://192.168.0.189:9332 with LP as user user/1000+1
Block: 000006e1c8f6fcf1aa1e1f358d344831... Started: [16:36:55]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 58.0C 960RPM | 324.2/335.3Mh/s | A:263 R:2 HW:0 U: 4.81/m I: 8
GPU 1: 59.0C 960RPM | REST /333.1Mh/s | A:261 R:6 HW:0 U: 4.77/m I: 8
GPU 2: 60.0C 960RPM | REST /225.7Mh/s | A:188 R:4 HW:0 U: 3.44/m I: 8
GPU 3: 60.5C 960RPM | REST /328.6Mh/s | A:246 R:5 HW:0 U: 4.49/m I: 8
GPU 4: 56.0C 960RPM | 324.5/358.6Mh/s | A:217 R:3 HW:0 U: 3.96/m I: 8
GPU 5: 59.5C 960RPM | REST /330.7Mh/s | A:239 R:0 HW:0 U: 4.37/m I: 8
GPU 6: 59.5C 960RPM | REST /330.4Mh/s | A:261 R:3 HW:0 U: 4.77/m I: 8
GPU 7: 58.5C 960RPM | REST /333.3Mh/s | A:262 R:3 HW:0 U: 4.79/m I: 8
Notice the 10s avg hashrate is inaccurate. Looks like when card goes idle due to overheat its last hashrate is still added to global average. It's just the asynchronous way the counter is updated. It starts reading wrong when the card is not reporting in and only works after it knows what's going on with the unresponsive card. I can make the counter more accurate but I'm loathe to making it use more CPU time. I went out of my way to make all these counters use hardly any CPU, and since multiple threads report to the global counter there is a lot of locking required to update the counter which is a potential source of overhead if you update it often. |
|
|
|
I've put a few commits in my git: https://github.com/kanoi/cgminer/that add a simple device history that is accessible via the new API command 'notify' Compiling my git reports itself as 2.3.1k You can see it with echo -n notify | nc 127.0.0.1 4028 ; echo The base code change adds a few extra fields and counters to the device structure (that are all reported by the API) Including: per device: last well time, last not well time, last not well reason, and counters for each of the reasons meaning how many times they have happened (e.g. Device Over Heat count, Device Thermal Cutoff count among others) I ran for 30 minutes at stock gpu clocks and several gpu threads restarted... again on the GPU Managment screen, it only showed that gpu 5 had been re-initialized according to the times tamps. Seems to be random cards.... first time i looked it was 2,3 and 5. I restarted and this time its 1,3,4, and 5... after 30 minutes at stock gpu clock. Here's the output of your command: STATUS=S,When=1332519326,Code=60,Msg=Notify,Description=cgminer 2.3.1k|NOTIFY=0,Name=GPU,ID=0,Last Well=1332519326,Last Not Well=0,Reason Not Well=None,Thread Fail Init=0,Thread Zero Hash=0,Thread Fail Queue=0,Dev Sick Idle 60s=0,Dev Dead Idle 600s=0,Dev Nostart=0,Dev Over Heat=0,Dev Thermal Cutoff=0|NOTIFY=1,Name=GPU,ID=1,Last Well=1332519326,Last Not Well=1332518925,Reason Not Well=Device idle for 60s,Thread Fail Init=0,Thread Zero Hash=0,Thread Fail Queue=0,Dev Sick Idle 60s=1,Dev Dead Idle 600s=0,Dev Nostart=0,Dev Over Heat=0,Dev Thermal Cutoff=0|NOTIFY=2,Name=GPU,ID=2,Last Well=1332519326,Last Not Well=0,Reason Not Well=None,Thread Fail Init=0,Thread Zero Hash=0,Thread Fail Queue=0,Dev Sick Idle 60s=0,Dev Dead Idle 600s=0,Dev Nostart=0,Dev Over Heat=0,Dev Thermal Cutoff=0|NOTIFY=3,Name=GPU,ID=3,Last Well=1332519325,Last Not Well=1332518862,Reason Not Well=Device idle for 60s,Thread Fail Init=0,Thread Zero Hash=0,Thread Fail Queue=0,Dev Sick Idle 60s=1,Dev Dead Idle 600s=0,Dev Nostart=0,Dev Over Heat=0,Dev Thermal Cutoff=0|NOTIFY=4,Name=GPU,ID=4,Last Well=1332519326,Last Not Well=1332517934,Reason Not Well=Device idle for 60s,Thread Fail Init=0,Thread Zero Hash=0,Thread Fail Queue=0,Dev Sick Idle 60s=2,Dev Dead Idle 600s=0,Dev Nostart=0,Dev Over Heat=0,Dev Thermal Cutoff=0|NOTIFY=5,Name=GPU,ID=5,Last Well=1332519326,Last Not Well=1332518716,Reason Not Well=Device idle for 60s,Thread Fail Init=0,Thread Zero Hash=0,Thread Fail Queue=0,Dev Sick Idle 60s=1,Dev Dead Idle 600s=0,Dev Nostart=0,Dev Over Heat=0,Dev Thermal Cutoff=0|
I'll try running on a different pool other than gpumax again see what happens. Did you read my advice about fan control and 5970s? |
|
|
|
Isn't there a way in OpenCL to check what version of the SDK the .bin was compiled in and re-compile only if the SDK did not match currently installed? Or, encode the version into .bin filename. Sorry for nitpicking  . Doing this would circumvent the cheating people can do by using a bin from an older sdk like 2.1 with a newer installed sdk indefinitely to get the performance from the older sdk while installing newer drivers without losing their hashrate. |
|
|
|
I noticed two small issues this morning, one which would be easy to reproduce but doesn't necessarily need fixed, the other which would be difficult to reproduce but should theoretically be fixed for best performance (assuming my observation was correct). Issue one is related to the use of system time, my mining machine was about 6 minutes slow, over the course of a couple weeks with ntp not running. I started ntp and when the time changed, cgminer immediately reported "pool not providing work enough" and subsequently switched pools. This probably wouldn't have happened if ntp was running all along, which is why I think it is a minor issue, but it makes me wonder if DST causes dropped work and pool failovers when they shouldn't exist. Since that would only be a problem once or twice a year, I still don't know if this would be worth fixing, because I'm guessing it would be difficult to fix (would require a unique time source or some sort of interrupt to deal with known time changes on the existing time source [assuming either one of those is even possible]). Issue two is related to submission of stale shares. Note that I did not have --submit-stale on the command line in this case, but I have previously seen cgminer submit detected stales to the pool because it was instructed to (pool is eligius). This morning, I just happened to look at my miner while this was still on the screen: [2012-03-23 08:22:53] LONGPOLL requested work restart, waiting on fresh work
[2012-03-23 08:22:57] Accepted 00000000.949b59d0.7ecd59ab GPU 0 thread 1 pool 0
[2012-03-23 08:23:03] Accepted 00000000.58e019ff.7a3bc657 GPU 0 thread 1 pool 0
[2012-03-23 08:23:05] Pool 0 communication failure, caching submissions
[2012-03-23 08:23:05] Stale share detected, discarding
[2012-03-23 08:23:07] Pool 0 communication resumed, submitting work
[2012-03-23 08:23:07] Accepted 00000000.ade4193a.07083649 GPU 0 thread 0 pool 0 I had recently restarted cgminer, so I can't be 100% certain cgminer was again instructed to submit stales, but assuming it was, I believe the discarded share above would indicate a bug in stale share handling in this scenario. I also believe it would have been accepted based on the length of time between the last longpoll and this event and the fact that other shares were accepted before and after this one with no other new block event shown. I can't do much about either of these, but I thought I would bring them up in case anyone who could might want to. 1: It will just switch back a minute later so it's not a big problem. 2: Pools selectively send the submitold flag depending on their work. It is not always on for all work from the pool. The reason for that has to do with merged mining. If there is a real block change for both namecoin and bitcoin (and anywhere else that eligius is sending your shares without your consent), then you really dont want to submit the old share. So this is not a bug. |
|
|
|
[2012-03-22 22:46:43] Started cgminer 2.3.1
[2012-03-22 22:46:43] Started cgminer 2.3.1
[2012-03-22 22:46:43] Probing for an alive pool
[2012-03-22 22:46:44] Long-polling activated for http://mining.eligius.st:8337/LP
Segmentation fault
root@ds-r:~/cgminer-2.3.1-2#
Running on debian squeeze, sdk 2.4, newer/ish fglrx I get the same error from both a self built and the pre-built ubuntu binary. Partial install of 2 different SDKs. |
|
|
|
I would assume this is a false positive, but I guess it doesn't hurt to ask official advice. MS Security Essentials didn't pick up on anything but AVG did.  Read the increasingly unread FAQ in the readme included in the zip file about cgeminer being a virus. |
|
|
|
Hi, I'm sure I am doing something really stupid but I can't get my 3x 7970s over 200 MHash/S each.
Running 12.2 driver and the newest version of cgminer.
Is there anything extra I need to do for 7970? I used cgminner for all my other cards. Thanks.
Presumably that's the dodgy sdk that diablo kernel doesn't work with. Try -k poclbm if you are passing a kernel choice to it. |
|
|
|
Is it efficient to use balance or rotation mode? I would like to get text alerts from a pool but I don't like putting on my hashing power there. Balance seems like a good option if LP still works correctly. Does it matter how many pools are used?
It is a little less efficient trying to use multiple pools at the same time because of the problem with pools disagreeing about when a block changes by a few seconds between them and having to run multiple long polls that discard more work. That said it's only 2 or 3 seconds' work every 10 minutes so doesn't amount to much but will be visible if you watch stats on cgminer at the time. |
|
|
|
been getting this error on 2 of my miners lately. they run about 6 hours every time too. been crashing like clockwork for a few days now [regular log stuff, then suddenly this] [2012-03-20 14:04:09] Failed to create submit_work_thread [lots of statistics] [2012-03-20 14:04:09] API failed (Socket Error: (10004) Interrupted system call) - API will not be available [2012-03-20 14:04:09] longpoll failed for http://api.bitcoin.cz:8408, sleeping for 30s and thats the end, they are then sitting at "press any key to continue . . ." same exact error on both they are both running 2.3.1, no special flags aside from autoclock and autofan settings. my 6870 is win7 64 bit, 11.11 driver, 2.5 sdk, and the 6770 is vista 32, 12.1, 2.3 sdk. clean installs, I never reuse bins, and delete bins when upgrading drivers and/or sdks. cgminer is always installed fresh, never over itself. my 5830 on 11.4, 2.1 and XP with cgminer 2.2.7 runs perfect. same pool settings as the 6870 and 6770, so if its the longpoll fail thats killing the 2.3.1 miners the 2.2.7 version is OK with whatever it is.. is longpoll handled differently between 2.2.7 and 2.3.1? any ideas? Failing to create submit_work_thread is the key here. It has nothing to do with how it fails after that. Inability to create the thread suggests a system resource problem, like running out of memory or too many threads starting up for some reason. |
|
|
|
|
Show Posts
