OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 456.

Krak

hero member

Activity: 591

Merit: 500

Quote from: ryann on October 29, 2012, 06:18:35 PM

Quote from: -ck on October 28, 2012, 03:51:01 PM

I got a share that registered a diff of 7.58M Grin

That was a block solve for mtred since current difficulty is just over 3 million.

What does that mean? Does it mean you make more coins or something?

Not unless you're mining on p2pool. Tongue

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ryann on October 29, 2012, 06:18:35 PM

Quote from: -ck on October 28, 2012, 03:51:01 PM

I got a share that registered a diff of 7.58M Grin

That was a block solve for mtred since current difficulty is just over 3 million.

What does that mean? Does it mean you make more coins or something?

No.

The share difficulty must be above the work difficulty for it to count as valid work.
How far above it is, makes no different to it's share value.

If it is above the network difficulty, it also represent s a block for the pool.

... i.e. it's purely information of interest to some

ryann

member

Activity: 70

Merit: 10

Quote from: -ck on October 28, 2012, 03:51:01 PM

I got a share that registered a diff of 7.58M Grin

That was a block solve for mtred since current difficulty is just over 3 million.

What does that mean? Does it mean you make more coins or something?

dooferorg

full member

Activity: 163

Merit: 100

Quote from: -ck on October 29, 2012, 05:09:55 PM

Quote from: dooferorg on October 29, 2012, 04:01:02 PM

Well darn .. You are quite right. 'cgminer -n' does show only 1. It says that ADL doesn't match OpenCL. I read about that with the gpu-map command but am still a bit confused.

I have the entries with their PCI IDs in the xorg.conf that match with the output of 'aticonfig --list-adapters'. I shouldn't need 'dummy plugs' to get the other adapter to work, should I?

Right, you shouldn't need dummy plugs unless you have a driver before about 11.6 or something. I still suspect your xorg config. is wrong, or you're not really exporting the display variable. Also it's worth noting people have had looots of trouble with recent drivers and last good was something like 12.8. Can you show us the actual output from cgminer -n ?

Absolutely. I'll provide any information needed. This is the first machine I've had multiple GPUs in (Linux or Windows), so I admit to being a bit clueless in their setup. I've done multiple displays under Linux, but only one GPU at a time.

Spammy stuff below:

cgminer -n:

Code:

 [2012-10-29 18:53:47] CL Platform 0 vendor: Advanced Micro Devices, Inc.                    
 [2012-10-29 18:53:47] CL Platform 0 name: AMD Accelerated Parallel Processing                    
 [2012-10-29 18:53:47] CL Platform 0 version: OpenCL 1.2 AMD-APP (1016.4)                    
 [2012-10-29 18:53:47] Platform 0 devices: 1                    
 [2012-10-29 18:53:47] 	0	Cypress                    
 [2012-10-29 18:53:47] ADL found more devices than opencl!                    
 [2012-10-29 18:53:47] There is possibly at least one GPU that doesn't support OpenCL                    
 [2012-10-29 18:53:47] Use the gpu map feature to reliably map OpenCL to ADL                    
 [2012-10-29 18:53:47] WARNING: Number of OpenCL and ADL devices did not match!                    
 [2012-10-29 18:53:47] Hardware monitoring may NOT match up with devices!                    
 [2012-10-29 18:53:47] GPU 0 ATI Radeon HD 5800 Series hardware monitoring enabled                    
 [2012-10-29 18:53:47] 1 GPU devices max detected

aticonfig --list-adapters:

Code:

* 0. 09:00.0 ATI Radeon HD 5800 Series
  1. 04:00.0 ATI Radeon HD 5800 Series

* - Default adapter

xorg.conf:

Code:

Section "ServerLayout"
	Identifier     "aticonfig Layout"
	Screen      0  "aticonfig-Screen[0]-0" 0 0
	Screen         "aticonfig-Screen[1]-0" RightOf "aticonfig-Screen[0]-0"
EndSection

Section "Module"
EndSection

Section "Monitor"
	Identifier   "aticonfig-Monitor[0]-0"
	Option	    "VendorName" "ATI Proprietary Driver"
	Option	    "ModelName" "Generic Autodetecting Monitor"
	Option	    "DPMS" "true"
EndSection

Section "Monitor"
	Identifier   "aticonfig-Monitor[1]-0"
	Option	    "VendorName" "ATI Proprietary Driver"
	Option	    "ModelName" "Generic Autodetecting Monitor"
	Option	    "DPMS" "true"
EndSection

Section "Device"
	Identifier  "aticonfig-Device[0]-0"
	Driver      "fglrx"
	BusID       "PCI:9:0:0"
EndSection

Section "Device"
	Identifier  "aticonfig-Device[1]-0"
	Driver      "fglrx"
	BusID       "PCI:4:0:0"
EndSection

Section "Screen"
	Identifier "aticonfig-Screen[0]-0"
	Device     "aticonfig-Device[0]-0"
	Monitor    "aticonfig-Monitor[0]-0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

Section "Screen"
	Identifier "aticonfig-Screen[1]-0"
	Device     "aticonfig-Device[1]-0"
	Monitor    "aticonfig-Monitor[1]-0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dooferorg on October 29, 2012, 04:01:02 PM

Well darn .. You are quite right. 'cgminer -n' does show only 1. It says that ADL doesn't match OpenCL. I read about that with the gpu-map command but am still a bit confused.

I have the entries with their PCI IDs in the xorg.conf that match with the output of 'aticonfig --list-adapters'. I shouldn't need 'dummy plugs' to get the other adapter to work, should I?

Right, you shouldn't need dummy plugs unless you have a driver before about 11.6 or something. I still suspect your xorg config. is wrong, or you're not really exporting the display variable. Also it's worth noting people have had looots of trouble with recent drivers and last good was something like 12.8. Can you show us the actual output from cgminer -n ?

dooferorg

full member

Activity: 163

Merit: 100

Quote from: -ck on October 29, 2012, 03:34:22 PM

Quote from: dooferorg on October 29, 2012, 12:31:53 PM

I'm using cgminer on Linux for the particular machine I'm discussing here. It had one 5870 card in it and I was getting ~430Mh/s out of it. Not too bad.

I happened to get my hands on another 5870 so I thought I'd pop that in too. I have both GPUs turning up in cgminer (after a little trouble, but 'aticonfig -f --adapter=all --initial' worked wonders.

I have cgminer 2.8.7 (same behavior with 2.8.5), AMD SDK 2.7 and Catalyst 12.10.

If I only enable one GPU, I get the hashrate as before. If I enable both GPUs, the first GPUs hashrate plummets. Net result is I'm still only getting the same hashrate but now it's 'using' both GPUs.

e.g.
GPU 0: ~400Mh
GPU 1: OFF

to

GPU 0: ~100Mh
GPU 1: ~300Mh

Actually sounds like it's still only mining on the one GPU, just splitting it into two. What does 'cgminer -n' say?

Well darn .. You are quite right. 'cgminer -n' does show only 1. It says that ADL doesn't match OpenCL. I read about that with the gpu-map command but am still a bit confused.

I have the entries with their PCI IDs in the xorg.conf that match with the output of 'aticonfig --list-adapters'. I shouldn't need 'dummy plugs' to get the other adapter to work, should I?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dooferorg on October 29, 2012, 12:31:53 PM

I'm using cgminer on Linux for the particular machine I'm discussing here. It had one 5870 card in it and I was getting ~430Mh/s out of it. Not too bad.

I happened to get my hands on another 5870 so I thought I'd pop that in too. I have both GPUs turning up in cgminer (after a little trouble, but 'aticonfig -f --adapter=all --initial' worked wonders.

I have cgminer 2.8.7 (same behavior with 2.8.5), AMD SDK 2.7 and Catalyst 12.10.

If I only enable one GPU, I get the hashrate as before. If I enable both GPUs, the first GPUs hashrate plummets. Net result is I'm still only getting the same hashrate but now it's 'using' both GPUs.

e.g.
GPU 0: ~400Mh
GPU 1: OFF

to

GPU 0: ~100Mh
GPU 1: ~300Mh

Actually sounds like it's still only mining on the one GPU, just splitting it into two. What does 'cgminer -n' say?

burger

full member

Activity: 195

Merit: 100

Quote from: dooferorg on October 29, 2012, 12:31:53 PM

I'm using cgminer on Linux for the particular machine I'm discussing here. It had one 5870 card in it and I was getting ~430Mh/s out of it. Not too bad.

I happened to get my hands on another 5870 so I thought I'd pop that in too. I have both GPUs turning up in cgminer (after a little trouble, but 'aticonfig -f --adapter=all --initial' worked wonders.

I have cgminer 2.8.7 (same behavior with 2.8.5), AMD SDK 2.7 and Catalyst 12.10.

If I only enable one GPU, I get the hashrate as before. If I enable both GPUs, the first GPUs hashrate plummets. Net result is I'm still only getting the same hashrate but now it's 'using' both GPUs.

e.g.
GPU 0: ~400Mh
GPU 1: OFF

to

GPU 0: ~100Mh
GPU 1: ~300Mh

Anyone else had this problem? It's really frustrating. I've tried an older AMD SDK (2.5) but even with reboots, driver reinstallation and cgminer recompilation it simply makes cgminer segfault on startup.

Any hints would be really appreciated.

EDIT: I realized I left out some information that might help.

I am using 'phatk' kernel, worksize 256, vectors 2 and the variables:

export DISPLAY=:0
export GPU_USE_SYNC_OBJECTS=1

are set before cgminer runs. CPU usage seems high though (Xorg is the top), which is concerning. The CPU in the system is an AMD FX 4170 (4.2Ghz) quad core.

You might have to use other intensity for that, I get high cpu usuage when intensity is at 1 on windows and cpu at about 0% with I: 9.

dooferorg

full member

Activity: 163

Merit: 100

I'm using cgminer on Linux for the particular machine I'm discussing here. It had one 5870 card in it and I was getting ~430Mh/s out of it. Not too bad.

I happened to get my hands on another 5870 so I thought I'd pop that in too. I have both GPUs turning up in cgminer (after a little trouble, but 'aticonfig -f --adapter=all --initial' worked wonders.

I have cgminer 2.8.7 (same behavior with 2.8.5), AMD SDK 2.7 and Catalyst 12.10.

If I only enable one GPU, I get the hashrate as before. If I enable both GPUs, the first GPUs hashrate plummets. Net result is I'm still only getting the same hashrate but now it's 'using' both GPUs.

e.g.
GPU 0: ~400Mh
GPU 1: OFF

to

GPU 0: ~100Mh
GPU 1: ~300Mh

Anyone else had this problem? It's really frustrating. I've tried an older AMD SDK (2.5) but even with reboots, driver reinstallation and cgminer recompilation it simply makes cgminer segfault on startup.

Any hints would be really appreciated.

EDIT: I realized I left out some information that might help.

I am using 'phatk' kernel, worksize 256, vectors 2 and the variables:

export DISPLAY=:0
export GPU_USE_SYNC_OBJECTS=1

are set before cgminer runs. CPU usage seems high though (Xorg is the top), which is concerning. The CPU in the system is an AMD FX 4170 (4.2Ghz) quad core.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

My highest (failed) share since it was added a few weeks ago is 802K (a week after my last block)
[2012-10-29 14:24:49] Accepted 000014e8 Diff 802K/1 MMQ 0 pool 0
(11.5 hours ago - an MMQ mining on OzCoin)
That one was 1 bit away from being a block ...

But when they aren't blocks and the higher they get - the worse it is Sad

The highest difficulty share ever found will of course be in the blockchain already - but no idea which block it was - just get all the block hashes and sort them

Should be somewhere in the 100M to 1Billion range.
Though ... soon all blocks will be at least in that range ...

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: -ck on October 28, 2012, 03:51:01 PM

I got a share that registered a diff of 7.58M Grin

That was a block solve for mtred since current difficulty is just over 3 million.

Woah, I was gonna make a thread aobut "whats the hardest share you've seen"
Mine is 901...
You had a 7580000 difficulty share? Woah.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: -ck on October 29, 2012, 06:34:45 AM

By the way I spotted that it is still possible for a few untracked shares to rarely show up, but for the most part it is only a cosmetic issue and is corrected in the current git tree.

I've added a 2.8.7b to my downloads that is 2.8.7 + commit e19c5d9d

2.8.7b includes the extra commit coz I was seeing the untracked shares ... and this resolved it.

There's no work lost with 2.8.7a so no need to change unless you want to get rid of the occasional incorrect message when mining using stratum.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

By the way I spotted that it is still possible for a few untracked shares to rarely show up, but for the most part it is only a cosmetic issue and is corrected in the current git tree.

dietwice

newbie

Activity: 58

Merit: 0

Quote from: -ck on October 29, 2012, 01:00:47 AM

Quote from: dietwice on October 29, 2012, 12:58:45 AM

Quote from: -ck on October 29, 2012, 12:00:58 AM

Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

I connect cgminer to the mining_proxy which itself connects to the Slush's pool.
Both connections are via Stratum.
This way I get cgminer stable on network outages.

Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum.

Yes, being a local proxy it responds quickly which is why you can reproduce it. Try 2.8.7 please.

Trying.
No more "untracked" shares

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

cut/paste ...

2.8.7

... like he said above ...

No one had already downloaded 2.8.6a it would appear except me to test the download
So I deleted it and put up 2.8.7a

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dietwice on October 29, 2012, 12:58:45 AM

Quote from: -ck on October 29, 2012, 12:00:58 AM

Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

I connect cgminer to the mining_proxy which itself connects to the Slush's pool.
Both connections are via Stratum.
This way I get cgminer stable on network outages.

Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum.

Yes, being a local proxy it responds quickly which is why you can reproduce it. Try 2.8.7 please.

dietwice

newbie

Activity: 58

Merit: 0

Quote from: -ck on October 29, 2012, 12:00:58 AM

Quote from: -ck on October 28, 2012, 11:36:30 PM

Quote from: dietwice on October 28, 2012, 11:32:05 PM

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.

That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was.

Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

I connect cgminer to the mining_proxy which itself connects to the Slush's pool.
Both connections are via Stratum.
This way I get cgminer stable on network outages.

Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Hold on while I respin the 2.8.6 release as 2.8.7 Roll Eyes

... it hasn't been out that long Tongue

Pretend you didn't see anything...

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on October 28, 2012, 11:36:30 PM

Quote from: dietwice on October 28, 2012, 11:32:05 PM

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.

That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was.

Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dietwice on October 28, 2012, 11:32:05 PM

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.

That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was.

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