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

[jjiimm_64]

it seems that 2.8.4 uses gpu more aggressive...
Some of my radeon 7970 (1170/1050/65C) work well with 2.7.7 but with 2.8.4 are sick after 2-3 min btc mining.

you must have free electricity or something...  1170!  The other guy was right, lower your clock for stability.  if you run at 950 you can lower the volt to 0.949 and cut your electricity usage in half and only go down about 70Mh

[dlasher]

Interesting failure state today.

I have some (2.8.3) miners behind stratum 1.1.1 proxy.. primary pool stratum was pointed at failed. (stratum crashed). cgminer stayed connected to proxy, which stayed up. proxy couldn't get work from primary pool, stayed idle, all miners went idle, cgminer never failed down to next pools in the chain.

It would be nice to be able to set some sort of threshold.. (And shoot me conman if you already do this and I just missed it)..in cgminer.  If I don't get any work from a pool in {threshold} minutes, in spite of being TCP/UDP/etc up, I should mark it dead.  (I swear cgminer already does this for getwork.. I see messages about "pool not providing work fast enough")

(FWIW, I'm going to post something over in Slush's proxy thread, because I think his proxy should have marked itself dead, but somehow cgminer should know a pool is "starving", shouldn't it?)

[-ck]

Interesting failure state today.

I have some (2.8.3) miners behind stratum 1.1.1 proxy.. primary pool stratum was pointed at failed. (stratum crashed). cgminer stayed connected to proxy, which stayed up. proxy couldn't get work from primary pool, stayed idle, all miners went idle, cgminer never failed down to next pools in the chain.

It would be nice to be able to set some sort of threshold.. (And shoot me conman if you already do this and I just missed it)..in cgminer.  If I don't get any work from a pool in {threshold} minutes, in spite of being TCP/UDP/etc up, I should mark it dead.  (I swear cgminer already does this for getwork.. I see messages about "pool not providing work fast enough")

(FWIW, I'm going to post something over in Slush's proxy thread, because I think his proxy should have marked itself dead, but somehow cgminer should know a pool is "starving", shouldn't it?)

2 minutes. It's there already.

EDIT: The problem is the proxy may have been lying and continuing to send what looked like fresh work to cgminer. It's time to stop  using the proxy

[dlasher]

Interesting failure state today.

<snip>

2 minutes. It's there already.

Hmmm... I wonder what went wrong then.. I'll have to go back and look at logs again, see if I can dig anything up. In the mean time, I updated all the 2.8.3's to 2.8.4, hope there's magic in the upgrade.

[-ck]

I'm upgrading the status of cgminer 2.8.4 to stable status and removing 2.7.7 from the top directory. Even if some stratum bug does show up in the future, disabling stratum with --fix-protocol will still make it more stable than 2.7.7 is, and it's time to move on.

[rav3n_pl]

I'm upgrading the status of cgminer 2.8.4 to stable status and removing 2.7.7 from the top directory. Even if some stratum bug does show up in the future, disabling stratum with --fix-protocol will still make it more stable than 2.7.7 is, and it's time to move on.

Good, but Q: is still counting in some odd way

Code:

 cgminer version 2.8.4 - Started: [2012-10-19 09:35:35]
-----------------------------------------------------------------------
 (5s):5.353M (avg):14.46Mh/s | Q:12  A:63  R:0  HW:0  E:525%  U:0.2/m
 TQ: 0  ST: 1  SS: 0  DW: 11  NB: 1  LW: 3816  GF: 0  RF: 0  WU: 0.2
 Connected to http://rav3n.dtdns.net:9332 with LP as user toy.gpu
 Block: 0000005defaf82b794f28a67e56e7482...  Started: [09:35:35]
-----------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  66.0C  56%    | 14.57M/14.47Mh/s | A:63 R:0 HW:0 U:0.20/m I: 3
-----------------------------------------------------------------------

 [2012-10-19 14:54:24] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:28] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:29] Accepted 89346c22 Diff 1/1 GPU 0
 [2012-10-19 14:54:29] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:33] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:34] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:41] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:50] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:51] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:56] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:55:24] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:55:33] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:55:43] LONGPOLL from pool 0 requested work restart

It is running about 6 hrs on p2pool so Q should be over 360/hour.
Where was more than 12 blocks too...

EDIT:
Some time later O_o

Code:

 cgminer version 2.8.4 - Started: [2012-10-19 09:35:35]
--------------------------------------------------------------------------------
 (5s):14.57M (avg):13.18Mh/s | Q:66382  A:81  R:5  HW:0  E:0%  U:0.2/m
 TQ: 0  ST: 1  SS: 0  DW: 34  NB: 1  LW: 4852  GF: 18  RF: 0  WU: 0.2
 Connected to http://rav3n.dtdns.net:9332 with LP as user toy.gpu
 Block: 0000005defaf82b794f28a67e56e7482...  Started: [09:35:35]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  65.5C  54%    | 14.56M/13.18Mh/s | A:81 R:5 HW:0 U:0.17/m I: 3
--------------------------------------------------------------------------------

 [2012-10-19 17:40:57] LONGPOLL from pool 0 requested work restart

[TheHarbinger]

Con, I'll give the new build a whirl tomorrow since I was one of the ones that was having issues with dynamic difficulty.  2.7.6 is what I've been running, and has been rock solid for me, although it seems a few others still had problems.  The only thing I did notice is that if I loose my network, the queued value (Q:) shoots through the roof and then drives the efficiency (E:) down through the floor.  But it doesn't actually effect anything since those are just displayed values, and I know the queued work isn't actually increasing like a rocket ship because it can't get the work if the network is down.   

Okay, not seeing any issues with dynamic difficulty with 2.8.4, so hopefully that issue is dead and truly buried.  I'm still seeing the weird behavior with queued work after a network loss, though this is clearly a  very minor issue as it does not truly affect anything except displayed stats.

[sharky112065]

C. Kolivas

I am having trouble compiling cgminer 2.8.4 on MinGW 32 (Windows 7 x64). The last version I compiled was 2.7.5 and that version had no problems.

Compiling from "cgminer-2.8.4.tar.bz2" on your site.

Configure complains about not having any GPU/CL support.

If I remark out the following lines in configure.ac

#if test "x$ATISTREAMSDKROOT" != x; then
#   OPENCL_FLAGS="-I$ATISTREAMSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$ATISTREAMSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

#if test "x$AMDAPPSDKROOT" != x; then
#   OPENCL_FLAGS="-I$AMDAPPSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$AMDAPPSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

and then type:
autoreconf -fvi
  and then
CFLAGS="-O2 -msse2" ./configure
  and then
make

And now, cgminer 2.8.4 compiles just fine with AMD GPU support.

$ATISTREAMSDKROOT = Empty; Does not exist on MinGW 32
$AMDAPPSDKROOT = C:\Program Files (x86)\AMD APP\ and is a valid directory.
$ARCH_DIR = Empty; Does not exist on MinGW 32

There is a $PROCESSOR_ARCHITECTURE environment variable and it is set to "x86" but using this variable could be problematic as the two AMD directories are "x86" and "x86_64" and the possible settings for the variable are "x86", "AMD64", and "IA64".

I'm sure windows users that compile on MinGW will have problems with this and it should probably be fixed.

 

[nitrox]

something strange whit MULTIPOOL and LOAD BALANCE and BALANCE.

a try to mining on 3 pools whit LOAD BALANCE or BALANCE strategy and the result is the same
first : http://pool.50btc.com
second : http://pool2.50btc.com
third : http://pool.coinlab.com

result for LOAD BALANCE after several hours
first pool : 227 shares
second pool : 168 shares
third pool : 1412 shares

result for BALANCE after several hours
first pool : 213 shares
second pool : 191 shares
third pool : 1624 shares

it is a bug something ?
or i don't get right the value of BALANCE and LOAD BALANCE strategy.
why is there such a big difference between shares count ?

[-ck]

C. Kolivas

I am having trouble compiling cgminer 2.8.4 on MinGW 32 (Windows 7 x64). The last version I compiled was 2.7.5 and that version had no problems.

Compiling from "cgminer-2.8.4.tar.bz2" on your site.

Configure complains about not having any GPU/CL support.

If I remark out the following lines in configure.ac

#if test "x$ATISTREAMSDKROOT" != x; then
#   OPENCL_FLAGS="-I$ATISTREAMSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$ATISTREAMSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

#if test "x$AMDAPPSDKROOT" != x; then
#   OPENCL_FLAGS="-I$AMDAPPSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$AMDAPPSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

and then type:
autoreconf -fvi
  and then
CFLAGS="-O2 -msse2" ./configure
  and then
make

And now, cgminer 2.8.4 compiles just fine with AMD GPU support.

$ATISTREAMSDKROOT = Empty; Does not exist on MinGW 32
$AMDAPPSDKROOT = C:\Program Files (x86)\AMD APP\ and is a valid directory.
$ARCH_DIR = Empty; Does not exist on MinGW 32

There is a $PROCESSOR_ARCHITECTURE environment variable and it is set to "x86" but using this variable could be problematic as the two AMD directories are "x86" and "x86_64" and the possible settings for the variable are "x86", "AMD64", and "IA64".

I'm sure windows users that compile on MinGW will have problems with this and it should probably be fixed.

 

Yes you're not the only one to report this. Curious. I guess I can just ignore those defines on anything but linux.

[-ck]

something strange whit MULTIPOOL and LOAD BALANCE and BALANCE.

a try to mining on 3 pools whit LOAD BALANCE or BALANCE strategy and the result is the same
first : http://pool.50btc.com
second : http://pool2.50btc.com
third : http://pool.coinlab.com

result for LOAD BALANCE after several hours
first pool : 227 shares
second pool : 168 shares
third pool : 1412 shares

result for BALANCE after several hours
first pool : 213 shares
second pool : 191 shares
third pool : 1624 shares

it is a bug something ?
or i don't get right the value of BALANCE and LOAD BALANCE strategy.
why is there such a big difference between shares count ?

Bug I guess. It's extraordinarily hard balancing things out when there are vastly different ways of getting the same amount of work and handing out depending on pool configuration.
If you strictly want a fixed proportion to each pool only the rotate strategy can guarantee that.

[-ck]

Con, I'll give the new build a whirl tomorrow since I was one of the ones that was having issues with dynamic difficulty.  2.7.6 is what I've been running, and has been rock solid for me, although it seems a few others still had problems.  The only thing I did notice is that if I loose my network, the queued value (Q:) shoots through the roof and then drives the efficiency (E:) down through the floor.  But it doesn't actually effect anything since those are just displayed values, and I know the queued work isn't actually increasing like a rocket ship because it can't get the work if the network is down.   

Okay, not seeing any issues with dynamic difficulty with 2.8.4, so hopefully that issue is dead and truly buried.  I'm still seeing the weird behavior with queued work after a network loss, though this is clearly a  very minor issue as it does not truly affect anything except displayed stats.

Great thanks

I wouldn't worry about the Q value... hopefully the old getwork queue thing will be a thing of the past as pools move to better protocols like stratum.

[ice_chill]

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

[-ck]

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

[ice_chill]

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

It was stratum connection to BTC Guild. Would it help posting the crash error log ? or are they of limited use ?

[-ck]

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

It was stratum connection to BTC Guild. Would it help posting the crash error log ? or are they of limited use ?

Limited yes, useless no.

[nitrox]

Bug I guess. It's extraordinarily hard balancing things out when there are vastly different ways of getting the same amount of work and handing out depending on pool configuration.
If you strictly want a fixed proportion to each pool only the rotate strategy can guarantee that.

yes i use the rotate strategy.
just report what I saw for the record. 

[AxelMi]

Cgminer 2.8.4 crashes again on windows 7.
The funny thing is, that i am running some machines with 2.8.3 and some with 2.8.4.
All Machines are using Stratum.
the 2.8.4 machine crashes 80 Minutes later than the 2.8.3 Machines.

[amigaman]

Cgminer 2.8.4 crashes again on windows 7.
The funny thing is, that i am running some machines with 2.8.3 and some with 2.8.4.
All Machines are using Stratum.
the 2.8.4 machine crashes 80 Minutes later than the 2.8.3 Machines.

I have experienced similar, that's why my rigs have stratum proxy 1.1.1 running with 2.7.6, flawless for days without interruption, on a shaky DSL that disconnects ten times a day.
Also, higher hashrates than on 2.8.x.
I have that proxy as pool one, the pool the proxy points to as pool two and two other non-stratum pools as pool 3 and 4.
To my surprise, 98% of the work go to the proxy or the direct pool, 1% each to my reserve pools.
I have seen that after a DSL reconnect the proxy sometimes is a little picky, then after a few minutes all work resumes to it.

[Frizz23]

Cgminer 2.8.4 crashes again on windows 7.

Same here.

2.8.3 and 2.8.4 crash after approx 2 days.

Have only tried Stratum (on BTCGuild) so far.

Host: OS: Win7x64, GPU: 1 x 6970.

@ckolivas: what information can I provide to help you fix this bug?