OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 612.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ?? on ??

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: cuz0882 on March 21, 2012, 03:59:14 AM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: vapourminer on March 20, 2012, 06:47:05 PM

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.

ancow

full member

Activity: 373

Merit: 100

Quote from: de4l on March 22, 2012, 10:50:55 PM

Code:

[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.

I'm getting a similar segfault with 12.x fglrx if I use an SDK older than 2.6 (debian testing, though). The best solution I found was to remove the APP SDK completely, install the packages "opencl-headers", "amd-libopencl1" and "amd-opencl-icd" and run cgminer with "GPU_USE_SYNC_OBJECTS=1" set after re-compiling it. Alternatively, using fglrx 11.x was the only alternative I found.
But then, I compile cgminer myself and have never gotten the opencl version mismatch.

DeathAndTaxes

donator

Activity: 1218

Merit: 1080

Gerald Davis

So was testing over heat protection on my water cooled farm ...

Code:


 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.

boozer

sr. member

Activity: 309

Merit: 250

Quote from: kano on March 22, 2012, 11:44:25 AM

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

Code:

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:

Code:

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.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Kano, just tried to compile your latest, getting this:

Code:

bitforce.c: In function ‘bitforce_scanhash’:
bitforce.c:310: error: ‘REASON_THERMAL_CUTOFF’ undeclared (first use in this function)
bitforce.c:310: error: (Each undeclared identifier is reported only once
bitforce.c:310: error: for each function it appears in.)

Haven't looked into it myself yet, but thought I'd post it straight away...

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: kano on March 23, 2012, 09:25:49 AM

Daylight savings does not affect the internal storage of time, it simply displays it differently.

Right, I forgot, too much time in Windows-land where this isn't the case, so I agree, this one doesn't really need fixing.

Quote from: kano on March 23, 2012, 09:25:49 AM

Edit: oops yes the pool can also tell cgminer to submit stales - forgot to mention that - as mentioned above.

And this pool does tell it to. Like I said, it would be difficult to replicate, but I believe the stale handling via the SUBMITOLD function (pool telling cgminer to submit them) was ignored when the communication failure occurred (whereas --submit-stale would have presumably held onto it indefinitely based on posts to another user who was experiencing a memory leak issue that turned out to be due to GPU idle restarts with the 5970 bug). It is possible that the pool didn't send the SUBMITOLD command this time, but the same pool did in my previous run that was only a few days, and I haven't seen any posts indicating a change to the pool, so I wanted to bring up the possibility of that function not being as persistent as --submit-stale switch, as I don't know whether it should be or not. My discussion regarding whether or not the share would have been accepted shouldn't have been included, that was extraneous information.

DeathAndTaxes

donator

Activity: 1218

Merit: 1080

Gerald Davis

Quote from: The00Dustin on March 23, 2012, 08:27:44 AM

ETA2 If your point was that there is something I can do (in spite of the fact that my post should have made it clear that I was aware of that, I did say "I can't do much about either of these")

Yes that was the point. You said "I can't do much" and I was showing there is something = workaround that you CAN do.

I didn't say conman ignore this guy cgminer is flawless and never needs any future patches/fixes. Just pointing out if it is a bug it is somewhat rare and likely hard to track down one. It is also possible your pool screwed up. Are you saving raw copies of getworks? If pool has a bug where sometimes it fails to indicate stales should be submitted then cgminer won't.

In the meantime using submit stale = true will force cgminer to always submit a share. The code is very simple and likely immune to any potential bugs. cgminer simply always submits completed work, no matter what. I have one rig running 90+ days with almost 4 million shares and SS = 0 because submit stale = true.

If you don't want to workaround until a fix is found (if ever) then feel free to ignore the suggestion.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: The00Dustin on March 23, 2012, 07:59:08 AM

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]).

No - time always travels forwards - oddly enough

Daylight savings does not affect the internal storage of time, it simply displays it differently.

However, if you change the computer clock backwards or forwards (with ntp) - you get what you deserve.

Quote from: The00Dustin on March 23, 2012, 07:59:08 AM

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:

Quote

[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.

If you tell cgminer to submit stales it tells you explicitly that it is doing that:
"Stale share detected, submitting as user requested" before it shows the share Accepted/Rejected/whatever

If you don't tell cgminer to submit stales, then it will discard what it considers stale.
The thing to know about stales is that a work request is stale based on when it was received, not when you see it's share(s) shown in cgminer.
Cgminer threw away that share coz it wasn't told to submit stales and the getwork time implied the share was stale.
You can't assume the getwork order matches the share display order.

Edit: oops yes the pool can also tell cgminer to submit stales - forgot to mention that - as mentioned above.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Hawkix on March 23, 2012, 08:20:06 AM

...
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?

No.

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: DeathAndTaxes on March 23, 2012, 08:02:57 AM

If you want to avoid the second one there is a submit stale = true option available in the config file.

If the share is genuinely stale though that will simply increase the stale count on the pool server. If the share is valid it will prevent cgminer from proactively killing it.

Quote from: The00Dustin on March 23, 2012, 07:59:08 AM

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).

Quote from: -ck on February 27, 2012, 05:45:43 PM

Expiry is irrelevant when you have submit stale enabled or the pool asks for submitold (as p2pool does).

ETA emphasis

ETA2 If your point was that there is something I can do (in spite of the fact that my post should have made it clear that I was aware of that, I did say "I can't do much about either of these"), then I should clarify and note that I meant to fix the issues (as opposed to working around them, I can disable ntp and dst if need be for issue one and use --submit-old for issue 2, but that doesn't change the fact that either issue may be considered a design flaw worthy of fixing, which is why I posted them).

Hawkix

hero member

Activity: 531

Merit: 505

Quote from: DeathAndTaxes on March 23, 2012, 07:43:41 AM

Why? Compiling the kernel takes time and resources. It makes the first start much slower.

That is the entire point of saving a bin file.

1) cgminer looks to see if bin files exists (binary version of OpenCL kernel)
2a) if no bin file exists it compiles the open CL kernel using CURRENTLY INSTALLED SDK and saves a copy as bin file
2b) if bin file exists then cgminer saves time and resources and loads that bin file
3) compiled binary (bin file) is loaded onto the GPU
4) execution begins

The 2a & 2b means if you upgrade sdk but DON'T delete the bin files you will run cgminer used kernel compiled on the SDK at the time of first start. If later you install a new copy of cgminer (which has no precompiled bin files) then and only then will the new SDK be used.

ckolivas could make cgminer compile on the fly on each startup and it likely would reduce confusion because as soon as you upgraded SDK and restarted cgminer you would see performance drop and people would stop blaming later version of cgminer for the drop. Still that change would only help the uninformed be less clueless and would slow start times for everyone else.

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

.

DeathAndTaxes

donator

Activity: 1218

Merit: 1080

Gerald Davis

If you want to avoid the second one there is a submit stale = true option available in the config file.

If the share is genuinely stale though that will simply increase the stale count on the pool server. If the share is valid it will prevent cgminer from proactively killing it.

The00Dustin

hero member

Activity: 807

Merit: 500

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:

Quote

[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.

ummas

sr. member

Activity: 274

Merit: 250

So i`m cheating...i like it....
I`m mining this same, but can run other(oclhashcat) software... double win to me.

DeathAndTaxes

donator

Activity: 1218

Merit: 1080

Gerald Davis

Quote from: Hawkix on March 23, 2012, 07:22:58 AM

Quote from: -ck on March 23, 2012, 07:02:44 AM

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.

Shouldn't the cgminer delete old .bin files itself? If it created them before, it should take care of them.

Why? Compiling the kernel takes time and resources. It makes the first start much slower.

That is the entire point of saving a bin file.

1) cgminer looks to see if bin files exists (binary version of OpenCL kernel)
2a) if no bin file exists it compiles the open CL kernel using CURRENTLY INSTALLED SDK and saves a copy as bin file
2b) if bin file exists then cgminer saves time and resources and loads that bin file
3) compiled binary (bin file) is loaded onto the GPU
4) execution begins

The 2a & 2b means if you upgrade sdk but DON'T delete the bin files you will run cgminer used kernel compiled on the SDK at the time of first start. If later you install a new copy of cgminer (which has no precompiled bin files) then and only then will the new SDK be used.

ckolivas could make cgminer compile on the fly on each startup and it likely would reduce confusion because as soon as you upgraded SDK and restarted cgminer you would see performance drop and people would stop blaming later version of cgminer for the drop. Still that change would only help the uninformed be less clueless and would slow start times for everyone else.

ummas

sr. member

Activity: 274

Merit: 250

22.02.2012 wasent the first day of usig, so he did i think...

.bin deleted....

Code:

2012-03-23 13:32:28] Failed to init GPU thread 0, disabling device 0
2012-03-23 13:32:28] Restarting the GPU from the menu is unlikely to fix this.
2012-03-23 13:32:28] Try stopping other applications using the GPU like afterburner.
2012-03-23 13:32:28] Then restart cgminer.
Press enter to continue:
cgminer version 2.0.6 - Started: [2012-03-23 13:32:28]
-------------------------------------------------------------------------------
(5s):0.0 (avg):0.0 Mh/s | Q:2  A:0  R:0  HW:0  E:0%  U:0.00/m
TQ: 2  ST: 3  SS: 0  DW: 0  NB: 1  LW: 0  GF: 0  RF: 0
Connected to http://gpumax.com:8332 with LP as user 4f39b86921fd404e601c2805
Block: 0000037bee13fa9ed034f4ae959e3405...  Started: [13:32:28]
-------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 41.5C 100% | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:0
GPU 1: 35.0C 1574RPM | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:9
GPU 2: 35.0C | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:9
GPU 3: 37.5C  960RPM | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:9
GPU 4: 42.0C | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:9
GPU 5: 38.5C  960RPM | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:9
GPU 6: 38.5C | DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:9
-------------------------------------------------------------------------------

I`m not able enable...

Code:

Select GPU to enable:
0 
Must restart device before enabling itGPU 0: 0.0 / 0.0 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:0

Hawkix

hero member

Activity: 531

Merit: 505

Quote from: -ck on March 23, 2012, 07:02:44 AM

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.

Shouldn't the cgminer delete old .bin files itself? If it created them before, it should take care of them.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ummas on March 23, 2012, 04:03:21 AM

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 Cheesy

Edit:
Last post have been edit with this:

Code:

 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 [email protected]_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.

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 612. (Read 5806103 times)