OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[kano]

I'm a bit out of the loop, but, did something drastic change in 2.3.2 ?

I have rigs reporting as high as 170% Efficiency right now, with 125-150% being the average range for the others.

Win7 x64, CGMiner 2.3.2
5 rigs each with either SDK 2.1 or 2.4 and CAT 11.12 on all.
Mixed 5xxx/6xxx series card machines, exclusive 5xxx series card machines and exclusive 6xxx series card machines.

The performance is not specific to any card/config. The ONLY thing they all have in common is the 11.12 driver and CGminer version 2.3.2.

WTF ?

I double checked and didn't rely on the Efficiency% readout only. The ratio of GetWork's to Accepted's (even with Rejected included/excluded) does not lie.

Colour me impressed

Efficiency is the number of shares you find per work requests from the pool.

However, with RollNTime, a miner can generate multiple work from the one work request.

So on my cgminer at the moment that shows Efficiency of 271% (which isn't actually very high) it means for each work request I ask from the pool, I generate on average 2.71 work requests (and on average reply with 2.71 shares)

The time it takes to mine those 2.71 shares is on average 2.71 times as long as mining 1 share.

A higher efficiency means that the pool had to provide you with less work and thus less communication and thus also less communication for your miner to the pool when trying to get work ...

Overall it's a big advantage for the pool and usually a small advantage for each miner
(but it doesn't mean you are getting more shares)

[1713309029]

1713309029

[1713309029]

1713309029

[1713309029]

1713309029

[bitlane]

It is a pretty useless stat.

....unless you are a Pool OP that is and I am sure the OPs appreciate the newly found efficiency of CGMiner and the affect it has on Getwork requests and their server loads

[bitlane]

(but it doesn't mean you are getting more shares)

I realize this. It's just nice to see overall network efficiency improving and less discarded work because of it.

[rjk]

likely your pool implemented longer/better NTimeRolling.

Ozcoin just announced that they have adjusted their X-Roll-Ntime to 120 seconds, if you mine there it may have made a difference for you.

[kano]

likely your pool implemented longer/better NTimeRolling.

Ozcoin just announced that they have adjusted their X-Roll-Ntime to 120 seconds, if you mine there it may have made a difference for you.

They already had it (for quite a while) they just increased the time allowed to use it per work.

[Eveofwar]

Woke up to a hung cgminer 0% activity and no hashing

The log below hasn't changed in the last 5 hours, so I've restarted cgminer (had to X out of the window, as "q" wasn't working)

GPU 0/1 = 5970
GPU 2 = 5830
GPU 3 = 5830
GPU 4 = 5830

[2012-04-09 04:07:28] Accepted 00000000.398219cb.0ccf2195 GPU 4 thread 9
[2012-04-09 04:07:30] Accepted 00000000.5bb7eedb.2e813ef8 GPU 3 thread 7
[2012-04-09 04:07:30] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:30] Will attempt to re-initialise ADL
[2012-04-09 04:07:30] ADL re-initialisation complete
[2012-04-09 04:07:32] Accepted 00000000.031c03e9.d02f5836 GPU 3 thread 6
[2012-04-09 04:07:32] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:32] Will attempt to re-initialise ADL
[2012-04-09 04:07:32] ADL re-initialisation complete

[kano]

Woke up to a hung cgminer 0% activity and no hashing

The log below hasn't changed in the last 5 hours, so I've restarted cgminer (had to X out of the window, as "q" wasn't working)

GPU 0/1 = 5970
GPU 2 = 5830
GPU 3 = 5830
GPU 4 = 5830

[2012-04-09 04:07:28] Accepted 00000000.398219cb.0ccf2195 GPU 4 thread 9
[2012-04-09 04:07:30] Accepted 00000000.5bb7eedb.2e813ef8 GPU 3 thread 7
[2012-04-09 04:07:30] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:30] Will attempt to re-initialise ADL
[2012-04-09 04:07:30] ADL re-initialisation complete
[2012-04-09 04:07:32] Accepted 00000000.031c03e9.d02f5836 GPU 3 thread 6
[2012-04-09 04:07:32] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:32] Will attempt to re-initialise ADL
[2012-04-09 04:07:32] ADL re-initialisation complete

That would probably be the new code that attempts to restart ADL when it stops reporting GPU info.
Someone else mentioned a problem with it in IRC.
Looks like it doesn't work ... has anyone had it work yet?

It's this commit:
https://github.com/ckolivas/cgminer/commit/d4c513030f6d6da4cb54c0d1499d332a3987c376

If you remove the lines added at 686 to 690 (the whole 'if') it should stop it from attempting to do that for the time being until ckolivas gets back.

[GenTarkin]

Can confirm, I have this same error on my 6950. The fan stops "reporting" or w/e and cgminer goes poop. I just restart CGMINER for now, but this happens maybe once a day or 2.

[Eveofwar]

Woke up to a hung cgminer 0% activity and no hashing

The log below hasn't changed in the last 5 hours, so I've restarted cgminer (had to X out of the window, as "q" wasn't working)

GPU 0/1 = 5970
GPU 2 = 5830
GPU 3 = 5830
GPU 4 = 5830

[2012-04-09 04:07:28] Accepted 00000000.398219cb.0ccf2195 GPU 4 thread 9
[2012-04-09 04:07:30] Accepted 00000000.5bb7eedb.2e813ef8 GPU 3 thread 7
[2012-04-09 04:07:30] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:30] Will attempt to re-initialise ADL
[2012-04-09 04:07:30] ADL re-initialisation complete
[2012-04-09 04:07:32] Accepted 00000000.031c03e9.d02f5836 GPU 3 thread 6
[2012-04-09 04:07:32] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:32] Will attempt to re-initialise ADL
[2012-04-09 04:07:32] ADL re-initialisation complete

That would probably be the new code that attempts to restart ADL when it stops reporting GPU info.
Someone else mentioned a problem with it in IRC.
Looks like it doesn't work ... has anyone had it work yet?

It's this commit:
https://github.com/ckolivas/cgminer/commit/d4c513030f6d6da4cb54c0d1499d332a3987c376

If you remove the lines added at 686 to 690 (the whole 'if') it should stop it from attempting to do that for the time being until ckolivas gets back.

Good to know I'm not alone then.  It just started in 2.3.2 and was fine in 2.3.1-2 Windows

I'll just wait for a fix in the meantime.

[BCMan]

 Huge issue with cgminer cant shut down gpu if its overheats. Cgminer trying it to disable the gpu over and over again, but its continuing to mine!
 
 

[bulanula]

Huge issue with cgminer cant shut down gpu if its overheats. Cgminer trying it to disable the gpu over and over again, but its continuing to mine!
 
 

Do you have auto fan and auto gpu both enabled ?

I think that is the condition for the safety to kick in.

Read a few pages back, it is all there !

[BCMan]

 I have only autogpu enabled (dont want cgminer to control fans), and it worked before, on older version.

[jjiimm_64]

I have only autogpu enabled (dont want cgminer to control fans), and it worked before, on older version.

isn't the fan more important?  I actually do the opposite.  I set the gpu fixed, with auto-fan.  when things start to warm up I use the api to lower clocks and volts

[DeathAndTaxes]

only auto-gpu should be required.  that is how I have my 5970 farm configured.

The fact that cgminer is showing REST indicates a deeper problem.  cgminer IS trying to shutdown the card.  If it was a config issue it simply would never even attempt a shutdown.

I have never seen this bug before and it is somewhat worrisome.  I just had a 5970 idle due to overheat yesterday without issue. 

[ShadesOfMarble]

After starting cgminer, is it safe to delete the .bin-files or will that break functionality?
Reason is I want to run cgminer from one folder on different machines (dropbox folder) and they don't have the same SDK installed.

[BCMan]

only auto-gpu should be required.  that is how I have my 5970 farm configured.

The fact that cgminer is showing REST indicates a deeper problem.  cgminer IS trying to shutdown the card.  If it was a config issue it simply would never even attempt a shutdown.

I have never seen this bug before and it is somewhat worrisome.  I just had a 5970 idle due to overheat yesterday without issue.  

Yeah, don't want to mess with version with such critical bug. Back to 2.2.1 and its working as intended.

[bulanula]

Why not leave autofan on ?

That way it maintains a constant temperature for the GPUs which should be good for longer-term usage.

[DeathAndTaxes]

Why not leave autofan on ?

That way it maintains a constant temperature for the GPUs which should be good for longer-term usage.

auto-gpu also maintains constant temperature and keeps fan at a constant speed.

Also I think everyone is missing the point: auto-gpu vs auto-fan isn't the issue.

cgminer is showing REST.  Which indicates it has idled a GPU but the GPU continues to burn away at 100% load.  If you had a fan failure for example and that bug occurred it would indicate REST but the GPU would continue at 100% load until it destroyed the core.

[DeathAndTaxes]

After starting cgminer, is it safe to delete the .bin-files or will that break functionality?
Reason is I want to run cgminer from one folder on different machines (dropbox folder) and they don't have the same SDK installed.

Yes.  bin file is simply a cached copy of the compiled kernel.  Once a copy of the kernel has been loaded by the GPUs the bin file isn't used until the next start of cgminer.

[BCMan]

Why not leave autofan on ?

That way it maintains a constant temperature for the GPUs which should be good for longer-term usage.

Default ati algorithm is better imo and save fan & gpu for longer-term usage as well. With cgminer's autofan on they're less efficient. For example, when 50% is enough for one card for keeping good temp, cgminer switch it to 60%. Or when more speed is needed to keep temp below 69C ati algo spinning it at 48%, and keeping great temp., cgminer switch it to 40% and gpu starting to slowly overheating. These are real examples from my rig. So no, thanks.
 And yes, as DeathAndTaxes said, auto-fan don't fix the bug.