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

[kano]

... repost of what I said last time ...

No idea, however, the startup may show something ...

https://bitcointalk.org/index.php?topic=28402.msg742897#msg742897 (the bit after 4) )

[jjiimm_64]

HI all,
I'm just getting started here, so please excuse any noob statements or questions.
I followed the instructions for mining in P2Pool, and have it running smoothly, I think.
However, whenever I launch cgminer, it crashes my display driver (it recovers and reloads), then proceeds to give a bunch of errors and not do any mining that I can tell.
Where should I start looking to troubleshoot?
I can't attach images yet, but here's are links to screenshots showing the issue:

http://imageshack.us/photo/my-images/842/cap002k.jpg/
http://imageshack.us/photo/my-images/26/cap003t.jpg/

After I see this, if I click in cgminer window and press enter, it closes.

Thoughts?

Shameless bump, in case my issue got lost in the mix.
Anyone? I'm totally lost over here!

1. bumps usually are not necessary in bitcointalk
2. if cgminer crashes right away, you probably asked cgminer to clock your cards way out of the cards comfort zone.
3  Just start reading....... from the beginning

[Elmojo]

1. bumps usually are not necessary in bitcointalk
2. if cgminer crashes right away, you probably asked cgminer to clock your cards way out of the cards comfort zone.
3  Just start reading....... from the beginning

1. Sorry about that, I'm a little desperate.

2. I don't have any extra flags in the cgminer shortcut, so I can't see how it would be doing any clocking to my card.
Does it try to overclock by default? My card is already heavily OC'd using eVGA Precision.

3. I did, but my eyes just went crossed! I found an 'easy' step by step, and followed that, but that got me where I am now.
I need a bit of hand-holding, or at least some direction on where to get some clear, easy for noobs to understand instructions.

Elmojo

[ancow]

I need a bit of hand-holding, or at least some direction on where to get some clear, easy for noobs to understand instructions.

Perhaps if you considered following kano's advice, somebody could actually help you. So far, you haven't given anywhere near enough information.

[jjiimm_64]

2. I don't have any extra flags in the cgminer shortcut, so I can't see how it would be doing any clocking to my card.
Does it try to overclock by default? My card is already heavily OC'd using eVGA Precision.

3. I did, but my eyes just went crossed! I found an 'easy' step by step, and followed that, but that got me where I am now.
I need a bit of hand-holding, or at least some direction on where to get some clear, easy for noobs to understand instructions.

Elmojo

1.  if your going to use cgminer, try not to use other clocking tools, let cgminer manage
2.  "heavily OC'd"  is probably your issue

[cablepair]

Well I just made an interesting discovery. My newly modified poclbm kernel included in 2.2.4 works really well on my 6970 with sdk 2.6... I get the same hashrate with my modified poclbm kernel as I used to get with the phatk kernel on 2.4/2.5. Looks like a new default kernel may be in order.

Would others like to test this out on their various hardware?

-k poclbm

Also suggest decreasing worksize:

-k poclbm -w 64

nice Ill test it out on my various cards and let you know

Thanks a lot. As I said it's only the 6970 I tested it on and I was more than surprised. Other architecture may respond differently.

ok so I got upgraded to the latest CCC with sdk 2.6 on my testing Machine, its Windows 7 x64 / cgminer 2.2.4

ok so i tested the poclbm kernel as well as -w 64 on 6990 & 5870
Clocks:
6990 900/775
5870 950/180

SDK 2.5 default kernel

6990 - 405 mhash Per core
5870 - 430 Mhash

SDK 2.6 -k poclbm
6690 - 380-400 Mhash Per core (noticeably more fluctuation than with 2.5 and default kernel)
5870 - 390-420 Mhash Per core (again noticeably more fluctuation in mhash)

SDK 2.6 -k poclbm -w 64
6990 - Peeks at about 400 Mhash per core but usually stays below that and goes as low as 350
5870 - Same result I see 330-400+ Mhash a lot of fluctuation in mhash

Not sure why this is but with the 2.5 sdk and default kernel my speeds do not fluctuate hardly at all, If I look at the console of my 6990 rig every single core is running right about 405 mhash, same with the 5870, it stays pretty stable around 430 mhash, now with the 2.6 sdk and poclbm the speed is constantly changing and only peaks where it is normally stable with 2.5 and default kernel

conclusion:

in my humble opinion I think it is premature to make poclbm the default kernel, this is a nice option for people who game but if your running dedicated mining rigs you cant beat the 2.5 sdk with the default kernel

[Vbs]

From https://bitcointalk.org/?topic=7964.0

Below is a graph I came up with for my 5870 with the core clocked at 950.
V1 is the speed with no VECTORS option enabled, V2 is with using the standard "VECTORS" and V4 is using the new "VECTORS4" command line option.  The numbers with them show the WORKSIZE.

The phatk kernel still has one huge advantage over poclbm, which is being able to achieve peak performance at very low mem speeds (I'm using 150MHz myself on two 5850's), and which saves alot of $$$$ on the long run and allows for better o/c on the gpu core. Until someone develops a kernel that gets same/better results with a low mem clock (big worksize), people will be reluctant to change.

[kano]

Quote from: Phateus on May 11, 2011, 05:05:55 PM

... so nothing has changed since then?

[GenTarkin]

Ok, so I uninstalled AMD SDK 2.6 runtime and installed 2.5
Using 2.2.4 and latest phatk kernel (deleted previous bins) -w 256 and -w 128 are bout the same

Compared to cgminer 2.2.1 and phatk kernel from november w/ AMD SDK 2.6 its performance is on avg 1mh/s slower!
So the new kernel is poopy since it seems to suck when using SDK 2.6. Whereas the kernel from november works just fine w/ 2.6

[-ck]

Well I just made an interesting discovery. My newly modified poclbm kernel included in 2.2.4 works really well on my 6970 with sdk 2.6... I get the same hashrate with my modified poclbm kernel as I used to get with the phatk kernel on 2.4/2.5. Looks like a new default kernel may be in order.

Would others like to test this out on their various hardware?

-k poclbm

Also suggest decreasing worksize:

-k poclbm -w 64

nice Ill test it out on my various cards and let you know

Thanks a lot. As I said it's only the 6970 I tested it on and I was more than surprised. Other architecture may respond differently.

ok so I got upgraded to the latest CCC with sdk 2.6 on my testing Machine, its Windows 7 x64 / cgminer 2.2.4

ok so i tested the poclbm kernel as well as -w 64 on 6990 & 5870
Clocks:
6990 900/775
5870 950/180

SDK 2.5 default kernel

6990 - 405 mhash Per core
5870 - 430 Mhash

SDK 2.6 -k poclbm
6690 - 380-400 Mhash Per core (noticeably more fluctuation than with 2.5 and default kernel)
5870 - 390-420 Mhash Per core (again noticeably more fluctuation in mhash)

SDK 2.6 -k poclbm -w 64
6990 - Peeks at about 400 Mhash per core but usually stays below that and goes as low as 350
5870 - Same result I see 330-400+ Mhash a lot of fluctuation in mhash

Not sure why this is but with the 2.5 sdk and default kernel my speeds do not fluctuate hardly at all, If I look at the console of my 6990 rig every single core is running right about 405 mhash, same with the 5870, it stays pretty stable around 430 mhash, now with the 2.6 sdk and poclbm the speed is constantly changing and only peaks where it is normally stable with 2.5 and default kernel

conclusion:

in my humble opinion I think it is premature to make poclbm the default kernel, this is a nice option for people who game but if your running dedicated mining rigs you cant beat the 2.5 sdk with the default kernel

Thanks for that. The question was about the poclbm kernel being default, not the SDK being default. How does poclbm perform on 2.5 sdk for you?

[cablepair]

Ok, so I uninstalled AMD SDK 2.6 runtime and installed 2.5
Using 2.2.4 and latest phatk kernel (deleted previous bins) -w 256 and -w 128 are bout the same

Compared to cgminer 2.2.1 and phatk kernel from november w/ AMD SDK 2.6 its performance is on avg 1mh/s slower!
So the new kernel is poopy since it seems to suck when using SDK 2.6. Whereas the kernel from november works just fine w/ 2.6

+1 for using "poopy" when referring to an AMD SDK

[cablepair]

Well I just made an interesting discovery. My newly modified poclbm kernel included in 2.2.4 works really well on my 6970 with sdk 2.6... I get the same hashrate with my modified poclbm kernel as I used to get with the phatk kernel on 2.4/2.5. Looks like a new default kernel may be in order.

Would others like to test this out on their various hardware?

-k poclbm

Also suggest decreasing worksize:

-k poclbm -w 64

nice Ill test it out on my various cards and let you know

Thanks a lot. As I said it's only the 6970 I tested it on and I was more than surprised. Other architecture may respond differently.

ok so I got upgraded to the latest CCC with sdk 2.6 on my testing Machine, its Windows 7 x64 / cgminer 2.2.4

ok so i tested the poclbm kernel as well as -w 64 on 6990 & 5870
Clocks:
6990 900/775
5870 950/180

SDK 2.5 default kernel

6990 - 405 mhash Per core
5870 - 430 Mhash

SDK 2.6 -k poclbm
6690 - 380-400 Mhash Per core (noticeably more fluctuation than with 2.5 and default kernel)
5870 - 390-420 Mhash Per core (again noticeably more fluctuation in mhash)

SDK 2.6 -k poclbm -w 64
6990 - Peeks at about 400 Mhash per core but usually stays below that and goes as low as 350
5870 - Same result I see 330-400+ Mhash a lot of fluctuation in mhash

Not sure why this is but with the 2.5 sdk and default kernel my speeds do not fluctuate hardly at all, If I look at the console of my 6990 rig every single core is running right about 405 mhash, same with the 5870, it stays pretty stable around 430 mhash, now with the 2.6 sdk and poclbm the speed is constantly changing and only peaks where it is normally stable with 2.5 and default kernel

conclusion:

in my humble opinion I think it is premature to make poclbm the default kernel, this is a nice option for people who game but if your running dedicated mining rigs you cant beat the 2.5 sdk with the default kernel

Thanks for that. The question was about the poclbm kernel being default, not the SDK being default. How does poclbm perform on 2.5 sdk for you?

thats easy

POCLBM IS ABSOLUTE GARBAGE ON 2.5 !

seriously, I lose 100-150 Mhash per GPU using -k poclbm with 2.5 SDk
(tested with multiple 5870 and 6990)

that what I was trying to say it is premature to make poclbm the default kernel because most miners are using 2.5
the only people that want 2.6 and poclbm are people who want to do mining and gaming with the same machine

[-ck]

Thanks for that. The question was about the poclbm kernel being default, not the SDK being default. How does poclbm perform on 2.5 sdk for you?

thats easy

POCLBM IS ABSOLUTE GARBAGE ON 2.5 !

seriously, I lose 100-150 Mhash per GPU using -k poclbm with 2.5 SDk
(tested with multiple 5870 and 6990)

that what I was trying to say it is premature to make poclbm the default kernel because most miners are using 2.5
the only people that want 2.6 and poclbm are people who want to do mining and gaming with the same machine

Woho. That's more definitive testing. Just for my comfort, can you confirm that's the latest poclbm in 2.2.4 you're talking about? Thanks!

[cablepair]

Thanks for that. The question was about the poclbm kernel being default, not the SDK being default. How does poclbm perform on 2.5 sdk for you?

thats easy

POCLBM IS ABSOLUTE GARBAGE ON 2.5 !

seriously, I lose 100-150 Mhash per GPU using -k poclbm with 2.5 SDk
(tested with multiple 5870 and 6990)

that what I was trying to say it is premature to make poclbm the default kernel because most miners are using 2.5
the only people that want 2.6 and poclbm are people who want to do mining and gaming with the same machine

Woho. That's more definitive testing. Just for my comfort, can you confirm that's the latest poclbm in 2.2.4 you're talking about? Thanks!

yes, I tested it on a freshly unzipped cgminer 2.2.4

[-ck]

Thanks very much!

I guess I could whitelist the SDK and when cgminer detects sdk 2.6 it could default to poclbm instead of always. On linux it is "OpenCL 1.1 AMD-APP (844.4)". Can anyone tell me what "cgminer -n" tells them on windows with sdk 2.6 please?

edit: I guess I can install it into my windows VM and see for myself what 32 bit sdk2.6 is

edit: I have them all now. (does anyone use osx?)

[cablepair]

Code:

C:\cgminer-2.2.4-win32>cgminer -ndev.
[2012-02-12 16:10:55] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-02-12 16:10:55] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-02-12 16:10:55] CL Platform 0 version: OpenCL 1.1 AMD-APP (851.4)
[2012-02-12 16:10:55] Platform 0 devices: 4
[2012-02-12 16:10:55] GPU 0 AMD Radeon HD 6900 Series hardware monitoring enable
d
[2012-02-12 16:10:55] GPU 1 AMD Radeon HD 6900 Series hardware monitoring enable
d
[2012-02-12 16:10:55] GPU 2 AMD Radeon HD 6900 Series hardware monitoring enable
d
[2012-02-12 16:10:55] GPU 3 AMD Radeon HD 6900 Series hardware monitoring enable
d
[2012-02-12 16:10:55] 4 GPU devices max detected

C:\cgminer-2.2.4-win32>

[Elmojo]

Perhaps if you considered following kano's advice, somebody could actually help you. So far, you haven't given anywhere near enough information.

I didn't realize kano was responding to me. I didn't see anything in his post that made me think he was answering my question.
I looked at the post he linked to, but I don't see anything there that appears to apply to me.
He posted:
1) Read the README <-Did that first, looks like Greek (or Klingon) to me!
or
2) just restart it over and over until it succeeds to generate the new *.bin  <-From what I can tell, mine is generating BINs correctly
or
3) make sure you extracted all the files (including the new *.cl files) <- The cl files are in the directory, not sure what else to check
or
4) Last resort: just rename the old *.bin files to the new names: replace 110817 with 120203 in the names <-My bin files already have 120203 in the name

And the other repeated again and again info often needed with problems:
the full output of 'cgminer -n' and some of 'cgminer -D -T --verbose ...' (obviously not all of it if cgminer is actually running ...)
where '...' are the options you use  <-I have NO idea what this means. I tried running cgminer with the -n flag, and it flashes on the screen so fast I can't read anything, then closes.

I still think the biggest issue is figuring why it crashes my graphics driver every time.

1.  if your going to use cgminer, try not to use other clocking tools, let cgminer manage
2.  "heavily OC'd"  is probably your issue

1. I will, if I ever figure out how to use it.
2. Unlikely, it does the same even when my card is set back to stock clocks.

Does any of this help?
I'll be happy to post additional stats and logs, if I can get it working.

[Frizz23]

Would it be possible to add a switch to set the memory voltage? By default it's about 1.06V - but since we usually downclock memory so much, it would make sense to lower it considerably.

[DeathAndTaxes]

Would it be possible to add a switch to set the memory voltage? By default it's about 1.6V - but since we usually downclock memory so much, it would make sense to lower it considerably.

Not possible to alter the mem voltage via drivers.  Your only option is a flashed bios and even then
a) on most cards it is impossible, there is no voltage controller it is a single value device
b) you have a very good chance of bricking the card.

[Vbs]

Quote from: Phateus on May 11, 2011, 05:05:55 PM

... so nothing has changed since then?

Hmmm... Tough question there mate! To the best of my knowledge, we still have a kernel made for the 2.4 SDK having the best performance today on BFI_INT cards.