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

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: -ck on December 26, 2011, 09:00:07 PM

Spacing of even values that do exist is not exactly fixed width... Imposing a fixed width one way or another will just lead to other formatting issues :\

Well it is less of an issue now w/ RPC patch being integrated. I can see web and other GUI front ends handling it more elegently but I am pretty sure console/terminal uses a fixed width font. Right?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Spacing of even values that do exist is not exactly fixed width... Imposing a fixed width one way or another will just lead to other formatting issues :\

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Proofer on December 26, 2011, 07:23:36 PM

Now here's a real biggie...

Code:

 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: 73.0C 3858RPM | 326.7/326.1Mh/s | A:683 R:6 HW:0 U:4.83/m I:9
 GPU 1: 77.0C | 328.8/327.4Mh/s | A:631 R:4 HW:0 U:4.46/m I:9
 GPU 2: 73.5C 3140RPM | 337.0/327.9Mh/s | A:626 R:5 HW:0 U:4.43/m I:9
 GPU 3: 68.5C | 338.3/324.8Mh/s | A:586 R:1 HW:0 U:4.14/m I:9
 GPU 4: 73.0C 2780RPM | 319.6/327.3Mh/s | A:656 R:4 HW:0 U:4.64/m I:9
 GPU 5: 77.0C | 333.3/327.3Mh/s | A:642 R:4 HW:0 U:4.54/m I:9

For the second GPU in each card I'd like the (non-existent) fan RPM to be replaced by spaces so that the following columns align for all the GPUs.

I give a +1 on that.

Even better would be to generally speaking replace any null value was replaced w/ spaces. I have one GPU which for some reason doesn't report any temp which further fraks the spacing.

Proofer

member

Activity: 266

Merit: 36

Now here's a real biggie...

Code:

 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: 73.0C 3858RPM | 326.7/326.1Mh/s | A:683 R:6 HW:0 U:4.83/m I:9
 GPU 1: 77.0C | 328.8/327.4Mh/s | A:631 R:4 HW:0 U:4.46/m I:9
 GPU 2: 73.5C 3140RPM | 337.0/327.9Mh/s | A:626 R:5 HW:0 U:4.43/m I:9
 GPU 3: 68.5C | 338.3/324.8Mh/s | A:586 R:1 HW:0 U:4.14/m I:9
 GPU 4: 73.0C 2780RPM | 319.6/327.3Mh/s | A:656 R:4 HW:0 U:4.64/m I:9
 GPU 5: 77.0C | 333.3/327.3Mh/s | A:642 R:4 HW:0 U:4.54/m I:9

For the second GPU in each card I'd like the (non-existent) fan RPM to be replaced by spaces so that the following columns align for all the GPUs.

Proofer

member

Activity: 266

Merit: 36

cgminer version 2.0.8 - Started: [2011-12-26 13:59:18]
--------------------------------------------------------------------------------
(5s):1969.2 (avg):1958.5 Mh/s | Q:1776 A:3438 R:19 HW:0 E:194% U:27.02/m

For the bolded output E:...% I haven't found documentation in the 2.0.8 README. I'm curious.

Also... The G runtime command output starts thus:

GPU 0: 330.0 / 325.9 Mh/s | A:592 R:5 HW:0 U:4.82/m I:9
72.5 C F: 64% (3885 RPM) E: 725 MHz M: 190 Mhz V: 1.050V A: 99% P: 0%

but,

Quote from: README

G gives you something like:

GPU 0: [124.2 / 191.3 Mh/s] [Q:212 A:77 R:33 HW:0 E:36% U:1.73/m]
Temp: 67.0 C
[etc.]

...which contains that mysterious (to me) E% that is not in my 2.0.8 G output.

ancow

full member

Activity: 373

Merit: 100

Quote from: ?? on ??

Con it looks there are files missing as I tried last night and just today and get the same error on ubuntu 11.04 when building.

Works fine here (debian testing).

Quote from: ?? on ??

Code:

miner6@miner6:~/src/cgminer$ CFLAGS="-O2 -Wall -march=native -I/home/miner6/AMD-APP-SDK-v2.4-lnx64/include>" LDFLAGS="-L/home/miner6/AMD-APP-SDK-v2.4-lnx64/lib/x86_64>" ./configure

There's an error in that line: after the include and linker paths, there are superfluous '>'.

P4man

hero member

Activity: 518

Merit: 500

Quote from: bronan on December 26, 2011, 06:19:32 PM

Second i see with the cgminer 2.0.8 indeed a lot of rejects after some time, sometimes even showing all being rejects
And sometimes i saw cgminer constant reporting longpoll and not accepting work for a long time (5 to 145 minutes)
As a solution i allways restarted cgminer which if you press q ends in a hanging window.

Same here, reported it twice. Although I dont think cgminer hung on me. It just kept switching pools and complaining it couldnt connect to any of them, even though it was not a network connectivity issue (restarting routers didnt help, restarting cgminer solved it on every machine while the others where still in limbo).

My only guess at this point is that it happens when my public IP changes, which seems to be very random and rather rare (few times per month). Im monitoring that now to confirm.

bronan

hero member

Activity: 774

Merit: 500

Lazy Lurker Reads Alot

First of all regarding card memory speeds
My 5870 or 5970 was as it seemed gaining stability and lesser errors when i run them with 300 Mhz instead of 175 Mhz

Second i see with the cgminer 2.0.8 indeed a lot of rejects after some time, sometimes even showing all being rejects
And sometimes i saw cgminer constant reporting longpoll and not accepting work for a long time (5 to 145 minutes)
As a solution i allways restarted cgminer which if you press q ends in a hanging window.
But at some moments my system completely hanged on cgminer

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: P4man on December 26, 2011, 06:15:09 AM

Quote from: Turbor on December 26, 2011, 06:02:05 AM

I was wondering lately why my 6670 had a stale rate of nearly 10%. I switched the pool (nr 1 in poollist) and everything was fine for that card. Did the same on my other rig but out of nowhere i had stale rates up to 8% ! How was that possible ? I read then a post from p4man. It turned out that both times i had this, the pool i was mining to was not first in the poollist. Can someone else confirm this ?

Confirmed. Though not as dramatic as your results, for me stales go from ~0.15 % to 10x more when I am mining on a pool that is not #1 in the list.

Moreover, with failover enabled it seems cgminer sends ~5% of my hashing power to my failover pool, even though the primary pool is not ever down. Seems to be related to long polling, each time there is a new block I see cgminer submitting a few shares to the backup pool. Is there a reason for that?

The rise in rejects after a longpoll appears to be a bug afterall. I believe I've fixed this in my git tree.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Proofer on December 26, 2011, 05:26:42 PM

Quote from: -ck on December 26, 2011, 05:19:20 PM

If it takes longer than 15 seconds to get a result when you first try to connect it will say down. However cgminer tries to check when a pool comes back and will recover it automatically if possible.

OK. For some reason I get the same thing on three or four consecutive starts of cgminer recently.

It might be useful to have pool ID or URL with the message.

Good idea.

Proofer

member

Activity: 266

Merit: 36

Quote from: -ck on December 26, 2011, 05:19:20 PM

If it takes longer than 15 seconds to get a result when you first try to connect it will say down. However cgminer tries to check when a pool comes back and will recover it automatically if possible.

OK. For some reason I get the same thing on three or four consecutive starts of cgminer recently.

It might be useful to have pool ID or URL with the message.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Proofer on December 26, 2011, 05:02:35 PM

[2011-12-26 13:48:01] Started cgminer 2.0.8
[2011-12-26 13:48:17] Pool down, URL or credentials invalid
[2011-12-26 13:48:17] Long-polling activated for http://us.eclipsemc.com:9009/LP
[2011-12-26 13:48:21] Accepted 00000000.e4ed299d.2a614929 GPU 4 thread 4 pool 0

but a couple of seconds later in response to the P command:

0: Enabled Alive Priority 0: http://us.eclipsemc.com:9009 User:Redacted_0
1: Enabled Alive Priority 1: http://us.eclipsemc.com:8337 User:Redacted_1
2: Enabled Alive Priority 2: http://192.168.168.103:8332 User:brec

I have only those three pools in my cgminer.conf along with:
"failover-only" : true,

Why would I be geting the "Pool down, ..." message?

If it takes longer than 15 seconds to get a result when you first try to connect it will say down. However cgminer tries to check when a pool comes back and will recover it automatically if possible.

Proofer

member

Activity: 266

Merit: 36

[2011-12-26 13:48:01] Started cgminer 2.0.8
[2011-12-26 13:48:17] Pool down, URL or credentials invalid
[2011-12-26 13:48:17] Long-polling activated for http://us.eclipsemc.com:9009/LP
[2011-12-26 13:48:21] Accepted 00000000.e4ed299d.2a614929 GPU 4 thread 4 pool 0

but a couple of seconds later in response to the P command:

0: Enabled Alive Priority 0: http://us.eclipsemc.com:9009 User:Redacted_0
1: Enabled Alive Priority 1: http://us.eclipsemc.com:8337 User:Redacted_1
2: Enabled Alive Priority 2: http://192.168.168.103:8332 User:brec

I have only those three pools in my cgminer.conf along with:
"failover-only" : true,

Why would I be geting the "Pool down, ..." message?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Proofer on December 26, 2011, 12:50:50 PM

Quote from: DeathAndTaxes on December 26, 2011, 12:45:41 PM

t boot isn't a good time to test. There may be something going on in the boot process which is maxing CPU load. Look at load at idle after boot is complete. A 5970 at idle should be pulling ~50W. At load (w/ memclock down to 190Mhz) I measured load at ~260W. So when going from idle to full mining load wattage should increase by about 200W per card. If that isn't happening then likely something "weird" is going on w/ your 5970s in that they aren't going into lower wattage idle state raising boot/idle load.

Honestly if that is the case it likely isn't that big of a deal on a dedicated miner as wattage under full load matters more. On 3x 5970 rig w/ sempron, linux on usb key, 2GB RAM, and 80-Plus Gold PSU I get 870W at the wall. Others have gotten similar results (>2.5MH/W) so it can be done.

I wasn't clear... it jumps during boot and stays there... currently the system is idling at a 527W draw. I wonder if something (driver, cgminer, whatever) in my prior experimentation caused the 5970s to change their idle power draw, or more usefully whether there's something I can do to restore it/them.

We likely should take this to a new thread.

Proofer

member

Activity: 266

Merit: 36

Quote from: DeathAndTaxes on December 26, 2011, 12:45:41 PM

t boot isn't a good time to test. There may be something going on in the boot process which is maxing CPU load. Look at load at idle after boot is complete. A 5970 at idle should be pulling ~50W. At load (w/ memclock down to 190Mhz) I measured load at ~260W. So when going from idle to full mining load wattage should increase by about 200W per card. If that isn't happening then likely something "weird" is going on w/ your 5970s in that they aren't going into lower wattage idle state raising boot/idle load.

Honestly if that is the case it likely isn't that big of a deal on a dedicated miner as wattage under full load matters more. On 3x 5970 rig w/ sempron, linux on usb key, 2GB RAM, and 80-Plus Gold PSU I get 870W at the wall. Others have gotten similar results (>2.5MH/W) so it can be done.

I wasn't clear... it jumps during boot and stays there... currently the system is idling at a 527W draw. I wonder if something (driver, cgminer, whatever) in my prior experimentation caused the 5970s to change their idle power draw, or more usefully whether there's something I can do to restore it/them.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Proofer on December 26, 2011, 12:29:41 PM

Quote from: DeathAndTaxes on December 26, 2011, 12:15:38 PM

If you want to experiment I strongly recommend getting a kill-a-watt. It is entirely possible 5970 could run much lower than 190MHz.

I have a Kill-A-Watt. Off topic, but I can't think of a better crowd to ask... Seems to me I recall the rig in its infancy ten days ago was consistently drawing roughly 260W before I started started trying to mine. Now on power-up it's 260W, but during the Ubuntu 11.04 boot process it jumps to 500W. This is at the moment a clean OS install (except for /home on a separate partition). I can't imagine what's consuming the additional 240W other than the 5970s, but I'm at a loss as to why.

At boot isn't a good time to test. There may be something going on in the boot process which is maxing CPU load. Look at load at idle after boot is complete. A 5970 at idle should be pulling ~50W. At load (w/ memclock down to 190Mhz) I measured load at ~260W. So when going from idle to full mining load wattage should increase by about 200W per card. If that isn't happening then likely something "weird" is going on w/ your 5970s in that they aren't going into lower wattage idle state raising boot/idle load.

Honestly if that is the case it likely isn't that big of a deal on a dedicated miner as wattage under full load matters more. On 3x 5970 rig w/ sempron, linux on usb key, 2GB RAM, and 80-Plus Gold PSU I get 870W at the wall. Others have gotten similar results (>2.5MH/W) so it can be done.

Proofer

member

Activity: 266

Merit: 36

Quote from: DeathAndTaxes on December 26, 2011, 12:15:38 PM

If you want to experiment I strongly recommend getting a kill-a-watt. It is entirely possible 5970 could run much lower than 190MHz.

I have a Kill-A-Watt. Off topic, but I can't think of a better crowd to ask... Seems to me I recall the rig in its infancy ten days ago was consistently drawing roughly 260W before I started started trying to mine. Now on power-up it's 260W, but during the Ubuntu 11.04 boot process it jumps to 500W. This is at the moment a clean OS install (except for /home on a separate partition). I can't imagine what's consuming the additional 240W other than the 5970s, but I'm at a loss as to why.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Proofer on December 26, 2011, 12:01:15 PM

Is the 190MHz for 5970s? In a 5970 hardware topic people are reporting 800gpu/300mem, 850/300, 820/420, 930/500. I infer from the fact that a 6xxx GPU imposes a limit on the gpu-mem speed spread (cf. cgminer --gpu-memdiff option) that there's a direct relation between usable engine speed and memory speed.

I don't know for sure. Lower memory speed starts to be dimishing returns. Cutting memclock from 1000Mhz to 400Mhz saved almost 40W and reduced core temp by 3 deg (at same fan speed). 400Mhz to 190Mhz only saved another ~15W and no noticeable effect on core temps.

When I tried running <190MHz I had some system instabilities but that may have been due to other factors. Since the system was fast and stable I didn't experiment pushing it below 190Mhz. That was over 8 months ago. I haven't experimented since then. Not very scientific I know. It may be possible to push it stable below 190Mhz. If you want to experiment I strongly recommend getting a kill-a-watt. A dedicated rig w/ no monitors likely can be pushed lower than one which needs to drive physical monitors.

Proofer

member

Activity: 266

Merit: 36

Quote from: DeathAndTaxes on December 23, 2011, 07:52:40 PM

...
BEFORE overclocking you need to get that memspeed way down. Running mem @ full speed consumes a LOT of power and thus a lot of heat. High memspeed doesn't help hashing it just increases power and heat.I run @ 190 Mhz on memclock. You may need to experiment to find what results in best temp/speed combo. Also before overclocking run the system for 24 hours just to ensure it is rock solid.
...

Is the 190MHz for 5970s? In a 5970 hardware topic people are reporting 800gpu/300mem, 850/300, 820/420, 930/500. I infer from the fact that a 6xxx GPU imposes a limit on the gpu-mem speed spread (cf. cgminer --gpu-memdiff option) that there's a direct relation between usable engine speed and memory speed.

fred0

sr. member

Activity: 349

Merit: 250

Quote from: P4man on December 26, 2011, 06:15:09 AM

Moreover, with failover enabled it seems cgminer sends ~5% of my hashing power to my failover pool, even though the primary pool is not ever down. Seems to be related to long polling, each time there is a new block I see cgminer submitting a few shares to the backup pool. Is there a reason for that?

From page 1

--failover-only Don't leak work to backup pools when primary pool is lagging

I think this is what you are looking for. I am not sure of the criteria used to determine when the primary pool is lagging.

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