Author

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

hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
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

hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
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
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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?
legendary
Activity: 2450
Merit: 1002
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
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Quote from: Phateus on May 11, 2011, 05:05:55 PM

... so nothing has changed since then?
Vbs
hero member
Activity: 504
Merit: 500
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. Tongue
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
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

legendary
Activity: 1876
Merit: 1000


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
full member
Activity: 373
Merit: 100
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.
full member
Activity: 155
Merit: 100
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. Smiley

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
legendary
Activity: 1876
Merit: 1000
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. Smiley
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
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
... repost of what I said last time ...

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

https://bitcointalksearch.org/topic/m.742897 (the bit after 4) )
full member
Activity: 155
Merit: 100
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. Smiley
Anyone? I'm totally lost over here!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
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



ckvolias:

this kernel does not work well at all in 2.4/2.5 so (IMO) I think it may be premature to make it the default kernel as most people are not mining with 2.6

i will install 2.6 on my test machine with and see if the Cypress chips 58xx like this kernel at all

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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

hero member
Activity: 772
Merit: 500
Dia, you don't need to define a new variable (BASE) as const u base in order to edit it out in the case of GOFFSET.  Just toss an if statement into the void search.  

#ifndef GOFFSET
const u base,
#endif

As for your output, the only possible problem I can see is the use of parenthesis around your defined NFLAG and FOUND variables.
I don't bother defining things unless I absolutely have to.  It's much easier and less code-happy to use the exact value for the otherwise defined object and then comment anything that is worthy of remembering such as "The output, 0x80, is used for discovered Nonce.  The output, 0x7F, is used to ensure the Nonce is correct."

Also, why are you checking if the nonce values are the same?  O_o  Apparently, I don't understand your method.  Granted, I'm new at this.  Perhaps you were checking if you had the same work for each one?
I'll compare later when I'm home.  Rest assured, I'm OCD.  So I probably won't stop until it works.  ^_^

You are right, this works and looks a bit nicer, but would not have caused any problems with CGMINER, because GOFFSET is not used or implemented.
Code:
void search(	
#ifndef GOFFSET
const u base,
#endif
...

The output code for the CGMINER version was done by Con and should work ... can't see, why not, but any ideas are welcome Smiley.

Dia
hero member
Activity: 772
Merit: 500
Important code committed to git tree:

The longstanding generation of a zero sized binary appears to be due to the OpenCL library putting the binary in a RANDOM SLOT amongst 4 possible binary locations. Iterate over each of them after building from source till the real binary is found and use that.

THOSE HAVING THE ZERO SIZED BINARY BUG PLEASE TEST THIS EXECUTABLE!

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

Drop it into a clean 2.2.4 directory with no .bin files and try it please.

Or try a git build if you're that way inclined.

Great job on that issue, seems to work pretty good on Windows ...

Dia
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
Something is horribly wrong with cgminer 2.2.4 for me. It seems the newest kernel for phatk sucks monkey balls on my 5970. on cgminer 2.2.1 and kernel from last year (not sure which one) it was 359mh/s @ 805mhz / 109mhz
With the new phatk kernel as of this year, it gets around 300mh/s !!
any idea why?

Im running 11.12 drivers and 2.6sdk I believe.
Its on vista 32 ultimate.
Any idea?!

So, Ive stuck w/ cgminer 2.2.1 cuz it uses last years phatk kernel.
Repeat after me; it is not the kernel, it's the SDK.

Yeah. People just wanna get it working as fast as possible without even trying to understand what goes on behind the scenes.

Not good.


my 5970 gives me up to 380+ mhash per core using CCC 11.9 with the stock sdk 2.5xx it comes with (and CGMINER 2.2.4), try that just make sure you remove the other one completely
you can do this in windows by Express uninstall ALL amd software, then download driver sweeper or something similar, boot into safe mode (hold f8 at boot) and run driver sweeper in safe mode, (make sure to remove all registry entries) and physically delete the AMD/ATI directories then reboot, just make sure you delete your .bin files from cgminer directory first or alternatively just remove cgminer completely and then unzip a fresh copy back onto the hard drive

this will give you optimal speeds with 5970
hero member
Activity: 518
Merit: 500
Something is horribly wrong with cgminer 2.2.4 for me. It seems the newest kernel for phatk sucks monkey balls on my 5970. on cgminer 2.2.1 and kernel from last year (not sure which one) it was 359mh/s @ 805mhz / 109mhz
With the new phatk kernel as of this year, it gets around 300mh/s !!
any idea why?

Im running 11.12 drivers and 2.6sdk I believe.
Its on vista 32 ultimate.
Any idea?!

So, Ive stuck w/ cgminer 2.2.1 cuz it uses last years phatk kernel.
Repeat after me; it is not the kernel, it's the SDK.

Yeah. People just wanna get it working as fast as possible without even trying to understand what goes on behind the scenes.

Not good.
Jump to: