Author

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

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
OK, so I take it that I can no longer copy the .bin files from previous versions of CGMiner?
I can't get 2.2.3 to generate them.
Sam
Change the datestamp on your old bins to the new dates. That will do it. One day, just one day, I'd like for that fucking failed to build bug to go away. Maybe next release!  Roll Eyes
donator
Activity: 1218
Merit: 1079
Gerald Davis
Maybe nobody cares, but I should notice anyway.
Version 2.0.8 (win32) is last that works fast and effective. My 5850 gives 350 MH/s and I'm happy with the speed. All later versions (I tried every one of them) under the same conditions (cmdline options are the same) give just 308 MH/s
Any ideas?

Yes, you upgraded your video drivers. Thats the root cause. The reason your old copy of cgminer still works faster, is because it contains a cached/compiled copy of the .BIN file generated with your old drivers and sdk. If you were to reinstall 2.0.8 you will likely get the same lousy hashrate.

See here:
https://bitcointalksearch.org/topic/help-with-cgminer-and-5870s2-btc-bounty-solved-63383

For the speptical. 

1) make a copy of the bin files in your old "fast" cgminer.
2) delete the bin files
3) run "old fast" cgminer.  You will notice it has similar performance to the new cgminer.
4) copy "fast bins" to new cgminer
5) you will notice it has fast performance just like "old" cgminer.
hero member
Activity: 518
Merit: 500
Maybe nobody cares, but I should notice anyway.
Version 2.0.8 (win32) is last that works fast and effective. My 5850 gives 350 MH/s and I'm happy with the speed. All later versions (I tried every one of them) under the same conditions (cmdline options are the same) give just 308 MH/s
Any ideas?

Yes, you upgraded your video drivers. Thats the root cause. The reason your old copy of cgminer still works faster, is because it contains a cached/compiled copy of the .BIN file generated with your old drivers and sdk. If you were to reinstall 2.0.8 you will likely get the same lousy hashrate.

See here:
https://bitcointalksearch.org/topic/help-with-cgminer-and-5870s2-btc-bounty-solved-63383
member
Activity: 71
Merit: 10
Maybe nobody cares, but I should notice anyway.
Version 2.0.8 (win32) is last that works fast and effective. My 5850 gives 350 MH/s and I'm happy with the speed. All later versions (I tried every one of them) under the same conditions (cmdline options are the same) give just 308 MH/s
Any ideas?
sr. member
Activity: 406
Merit: 250
2.2.3 had strange behavior on my fixed-fan-rate rig, 10% lower hash rate on 5870s and crash on 5970

I think I had the same issue with my 5970.

Yesterday the rig sputtered while watching a video, mouse froze then screen went black.  Had to hard power off the rig and reset it, brought it back up and mining was fine.

This morning, shortly after a Longpoll -- 4-5 shares were submitted across my 4 GPUs, and then the stuttering starts again and my Kill-A-Watt shows my usage being near idle.  Mouse is basically unresponsive and doesn't do much.  Hard reset the machine again, 5970 wasn't being detected by Windows 7 or GPUz...powered off and back on, detected and mining under 2.2.1 until this can get resolved.

Both times, the 5970 fans would spin to 100%
legendary
Activity: 3586
Merit: 1098
Think for yourself
OK, so I take it that I can no longer copy the .bin files from previous versions of CGMiner?
I can't get 2.2.3 to generate them.
Sam
member
Activity: 266
Merit: 36
Proofer it will only go to 100% at the temp-overheat value which you have set to 77.

OK, I just removed the gpu-fan parameter and am leaving for the gym.  If I come back and my house is a pile of smoking rubble you will be in BIG TROUBLE!

Ha, at least you will be to worn out to do much about it  Tongue

After about 1.5 hours I see no difference after removing gpu-fan.  I'll report back if I encounter any problems.
donator
Activity: 798
Merit: 500
Proofer it will only go to 100% at the temp-overheat value which you have set to 77.

OK, I just removed the gpu-fan parameter and am leaving for the gym.  If I come back and my house is a pile of smoking rubble you will be in BIG TROUBLE!

Ha, at least you will be to worn out to do much about it  Tongue
member
Activity: 266
Merit: 36
Proofer it will only go to 100% at the temp-overheat value which you have set to 77.

OK, I just removed the gpu-fan parameter and am leaving for the gym.  If I come back and my house is a pile of smoking rubble you will be in BIG TROUBLE!
donator
Activity: 798
Merit: 500
Proofer it will only go to 100% at the temp-overheat value which you have set to 77.
member
Activity: 266
Merit: 36
Must be something other than 5970+Linux:  I've been running 2.2.3 on a 3x5970 rig for several days without problems.  (Well, I did have one DEAD core but I had that occasionally with previous versions as well.)

With p2pool:
Code:
"intensity" : "9",
"gpu-threads" : "1",
"gpu-engine" : "810-810",
"gpu-memclock" : "200",
"gpu-fan" : "85",
"temp-cutoff" : "80",
"temp-overheat" : "77",
"temp-target" : "70",
"temp-hysteresis" : "3",
"auto-fan" : true,
"auto-gpu" : true,

Take this out and see what happens:
Code:
"gpu-fan" : "85",

I believe that will cause one unit's fan -- cores 0-1 -- to go to 100%, which I don't want to see; currently:
Code:
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  72.5C 4593RPM | 364.7/363.8Mh/s | A:1559 R:45 HW:0 U: 1.89/m I: 9
 GPU 1:  76.0C 4593RPM | 365.1/364.2Mh/s | A:1562 R:48 HW:0 U: 1.89/m I: 9
 GPU 2:  68.0C 4438RPM | 365.1/364.2Mh/s | A:1614 R:44 HW:0 U: 1.95/m I: 9
 GPU 3:  63.0C 4438RPM | 365.1/364.2Mh/s | A:1568 R:45 HW:0 U: 1.90/m I: 9
 GPU 4:  65.5C 4493RPM | 365.0/364.1Mh/s | A:1580 R:56 HW:0 U: 1.91/m I: 9
 GPU 5:  68.5C 4493RPM | 365.2/364.1Mh/s | A:1493 R:45 HW:0 U: 1.81/m I: 9

However, if you really believe the experiment may be of use to the community, let me know and I'll do it.
donator
Activity: 798
Merit: 500
Must be something other than 5970+Linux:  I've been running 2.2.3 on a 3x5970 rig for several days without problems.  (Well, I did have one DEAD core but I had that occasionally with previous versions as well.)

With p2pool:
Code:
"intensity" : "9",
"gpu-threads" : "1",
"gpu-engine" : "810-810",
"gpu-memclock" : "200",
"gpu-fan" : "85",
"temp-cutoff" : "80",
"temp-overheat" : "77",
"temp-target" : "70",
"temp-hysteresis" : "3",
"auto-fan" : true,
"auto-gpu" : true,

Take this out and see what happens:
Code:
"gpu-fan" : "85",
member
Activity: 266
Merit: 36

Didn't' forget about this  Tongue I ran 2.1.2 with no errors for 18 hours then started 2.2.3 yesterday with the same flags and got this:
(...)
Weird how las initialised is slightly after start time, but it wasn't disabled for a few hours.  You might be on to something here.

I had to stay on 2.1.2. It's weird just us having reported this problem.
I believe that when people with 5970 rigs running Linux update cgminer, more posts like ours will appear.

Must be something other than 5970+Linux:  I've been running 2.2.3 on a 3x5970 rig for several days without problems.  (Well, I did have one DEAD core but I had that occasionally with previous versions as well.)

With p2pool:
Code:
"intensity" : "9",
"gpu-threads" : "1",
"gpu-engine" : "810-810",
"gpu-memclock" : "200",
"gpu-fan" : "85",
"temp-cutoff" : "80",
"temp-overheat" : "77",
"temp-target" : "70",
"temp-hysteresis" : "3",
"auto-fan" : true,
"auto-gpu" : true,
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
2.2.3 had strange behavior on my fixed-fan-rate rig, 10% lower hash rate on 5870s and crash on 5970
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Working on the 7970 tuning, I have tried to port both the diapolo and diablo kernels to cgminer. Alas neither of them are actually working yet, so instead I started modifying the existing poclbm kernel in cgminer to improve throughput. This should work on other GPUs as well as the 7970, but I have no idea if it's better or worse than phatk.

When it's released it will get a new date/version number, but I haven't changed the number right now so that people can download it now and give it a try:
https://raw.github.com/ckolivas/cgminer/kernels/poclbm120203.cl

Remember to delete any .bin files and if you're not on a 7970 with the latest cgminer, you'll have to tell it to use that kernel with -k poclbm.

So what's the damage? Well on the 7970 at 1200/1050 clocks, which was getting 694MHash, it's now getting 711Mhash. The 7970 has this unusual behaviour where the hashrate slowly rises for the first 5-10 minutes.
legendary
Activity: 1320
Merit: 1001
Working on i t... workaround for now is to set fan to fixed speed and disable --auto-fan

Thank you, ck. No need to hurry.
I know you are very busy these days.

newbie
Activity: 9
Merit: 0

Didn't' forget about this  Tongue I ran 2.1.2 with no errors for 18 hours then started 2.2.3 yesterday with the same flags and got this:
(...)
Weird how las initialised is slightly after start time, but it wasn't disabled for a few hours.  You might be on to something here.

I had to stay on 2.1.2. It's weird just us having reported this problem.
I believe that when people with 5970 rigs running Linux update cgminer, more posts like ours will appear.


Same here, 2x 6770 on Ubuntu 11.04  ~ 443 MH/s

With 2.2.3 GPU 0 stops working after a few hours. When i restart cgminer it works again for a few hours.
With 2.1.2  both cards are working fine since 30 hrs now...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/

Didn't' forget about this  Tongue I ran 2.1.2 with no errors for 18 hours then started 2.2.3 yesterday with the same flags and got this:
(...)
Weird how las initialised is slightly after start time, but it wasn't disabled for a few hours.  You might be on to something here.

I had to stay on 2.1.2. It's weird just us having reported this problem.
I believe that when people with 5970 rigs running Linux update cgminer, more posts like ours will appear.

Working on i t... workaround for now is to set fan to fixed speed and disable --auto-fan
legendary
Activity: 1320
Merit: 1001

Didn't' forget about this  Tongue I ran 2.1.2 with no errors for 18 hours then started 2.2.3 yesterday with the same flags and got this:
(...)
Weird how las initialised is slightly after start time, but it wasn't disabled for a few hours.  You might be on to something here.

I had to stay on 2.1.2. It's weird just us having reported this problem.
I believe that when people with 5970 rigs running Linux update cgminer, more posts like ours will appear.
hero member
Activity: 772
Merit: 500
Edit: Perhaps we could try my old approach of writing to output in the kernel, because I know that worked for me?

That's the code I used, but uses your NFLAG. It would need to scan the output buffer on host side everytime after a kernel execution, which could lead to higher CPU usage (and needs changes in host code), but saves the IF-clause and another write into output (which saves the kernel quite some instructions, even on GCN).

Code:
u result = (V[7] == 0x136032ed) * nonce;
output[NFLAG & result] = result;

This code would be more like your current code, but uses the approach of comparison and mul to save 0 or a positive nonce in result (and is slower than your current code). But for sure that can't be the problem we are looking for ...

Code:
u result = (V[7] == 0x136032ed) * nonce;
if (result)
output[FOUND] = output[NFLAG & result] = result;

Dia
Writing to output on every iteration isn't going to fix the problem, and I can't see how this would help to be honest. Note that your last code will end up setting output[FOUND] to 0 and would undo anything you wrote to it with other threads  Wink

You are right on the last code, at least I did no commit for it :-P.

Okay, phatk has const u base, which DiaKGCN has too, if GOFFSET is not set, which is currently always true.

phatk:
Code:
base + get_local_id(0) + get_group_id(0) * (WORKSIZE);
diakgcn:
Code:
((uint)get_group_id(0) * (uint)get_local_size(0)) + (uint)get_local_id(0) + base;

I have the (uint) cast, because the returned size_t can have 64 bits on some systems. The brakets I have for group-id * local_size should be unneded, because of * before +. Guess no problem here and as we discussed, output writing should be okay for now.

Dia
Jump to: