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
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 651. (Read 5805998 times)
February 15, 2012, 10:44:13 AM
February 15, 2012, 10:24:52 AM
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?
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.
February 15, 2012, 10:15:23 AM
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?
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?
February 15, 2012, 10:04:08 AM
February 15, 2012, 10:03:11 AM
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
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?
February 15, 2012, 09:58:29 AM
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.
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.
February 15, 2012, 09:39:02 AM
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? I'm running 2.2.4 i didn't notice that in 2.0.8
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.
February 15, 2012, 09:33:54 AM
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
I'm running 2.2.4 i didn't notice that in 2.0.8
February 15, 2012, 09:18:25 AM
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:
Thanks
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)
"Fan autotune is enabled (0-85)" is reported for each of the 6 cores.
February 15, 2012, 09:15:45 AM
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:
Thanks
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)
"Fan autotune is enabled (0-85)" is reported for each of the 6 cores.
February 15, 2012, 05:08:19 AM
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?
February 15, 2012, 12:48:24 AM
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.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.
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)
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)
February 15, 2012, 12:20:37 AM
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.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.
From running in debug mode for 2.5 minutes, here are the first three sequences in which the string "fanspeed" occurred:
Code:
[2012-02-14 16:46:10] GPU4 63.0C 4499RPM | (5s):362.2 (avg):363.3 Mh/s | A:489 R:12 HW:0 U:1.79/m I: 9
[2012-02-14 16:46:10] 69.0 C F: 85%(4615RPM) E: 810MHz M: 200Mhz V: 1.050V A: 98% P: 0%
[2012-02-14 16:46:10] 72.5 C F: 85%(4615RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:10] Temperature rising while in target range, increasing fanspeed
[2012-02-14 16:46:10] Setting GPU 2 fan percentage to 68
[2012-02-14 16:46:10] 68.0 C F: 67%(3987RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:10] 63.5 C F: 67%(3983RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:10] 63.0 C F: 85%(4504RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:10] 66.0 C F: 85%(4504RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:13] 69.0 C F: 85%(4609RPM) E: 810MHz M: 200Mhz V: 1.050V A: 98% P: 0%
[2012-02-14 16:46:13] 72.5 C F: 85%(4609RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:13] Temperature dropping while in target range, decreasing fanspeed
[2012-02-14 16:46:13] Setting GPU 2 fan percentage to 67
[2012-02-14 16:46:13] 68.0 C F: 68%(4020RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:13] 63.5 C F: 68%(4024RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:13] 63.0 C F: 85%(4509RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:13] 66.5 C F: 85%(4504RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:16] GPU3 63.0C 3983RPM | (5s):362.4 (avg):363.5 Mh/s | A:507 R:10 HW:0 U:1.85/m I: 9
[2012-02-14 16:46:16] 69.0 C F: 85%(4620RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:16] 72.5 C F: 85%(4626RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:16] Temperature rising while in target range, increasing fanspeed
[2012-02-14 16:46:16] Setting GPU 2 fan percentage to 68
[2012-02-14 16:46:16] 68.0 C F: 67%(3983RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:16] 63.0 C F: 67%(3987RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:16] 63.0 C F: 85%(4493RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
[2012-02-14 16:46:16] 66.0 C F: 85%(4499RPM) E: 810MHz M: 200Mhz V: 1.050V A: 99% P: 0%
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.
Here is cgminer -n while cgminer was running:
Code:
[2012-02-14 18:15:21] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-02-14 18:15:21] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-02-14 18:15:21] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2012-02-14 18:15:21] Platform 0 devices: 6
[2012-02-14 18:15:21] GPU 0 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-14 18:15:21] GPU 1 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-14 18:15:21] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2012-02-14 18:15:21] GPU 2 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-14 18:15:21] GPU 3 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-14 18:15:21] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2012-02-14 18:15:21] GPU 4 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-14 18:15:21] GPU 5 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-14 18:15:21] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2012-02-14 18:15:21] Dual GPUs detected: 1 and 0
[2012-02-14 18:15:21] Dual GPUs detected: 3 and 2
[2012-02-14 18:15:21] Dual GPUs detected: 5 and 4
[2012-02-14 18:15:21] 6 GPU devices max detected
2.2.5+ (commit 158c09107cb9ec1657c42213e3d7e5c972ff0aae; Tue Feb 14 13:33:17 2012 UTC)
February 14, 2012, 03:50:52 PM
I am using cgminer 2.1.2(I use 2.1.2 because any other version I use gives me lower speeds) and I save my config file before I exit, but it won't load my pools on restart.
Sigh ... coz you are using 2.1.2 ... and new is slower coz you upgraded your SDKI (and others) have posted about that a few times in the last few pages ... ... ... ...
February 14, 2012, 03:43:01 PM
I am using cgminer 2.1.2(I use 2.1.2 because any other version I use gives me lower speeds) and I save my config file before I exit, but it won't load my pools on restart.
February 14, 2012, 03:21:48 PM
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. 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.
February 14, 2012, 12:03:01 PM
3x5970 -- why is my GPU 4/5 fan speed so high?
Long version:
Brief version:
Relevant portion of .config:
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.
Edit:
I added:
"gpu-fan" : "0-85"
but it made no difference. However, I watched the startup values carefully. All three units started with fan speeds in the mid 4-thousands. GPUs 2/3 fan speed steadily decreased but the other two units (0/1 and 4/5) remained close to where they started. I posed my question (above) with respect to 4/5 because GPU 1 temperature is near/at the target and I thought that might be what is keeping its fan speed up, but the same can't be said of 4/5.
Long version:
Code:
GPU 0: 362.8 / 363.4 Mh/s | A:110 R:5 HW:0 U:2.04/m I:9
66.5 C F: 85% (4582 RPM) E: 810 MHz M: 200 Mhz V: 1.050V A: 99% P: 0%
Last initialised: [2012-02-14 07:57:44]
Intensity: 9
Thread 0: 362.1 Mh/s Enabled ALIVE
GPU 1: 363.1 / 363.5 Mh/s | A:118 R:1 HW:0 U:2.19/m I:9
70.0 C F: 85% (4582 RPM) E: 810 MHz M: 200 Mhz V: 1.050V A: 99% P: 0%
Last initialised: [2012-02-14 07:57:45]
Intensity: 9
Thread 1: 362.8 Mh/s Enabled ALIVE
GPU 2: 362.9 / 363.7 Mh/s | A:107 R:3 HW:0 U:1.99/m I:9
68.0 C F: 59% (3674 RPM) E: 810 MHz M: 200 Mhz V: 1.050V A: 99% P: 0%
Last initialised: [2012-02-14 07:57:46]
Intensity: 9
Thread 2: 362.3 Mh/s Enabled ALIVE
GPU 3: 363.0 / 363.5 Mh/s | A:101 R:4 HW:0 U:1.88/m I:9
63.5 C F: 59% (3678 RPM) E: 810 MHz M: 200 Mhz V: 1.050V A: 99% P: 0%
Last initialised: [2012-02-14 07:57:46]
Intensity: 9
Thread 3: 362.3 Mh/s Enabled ALIVE
GPU 4: 363.0 / 363.5 Mh/s | A:104 R:4 HW:0 U:1.93/m I:9
60.0 C F: 85% (4483 RPM) E: 810 MHz M: 200 Mhz V: 1.050V A: 99% P: 0%
Last initialised: [2012-02-14 07:57:47]
Intensity: 9
Thread 4: 362.3 Mh/s Enabled ALIVE
GPU 5: 363.1 / 363.6 Mh/s | A:101 R:5 HW:0 U:1.88/m I:9
64.0 C F: 85% (4488 RPM) E: 810 MHz M: 200 Mhz V: 1.050V A: 99% P: 0%
Last initialised: [2012-02-14 07:57:47]
Intensity: 9
Thread 5: 362.5 Mh/s Enabled ALIVE
Brief version:
Code:
cgminer version 2.2.5 - Started: [2012-02-14 07:57:44]
--------------------------------------------------------------------------------
(5s):2178.0 (avg):2178.7 Mh/s | Q:2409 A:691 R:22 HW:0 E:29% U:11.82/m
TQ: 6 ST: 7 SS: 13 DW: 487 NB: 5 LW: 3055 GF: 0 RF: 0
Connected to http://127.0.0.1:9332 with LP as user Proofer
Block: 000007a595070ee8a15647e9d1d101cb... Started: [08:51:35]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 67.5C 4599RPM | 363.6/363.4Mh/s | A:116 R:5 HW:0 U: 1.98/m I: 9
GPU 1: 70.5C 4599RPM | 364.2/363.6Mh/s | A:123 R:1 HW:0 U: 2.10/m I: 9
GPU 2: 69.5C 3706RPM | 364.2/363.7Mh/s | A:116 R:3 HW:0 U: 1.98/m I: 9
GPU 3: 64.5C 3709RPM | 364.1/363.6Mh/s | A:111 R:4 HW:0 U: 1.90/m I: 9
GPU 4: 61.0C 4483RPM | 364.0/363.5Mh/s | A:116 R:4 HW:0 U: 1.98/m I: 9
GPU 5: 64.5C 4483RPM | 364.1/363.1Mh/s | A:109 R:5 HW:0 U: 1.86/m I: 9
--------------------------------------------------------------------------------
Relevant portion of .config:
Code:
"intensity" : "9",
"gpu-threads" : "1",
"gpu-engine" : "810-810",
"gpu-memclock" : "200",
"temp-cutoff" : "80",
"temp-overheat" : "77",
"temp-target" : "70",
"temp-hysteresis" : "3",
"auto-fan" : true,
"auto-gpu" : true,
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.
Edit:
I added:
"gpu-fan" : "0-85"
but it made no difference. However, I watched the startup values carefully. All three units started with fan speeds in the mid 4-thousands. GPUs 2/3 fan speed steadily decreased but the other two units (0/1 and 4/5) remained close to where they started. I posed my question (above) with respect to 4/5 because GPU 1 temperature is near/at the target and I thought that might be what is keeping its fan speed up, but the same can't be said of 4/5.
February 14, 2012, 09:46:50 AM
Well the good news is that on static 2.2.5 has significantly lower rejects than any prior version I have used.
5128 shares accepted.
7 shares rejected.
0 SS (stale shares discarded locally)
5128 shares accepted.
7 shares rejected.
0 SS (stale shares discarded locally)
I second that, less 1-1.5% rejects here also.
February 14, 2012, 08:27:59 AM
So always use intensity 9 to avoid this bug then ?
Thanks !
Not quite. Always use a STATIC intensity, no matter whether it's set to 6, 8, or 14 as long as you don't use d.Thanks !
DAT is using intensity 9 because he has some powerful cards. Remember that intensity is a fine-tuning parameter and higher does not necessarily mean better.
Cards pulling 230MHash/s are generally better suited with intensity 8.
Yeah I am using 5870s only. I think they work best with 9 rather than 8 but I have not tested that yet.
February 14, 2012, 08:26:20 AM
Hmm well dynamic could be the culprit then indeed. And that won't really have anything to do with the 2nd thread being disabled, but perhaps because the worksize is constantly changing, it might not be offsetting the right amount and repeating work. That will need fixing...
I was noticing higher rejects with 2.2.x also, and upon searching, found this same problem with dynamic intensity. Switched to a static intensity, and the problem went away.Well the good news is that on static 2.2.5 has significantly lower rejects than any prior version I have used.
5128 shares accepted.
7 shares rejected.
0 SS (stale shares discarded locally)
Jump to: