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

[-ck]

3x5970 -- why is my GPU 4/5 fan speed so high?

This is after an hour or so of 2.2.5, but the fan speeds were the same after 70 hours of 2.2.4.

While it's running, can you go into settings and enable debug mode and see what it's saying about temperatures and fan speeds? It will spew all sorts of info so you'll have to watch for a while to find it.

Sequences like this were output at 3 or 6 second intervals, so there were dozens during the sample period.  100% of them had fanspeed changes for GPU 2, with temperatures rising or falling and setting its speed to 68 or 67.  No other GPU was mentioned in a "fanspeed" message.

2.2.5+ (commit 158c09107cb9ec1657c42213e3d7e5c972ff0aae; Tue Feb 14 13:33:17 2012 UTC)

Hmm if I didn't know any better, it looks like the auto-fan is not being enabled on the other devices.
Can you click on GPU setting, Change setting and select each device in order and see if they report:

Code:

Fan autotune is enabled (0-85)

Thanks

[1713979889]

1713979889

[1713979889]

1713979889

[1713979889]

1713979889

[1713979889]

1713979889

[1713979889]

1713979889

[1713979889]

1713979889

[Ed]

I am using cgminer 2.1.2(I use 2.1.2 because any other version I use gives me lower speeds)  

I am using too 2.1.2 as faster

it is good working config for me

Code:

{
"pools" : [
	{
...main pool...
	}
	{
...backup pool....
	}
],

"intensity" : "9,9,9,9",
"gpu-engine" : "996,1050,880,860",
"gpu-fan" : "50-100,50-100,50-100,50-100",
"gpu-memclock" : "200,200,200,200",
"gpu-vddc" : "1.210,1.120,1.135,1.135",
"temp-cutoff" : "90,90,90,90",
"temp-overheat" : "80,80,80,80",
"temp-target" : "64,53,61,61",

"algo" : "c",
"auto-fan" : true,
"expiry" : "120",
"failover-only" : true,
"gpu-threads" : "1",
"log" : "5",
"queue" : "3",
"retry-pause" : "5",
"scan-time" : "60",
"temp-hysteresis" : "1",
"worksize" : "0",

"donation" : "0.00",
"shares" : "0",
"submit-stale" : true,
"kernel-path" : "/usr/local/bin"
}

can you tell your AMD drivers / AMD OCL SDK versions combination?

I am using:
atiumdag 8.920.0.0 (Catalyst 11.12) / Win7 64
with
OpenCL 1.1 AMD-APP-SDK-v2.5 (684.213)


p/s/
anyone try to change kernels? and "-v" "-w" options?

[Proofer]

Hmm if I didn't know any better, it looks like the auto-fan is not being enabled on the other devices.
Can you click on GPU setting, Change setting and select each device in order and see if they report:

Code:

Fan autotune is enabled (0-85)

Thanks

"Fan autotune is enabled (0-85)" is reported for each of the 6 cores.

[-ck]

Hmm if I didn't know any better, it looks like the auto-fan is not being enabled on the other devices.
Can you click on GPU setting, Change setting and select each device in order and see if they report:

Code:

Fan autotune is enabled (0-85)

Thanks

"Fan autotune is enabled (0-85)" is reported for each of the 6 cores.

Thanks. In the meantime, I've audited the code and can't find where this might happen, so a fix for this is not coming in the next version I'm afraid. I'll keep looking.

[minero1]

Hi CK, have you found the problem causing the high % of rejected shares? i set it to -I 9 and still having way to many rejects, it starts very ugly but with time appears to get better, my current run shows (A:35107 R:2059), less than with dynamic set but still.
I'm running 2.2.4 i didn't notice that in 2.0.8

[-ck]

Hi CK, have you found the problem causing the high % of rejected shares? i set it to -I 9 and still having way to many rejects, it starts very ugly but with time appears to get better, my current run shows (A:35107 R:2059), less than with dynamic set but still.
I'm running 2.2.4 i didn't notice that in 2.0.8

This is the first time you've reported it?

Suggestions:
Perhaps your pool is actually asking you to submit the old shares even if they're stale. Newer cgminer supports the "submitold" feature now.

I get .3-.4% rejects with static intensities so I can't reproduce your problem here.

p2pool also has a significantly higher reject rate if that's what you're on/have moved to.

[-ck]

New release: Version 2.2.6 - February 16, 2012

Links in top post as always.

Trying hard to make the most current release as stable as possible at the moment.

Updated customised poclbm kernel for 7970 worth 2 more Mhash, and same on any other GPUs when run on SDK2.6.
BIG FAT WARNINGS if SDK 2.6 is detected.
Ability to tune dynamic mode with a new --gpu-dyninterval parameter. This tells cgminer how long maximum it can keep the GPU busy for. Default was 7ms but can now be set to any value. Setting it higher will increase your hashrate and make your desktop less responsive. This is in response to requests to improve hashrate back to what it was when 2 threads were in use.
The display should keep all logs now from startup when the curses formatted display begins.
The bug where dynamic mode increases stale rate by submitting duplicate work should be fixed.

Full changelog:

 Provide warning on each startup about sdk 2.6
- Fix unused warnings on win32.
- bitforce: Simplify BFopen WIN32 ifdef/else
- Fix initialization warning with jansson 1.3
- bitforce: Cleanup extraneous TODO that isn't needed
- Move tcsetattr (and new tcflush) into *nix BFopen to simplify things a bit
- Add message explaining 2nd thread disabling for dynamic mode and how to tune
it.
- Move logwindow down once number of devices is known.
- Automatically choose phatk kernel for bitalign non-gcn ATI cards, and then
only select poclbm if SDK2.6 is detected.
- Allow the refresh interval to be adjusted in dynamic intensity with a
--gpu-dyninterval parameter.
- Make curses display visible right from the beginning and fix the window sizes
so the initial messages don't get lost once the status window is drawn.
- The amount of work scanned can fluctuate when intensity changes and since we
do this one cycle behind, we increment the work more than enough to prevent
repeati
- bitforce: Set a 30 second timeout for serial port on Windows, since the
default is undefined
- Use PreVal4addT1 instead of PreVal4 in poclbm kernel.
- Import PreVal4 and PreVal0 into poclbm kernel.
- Import more prepared constants into poclbm kernel.
- Keep variables in one array but use Vals[] name for consistency with other
kernel designs.
- Replace constants that are mandatorily added in poclbm kernel with one value.
- Remove addition of final constant before testing for result in poclbm kernel.
- Hand optimise variable addition order.
- Hand optimise first variable declaration order in poclbm kernel.
- Radical reordering machine based first pass to change variables as late as
possible, bringing their usage close together.
- fix strcpy NULL pointer if env HOME unset.
- bitforce: Disable automatic scanning when at least one device is specified
manually
- Unroll all poclbm additions to enable further optimisations.

[DeathAndTaxes]

Hi CK, have you found the problem causing the high % of rejected shares? i set it to -I 9 and still having way to many rejects, it starts very ugly but with time appears to get better, my current run shows (A:35107 R:2059), less than with dynamic set but still.
I'm running 2.2.4 i didn't notice that in 2.0.8

What pool, what card, what clocks?
Does problem go away at lower intensity?
Does problem go away at lower clock?

[DeathAndTaxes]

BIG FAT WARNINGS if SDK 2.6 is detected.

Nice. 

[stevegee58]

I'd like to ask a couple of naive questions but first here's my background:  I am in fact using the 2.6 SDK and I'm mining productively using cgminer and a 6770 GPU.  I'm using phatk instead of poclbm because I read somewhere that it was "better".  At intensity 8 I'm getting right around 200 MH/s which isn't too bad for a 6770.

If I keep the 2.6 SDK, would switching to poclbm from phatk do anything for me?  The latest version favors poclbm for the 2.6 SDK but I don't know why.

If I downgrade my SDK from 2.6 to 2.5, what improvement might I see?

[DeathAndTaxes]

I'd like to ask a couple of naive questions but first here's my background:  I am in fact using the 2.6 SDK and I'm mining productively using cgminer and a 6770 GPU.  I'm using phatk instead of poclbm because I read somewhere that it was "better".  At intensity 8 I'm getting right around 200 MH/s which isn't too bad for a 6770.

If I keep the 2.6 SDK, would switching to poclbm from phatk do anything for me?  The latest version favors poclbm for the 2.6 SDK but I don't know why.

If I downgrade my SDK from 2.6 to 2.5, what improvement might I see?

Lots of variables involved.  Testing the other kernel is as simple as using -k option.

Run one for a large number of shares, check avg hashrate, stop cgminer, start w -k to use other kernel and run for roughly same number of shares (doesn't need to be exact).  The check avg hashrate.

Between, OS, driver version, kernel, worksize, vectors, intensity, type (dedicated rig vs multi-use), amount of non-mining use, GPU generation, core clock, memclock (yes different memclocks have different effects based on SDK and kernel), etc there is a lot of variation.  The best thing to do is just test it.

[cabin]

A lot of people have seen reduced performance with the 2.6 stream SDK and there seems to be a lot of confusion about it. Here are 4 methods where you can get your hash rate back to where it was. Many other combinations WILL produce spectacularly poor results on 2.6 compared to 2.4. These are on a 5770 @920MHz:

cgminer(v2.1.2) -I8 *using renamed phatk110817Juniperbitalignv2w128long4 kernal compiled under 2.4*           210 MH/s
cgminer(v2.1.2) -k phatk -v4 -I8                                                                                                          208 MH/s
cgminer(v2.2.5) -k phatk -v4 -I8                                                                                                         207 MH/s
phoenix(v1.7.5) -k phatk2 WORKSIZE=128 VECTORS4 AGGRESSION=9                                                         211 MH/s

[kentrolla]

you should just add all the opencl.dll files in there and have cgminer choose the best one. its getting confusing which opencl.dll works the best with what card.

[The00Dustin]

you should just add all the opencl.dll files in there and have cgminer choose the best one. its getting confusing which opencl.dll works the best with what card.

Since ck is busy enough and has stated he won't respond to posts others can respond to, I'll step in here and point out that he can't do this due to licensing restrictions.  I suppose he could have folders where you could choose to drop opencl.dll files in yourself, but I don't see most users dealing with that, so it would probably be wasted programming effort.

[rjk]

Just installed 11.6 on 64-bit windows 7, and cgminer 2.2.3 was only showing 1 GPU. I updated to cgminer 2.2.6, and now I get this:

Code:

Too many values passed to set temp cutoff

Do I need dummy plugs for the cards, or is there some other issue? Should I just suck it up and install the latest drivers?

[minero1]

Hi CK, have you found the problem causing the high % of rejected shares? i set it to -I 9 and still having way to many rejects, it starts very ugly but with time appears to get better, my current run shows (A:35107 R:2059), less than with dynamic set but still.
I'm running 2.2.4 i didn't notice that in 2.0.8

What pool, what card, what clocks?
Does problem go away at lower intensity?
Does problem go away at lower clock?

nothing wrong with the pool or rig, it was ok until i upgraded to 2.2.4. Anyway, i installed 2.2.6 and the reject rate dropped as promised by CK (good work, thanks), less than 1% this time with a short run thou, i'll report if it goes bad again. what is the proper method to downgrade to SDK 2.less than 6?

[psychok9]

On windows, you can also specify "export GPU_USE_SYNC_OBJECTS = 1"
Only way is different, "Computer> System Properties> Advanced system settings> system environment> create a new variable" GPU_USE_SYNC_OBJECTS ", the value of the variable is -" 1 "

Thanks!
This fixed my high cpu usage on Catalyst 12.2.

[jjiimm_64]

On windows, you can also specify "export GPU_USE_SYNC_OBJECTS = 1"
Only way is different, "Computer> System Properties> Advanced system settings> system environment> create a new variable" GPU_USE_SYNC_OBJECTS ", the value of the variable is -" 1 "

Thanks!
This fixed my high cpu usage on Catalyst 12.2.

Just tried this....  does not work on my win7 64 rig with 5x7970.  tried in the bat file and in the environment vars...

[The00Dustin]

On windows, you can also specify "export GPU_USE_SYNC_OBJECTS = 1"
Only way is different, "Computer> System Properties> Advanced system settings> system environment> create a new variable" GPU_USE_SYNC_OBJECTS ", the value of the variable is -" 1 "

Thanks!
This fixed my high cpu usage on Catalyst 12.2.

Just tried this....  does not work on my win7 64 rig with 5x7970.  tried in the bat file and in the environment vars...

It just has no effect at all on Windows systems (confirmed by AMD). You could as well set MITT_ROMNEY_IS_A_DICKHEAD = 1 ... would have the same effect

[DeathAndTaxes]

It just has no effect at all on Windows systems (confirmed by AMD). You could as well set MITT_ROMNEY_IS_A_DICKHEAD = 1 ... would have the same effect

You jerk.  I set the MITT_ROMNEY_IS_A_DICKHEAD = 1 flag and within minutes I had some Jehovah's witnesses at my door trying to convert me.  I am never going to do that again.