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

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: jjshabadoo on December 03, 2011, 11:48:06 PM

From what I can tell, cgminer seems to auto optimize your cards for maximum hash. Is this correct? I'm used to phoenix where you really need to tweak your settings. I'm using the basic command line code with -u I,9 and my overclock/fanspeed settings. Is there anything else I should do to get better hash rates?

Thanks.

Read the "Executive Summary" in the top post. It has allot of good suggestions on settings.

You'll need to tell CGMiner how much you want to overclock your GPU engine and underclock your GPU memory and that will still take some trial and error to get the best settings for your system.
Sam

P4man

hero member

Activity: 518

Merit: 500

Quote from: ThiagoCMC on November 29, 2011, 08:08:19 AM

I have this issue too. If I start some download which consumes 100% of my link, the miners can't reach the pool and, the hashrate slowsdown and, never come up again automatically. So, I need to stop/start cgminer.

Ive had it again today. It does seem related with bittorrent which was running overnight. Now you might expect the cause to be in the router (some routers do not cope well with bittorrent), but also this time, restarting the router didnt solve it. I had to restart all my instances of cgminer.

vapourminer

legendary

Activity: 4354

Merit: 3614

what is this "brake pedal" you speak of?

you can add a couple more pools to it if you only have one currently. couple reasons: failover if the main pool goes down and also cgminer will dribble work to the other pools if the primary cant feed it fast enough. that dribble feature (cant remember whats its called) adds up.

SleeperUnit

newbie

Activity: 52

Merit: 0

Quote from: jjshabadoo on December 03, 2011, 11:48:06 PM

From what I can tell, cgminer seems to auto optimize your cards for maximum hash. Is this correct? I'm used to phoenix where you really need to tweak your settings. I'm using the basic command line code with -u I,9 and my overclock/fanspeed settings. Is there anything else I should do to get better hash rates?

Thanks.

I hope you mean "-I 9" Undecided

And if you're underclocking the memory, then you may want to try "-w 256"

jjshabadoo

hero member

Activity: 535

Merit: 500

From what I can tell, cgminer seems to auto optimize your cards for maximum hash. Is this correct? I'm used to phoenix where you really need to tweak your settings. I'm using the basic command line code with -u I,9 and my overclock/fanspeed settings. Is there anything else I should do to get better hash rates?

Thanks.

ancow

full member

Activity: 373

Merit: 100

Edit:
Your version is pretty old, which I could have figured out earlier, seeing as how you're using centos. For the record, your video ABI version is 6.0, which is the oldest version still supported by the fglrx driver.

Quote from: JinTu on December 01, 2011, 04:44:23 PM

Yes, I am indeed using --auto-fan. I tried omitting this option (first setting the fanspeed manually with aticonfig) and it still causes the same error when I instruct cgminer to quit and X crashes.

You should know that cgminer really can't do much about it. Your backtrace suggests that fglrx does an invalid floating point operation somewhere in its "NIslands_FanCtrl_SetFanSpeedRPM" function. My first guess was that it might be to do with cgminer restoring the fan profile or something, but it might simply be triggered by decreasing the fan speed due to the decreasing temperature.
Either way, you should report this to your distro or directly to ATI since cgminer can't really fix driver errors.

JinTu

full member

Activity: 133

Merit: 100

Quote from: ancow on December 01, 2011, 01:44:47 PM

Is that with the new Xorg version (video ABI 11)? I've been having trouble with that as the fglrx driver causes a crash whenever I try to watch a video, so I downgraded Xorg and everything was fine once more.

Anyhow, your backtrace suggests that the crash has something to do with setting fan speed. Are you having cgminer manipulate that? If so, does the crash also happen when you start cgminer without --auto-fan or any other fan related options?

I'm using the latest stock version for CentOS 6: xorg-x11-server-Xorg-1.7.7-26.el6_0.3.x86_64. Grepping for ABI in my X logs I get the following:

Code:

(II) Module ABI versions:
        ABI class: X.Org Server Extension, version 2.0
        ABI class: X.Org Server Extension, version 2.0
        ABI class: X.Org Server Extension, version 2.0
        ABI class: X.Org Server Extension, version 2.0
        ABI class: X.Org Server Extension, version 2.0
        ABI class: X.Org Server Extension, version 2.0
        ABI class: X.Org Video Driver, version 6.0
        ABI class: X.Org Video Driver, version 6.0
        ABI class: X.Org ANSI C Emulation, version 0.4

Yes, I am indeed using --auto-fan. I tried omitting this option (first setting the fanspeed manually with aticonfig) and it still causes the same error when I instruct cgminer to quit and X crashes.

ancow

full member

Activity: 373

Merit: 100

Is that with the new Xorg version (video ABI 11)? I've been having trouble with that as the fglrx driver causes a crash whenever I try to watch a video, so I downgraded Xorg and everything was fine once more.

Anyhow, your backtrace suggests that the crash has something to do with setting fan speed. Are you having cgminer manipulate that? If so, does the crash also happen when you start cgminer without --auto-fan or any other fan related options?

JinTu

full member

Activity: 133

Merit: 100

Hi folks,

I have been having a rather annoying issue with X crashing when I stop cgminer with 'q' about 80% of the time. When I quit and it doesn't crash X, the mining statistics text is truncated and cgminer doesn't fully exit until I hit Ctrl-C twice.

When it crashes, I see the following in my X logs:

Code:

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x463548]
1: /usr/bin/Xorg (0x400000+0x622a9) [0x4622a9]
2: /lib64/libpthread.so.0 (0x320fe00000+0xf4c0) [0x320fe0f4c0]
3: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (NIslands_FanCtrl_SetFanSpeedRPM+0x85) [0x7f8fbddb5e55]
4: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (PHM_SetFanSpeedRPM+0x12) [0x7f8fbdd555d2]
5: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (PEM_SetFanSpeed+0x79) [0x7f8fbdd7a449]
6: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (0x7f8fbd7e3000+0x58fbeb) [0x7f8fbdd72beb]
7: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (PP_Cwdde+0x104) [0x7f8fbdd70c94]
8: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (swlPPLibAdlHandler+0xed) [0x7f8fbdd0b96d]
9: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (swlAdlDispatch+0x49) [0x7f8fbdd0a009]
10: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (0x7f8fbd7e3000+0x43cdbe) [0x7f8fbdc1fdbe]
11: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (0x7f8fbd7e3000+0x43a071) [0x7f8fbdc1d071]
12: /usr/bin/Xorg (0x400000+0x2a03c) [0x42a03c]
13: /usr/bin/Xorg (0x400000+0x2208a) [0x42208a]
14: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x320f21ec5d]
15: /usr/bin/Xorg (0x400000+0x21c49) [0x421c49]
Floating point exception at address 0x7f8fbddb5e55

Fatal server error:
Caught signal 8 (Floating point exception). Server aborting

Details about my mining rig:

CentOS 6 x86_64
Catalyst 11.11
ADL SDK 3.0
APP SDK 2.5
cgminer 2.0.8

This has been happening for me since building my new miner and may be related to my environment or cgminer itself but wanted to see if anyone else has been experiencing this issue.

P4man

hero member

Activity: 518

Merit: 500

No that wasnt it. It clearly had problems connecting to the pools and the gpus where idle most of the time.

Anyway, it only happened once and I havent been able to reproduce the problem since; but it did seem like a problem with cgminer considering the problem occurred on 2 completely different machines, different OSs, the network and internet connection was fine and restarting cgminer fixed it on both machines. Not a biggie, just reporting in case other people are seeing this.

TheMalon

member

Activity: 70

Merit: 10

Quote from: P4man on November 30, 2011, 11:33:29 AM

Quote from: phorensic on November 30, 2011, 11:31:00 AM

Sounds like bad QoS settings on your router.

Not in my case at least. Note I also restarted both my routers and it made no difference. I dont know if it was a maxing out of bandwidth that triggered the problem but its something I might test later. So far the problem only occurred once, but on both machines.

It might be only a problem of cgminer calculating the hash rate. On the server side (pool) do you see a drop in submited shares?
In my case cgminer reports a higher hash rate (impossible for my GPU) when i unzip a new version and lauch it for the first time.

P4man

hero member

Activity: 518

Merit: 500

Quote from: phorensic on November 30, 2011, 11:31:00 AM

Sounds like bad QoS settings on your router.

Not in my case at least. Note I also restarted both my routers and it made no difference. I dont know if it was a maxing out of bandwidth that triggered the problem but its something I might test later. So far the problem only occurred once, but on both machines.

phorensic

hero member

Activity: 630

Merit: 500

Quote from: ThiagoCMC on November 29, 2011, 08:08:19 AM

Quote from: P4man on November 24, 2011, 02:33:29 AM

Anyone else having trouble with cgminer 2.0.8 requiring periodic restarts to solve network issues?

I saw this morning that my hashrate was pretty much zero on both my machines and had been for an hour or so. It kept switching pools and complaining the main pool and failover pool (slush) were too slow. Hashrate of bitminter and slush pool itself was good, so it had to be me.

Checked my internet connection and it seemed fine. Restarted my routers nonetheless. No change.

Then I stopped and restarted cgminer on the linux machine, and it instantly worked smooth again, no performance or network issues, while the other miner (windows) still kept complaining about "slow to respond" and having 0 hashrate most of the time, with only short bursts of normal performance on any of the pools. Both machines are on the same LAN, so it didnt seem like a network issues. After restarting the second cgminer, it also instantly performed fine again.

Im a little confused? Ive never had this. I had cgminer 2.0.7 running for months nonstop and Ive had cgminer 2.0.8 up since it was released with no problems.

I have this issue too. If I start some download which consumes 100% of my link, the miners can't reach the pool and, the hashrate slowsdown and, never come up again automatically. So, I need to stop/start cgminer.

Sounds like bad QoS settings on your router.

Ghostofkobra

full member

Activity: 164

Merit: 100

Hi,
I am using cgminer 2.0.8 and asked this question in the slush pool thread:

Quote from: Ghostofkobra on November 28, 2011, 06:11:04 PM

XXX longpoll failed for http://api2.bitcoin.cz:8332:8404, sleeping for 30s

Is the pool using port 8404 for longpolls instead of a /LP/ like path.
In that case cgminer needs to be altered a little bit.
if not, well then where can the 8404 come from?

And i got the answers that it does but it seems like the path parsing on cgminer is not working correctly?

Quote from: slush on November 29, 2011, 11:58:37 AM

Quote from: Ghostofkobra on November 28, 2011, 06:11:04 PM

XXX longpoll failed for http://api2.bitcoin.cz:8332:8404, sleeping for 30s

Is the pool using port 8404 for longpolls instead of a /LP/ like path.

Looks like cgminer messed the parsing of URL, for some unknown reason. Port 8332 is "getwork" api, ports 8401-8410 are for LP broadcasts. That HTTP header for LP in getwork response is providing full URL for 8404 port. Can you report that to cgminer author?

Best
//GoK

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

Quote from: P4man on November 24, 2011, 02:33:29 AM

Anyone else having trouble with cgminer 2.0.8 requiring periodic restarts to solve network issues?

I saw this morning that my hashrate was pretty much zero on both my machines and had been for an hour or so. It kept switching pools and complaining the main pool and failover pool (slush) were too slow. Hashrate of bitminter and slush pool itself was good, so it had to be me.

Checked my internet connection and it seemed fine. Restarted my routers nonetheless. No change.

Then I stopped and restarted cgminer on the linux machine, and it instantly worked smooth again, no performance or network issues, while the other miner (windows) still kept complaining about "slow to respond" and having 0 hashrate most of the time, with only short bursts of normal performance on any of the pools. Both machines are on the same LAN, so it didnt seem like a network issues. After restarting the second cgminer, it also instantly performed fine again.

Im a little confused? Ive never had this. I had cgminer 2.0.7 running for months nonstop and Ive had cgminer 2.0.8 up since it was released with no problems.

I have this issue too. If I start some download which consumes 100% of my link, the miners can't reach the pool and, the hashrate slowsdown and, never come up again automatically. So, I need to stop/start cgminer.

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

Quote from: jake262144 on November 23, 2011, 06:24:03 AM

Quote from: ancow on November 22, 2011, 08:03:18 PM

Quote from: ThiagoCMC on November 22, 2011, 08:35:30 AM

Quote from: ocminer on November 17, 2011, 04:11:32 PM

100% CPU Usage Bug for me under Linux with 4 x 5870 with Catalyst 11.11 fixed !

Finally.

Not for me.

Ubuntu 11.10 64 bits
Catalyst 11.11
CGMiner 2.0.8

CGMiner consumes 120% of my CPU (core2 duo).

I'll fallback to Ubuntu 11.04 + Catalyst 11.6 + AMDAPPSDK v2.4 and CGMiner 2.0.6.

I've noticed this behaviour when using the opencl headers provided by debian and the ICD provided with the 11.11 drivers (package amd-opencl-icd in debian). Installed the app sdk from http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=125792 instead and the CPU usage is down to ~10%. (This is on a 64bit debian testing with the 11.11 driver from the repos.)

Confirmed! No more CPU hogging unless debian's headers are installed alongside amd's 11.11 drivers.

Compared to 11.6 driver I also noticed a slight performance improvement of just over 1% [HMash/s] on my VLIW4 cards. No discernible hashrate change for VLIW5.
Moreover, the power draw seems to have dropped by 3% but I've been only able to measure power draw for one mining rig - the rest are off-site.
Can anyone confirm a slight power draw decrease going from 11.6 to 11.11 driver?

I'm still enable to use CGMiner 2.0.8 at Ubuntu 11.10 with Catalyst 11.11.

CGMiner consumes 350% of my 4 core.

And the Catalyst 11.6 does not compile the fglrx module under Ubuntu 11.10.

I'm curious, how do you guys are using CGMiner 2.0.8 with Ubuntu 11.10?!?!

Thanks!
Thiago

P4man

hero member

Activity: 518

Merit: 500

Anyone else having trouble with cgminer 2.0.8 requiring periodic restarts to solve network issues?

I saw this morning that my hashrate was pretty much zero on both my machines and had been for an hour or so. It kept switching pools and complaining the main pool and failover pool (slush) were too slow. Hashrate of bitminter and slush pool itself was good, so it had to be me.

Checked my internet connection and it seemed fine. Restarted my routers nonetheless. No change.

Then I stopped and restarted cgminer on the linux machine, and it instantly worked smooth again, no performance or network issues, while the other miner (windows) still kept complaining about "slow to respond" and having 0 hashrate most of the time, with only short bursts of normal performance on any of the pools. Both machines are on the same LAN, so it didnt seem like a network issues. After restarting the second cgminer, it also instantly performed fine again.

Im a little confused? Ive never had this. I had cgminer 2.0.7 running for months nonstop and Ive had cgminer 2.0.8 up since it was released with no problems.

jake262144

full member

Activity: 210

Merit: 100

Quote from: ancow on November 22, 2011, 08:03:18 PM

Quote from: ThiagoCMC on November 22, 2011, 08:35:30 AM

Quote from: ocminer on November 17, 2011, 04:11:32 PM

100% CPU Usage Bug for me under Linux with 4 x 5870 with Catalyst 11.11 fixed !

Finally.

Not for me.

Ubuntu 11.10 64 bits
Catalyst 11.11
CGMiner 2.0.8

CGMiner consumes 120% of my CPU (core2 duo).

I'll fallback to Ubuntu 11.04 + Catalyst 11.6 + AMDAPPSDK v2.4 and CGMiner 2.0.6.

I've noticed this behaviour when using the opencl headers provided by debian and the ICD provided with the 11.11 drivers (package amd-opencl-icd in debian). Installed the app sdk from http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=125792 instead and the CPU usage is down to ~10%. (This is on a 64bit debian testing with the 11.11 driver from the repos.)

Confirmed! No more CPU hogging unless debian's headers are installed alongside amd's 11.11 drivers.

Compared to 11.6 driver I also noticed a slight performance improvement of just over 1% [HMash/s] on my VLIW4 cards. No discernible hashrate change for VLIW5.
Moreover, the power draw seems to have dropped by 3% but I've been only able to measure power draw for one mining rig - the rest are off-site.
Can anyone confirm a slight power draw decrease going from 11.6 to 11.11 driver?

UPDATE:
Power draw returned to 11.6 levels a few hours after I'd written this post, presumably after whe PSU warmed up sufficiently to affect its efficiency.
11.11 allows me to overclock my cards higher than 11.6 did, e.g. an ASUS 6950 DCII which I could only squeeze 930 MHz of, has been working fine for over a week at 945 MHz.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

LightRider

legendary

Activity: 1500

Merit: 1022

I advocate the Zeitgeist Movement & Venus Project.

This is what I'm seeing after the initial failure and then trying to restart the gpu, if it helps any:

Code:

 cgminer version 2.0.8 - Started: [2011-11-22 19:19:31]
--------------------------------------------------------------------------------
 (5s):0.0 (avg):246.0 Mh/s | Q:30  A:0  R:0  HW:0  E:0%  U:0.00/m
 TQ: 1  ST: 1  SS: 0  DW: 0  NB: 1  LW: 0  GF: 0  RF: 0
 Connected to http://pit.deepbit.net:8332 with LP as user [email protected]_gpu
 Block: 00000bbeaa82db43b223b13071fb207d...  Started: [19:19:31]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: 0.0/246.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:10
 GPU 1: DISABLED /0.0Mh/s | A:0 R:0 HW:0 U:0.00/m I:0
--------------------------------------------------------------------------------

GPU 0: 0.0 / 692.6 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:10
Last initialised: [2011-11-22 19:19:31]
Intensity: Dynamic
Thread 0: 0.0 Mh/s Disabled ALIVE
Thread 2: 0.0 Mh/s Disabled ALIVE

GPU 1: 0.0 / 0.0 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:0
Last initialised:
Intensity: Dynamic
Thread 1: 0.0 Mh/s Disabled Never started
Thread 3: 0.0 Mh/s Disabled Never started

[E]nable [D]isable [I]ntensity [R]estart GPU
Or press any other key to continue
Select GPU to attempt to restart:
0
Attempting to restart threads of GPU 0
GPU[ 02:0 01.10- /1 413-12.24 1 M9h:/2s0 |: A1:90]  R T:h0r  HeWa:d0 0  U s:t0i.
ll0 e0x/ims  It:s1,0 k
Laisltl iinnigt iita olfifs
[2e0d1:1 [-21011-12-21 119-:2220 1:91:91]9 T:h3r1e]a
Indt 2e nnos liotnyg:e Dry enxaimsitcs
Th
read 0: 0.0 Mh/s Disabled ALIVE
Thread 2: 0.0 Mh/s Enabled ALIVE

GPU 1: 0.0 / 0.0 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:0
Last initialised:
Intensity: Dynamic
Thread 1: 0.0 Mh/s Disabled Never started
Thread 3: 0.0 Mh/s Disabled Never started

[E]nable [D]isable [I]ntensity [R]estart GPU
Or press any other key to continue
[2011-11-22 19:20:19] Error: Creating Context. (clCreateContextFromType)

[2011-11-22 19:20:19] Failed to reinit GPU thread 0

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