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

[crazyates]

i've been running 2.10.1 for over 24 hrs now w/o any issues on win 7.   

Weird, cuz I was having freezing issues of 2.9.7, but now I'm not. Been good for 24 hours now. Next time it freezes, I'll upgrade to the newest. 

[1714157289]

1714157289

[1714157289]

1714157289

[1714157289]

1714157289

[1714157289]

1714157289

[1714157289]

1714157289

[crazyates]

Also, anyone like to respond to this: https://bitcointalk.org/index.php?topic=131035.0
I'm especially interested in the network usage differences between BFGminer and CGMiner when using various protocols?

[-ck]

Also, anyone like to respond to this: https://bitcointalk.org/index.php?topic=131035.0
I'm especially interested in the network usage differences between BFGminer and CGMiner when using various protocols?

Stratum on the hostile fork of cgminer uses approximately 100x (?1000x) the bandwidth of stratum on cgminer.

[juhakall]

I've noticed two problems with stratum backup pools, that still exist on 2.10.1. The bigger problem is that stratum backup pools can become permanently dead. This is only happening on my rigs with wireless connections, so maybe it's a problem with latency / packet loss? Second problem is that with failover-only disabled, most leaked shares seem to go to my getwork backup pool, even though it's last on the list. I have two stratum backup pools with higher priority than the getwork pool, but they rarely (if ever) get leaked shares. This is only a small matter, since share leakage is very low.

I need to investigate the dead pool issue. I haven't seen it happen myself.
As for leaking shares, stratum and gbt pools actually don't leak shares at all with or without failover-only mode. You only get leakage if the primary pool is getwork and you're not in failover only mode.

Here's how the shares end up to pool 3, the only getwork pool, when primary pool connection drops:

[2012-12-16 18:14:05] Accepted 0b30f6dd Diff 22/4 GPU 0 pool 0
[2012-12-16 18:14:32] Accepted 1717f2fd Diff 11/4 GPU 0 pool 0
[2012-12-16 18:16:02] Lost 2 shares due to stratum disconnect on pool 0
[2012-12-16 18:16:37] Accepted 481563e1 Diff 3/1 GPU 1 pool 3
[2012-12-16 18:16:52] Accepted 3752b425 Diff 4/1 GPU 0 pool 3
[2012-12-16 18:16:53] Accepted ed86b60d Diff 1/1 GPU 0 pool 3
[2012-12-16 18:17:02] Pool 0 http://mint.bitminter.com:3333 not responding!
[2012-12-16 18:17:02] Switching to http://us1.eclipsemc.com:3333
[2012-12-16 18:17:16] Accepted 33ec2056 Diff 4/1 GPU 1 pool 3
[2012-12-16 18:17:24] Accepted 3c342f03 Diff 4/1 GPU 0 pool 1

Some shares go to pool 3 before cgminer switches to my first backup pool. This also happens during startup, but it's only a share or two.

"Lost 2 shares due to stratum disconnect on pool 0" happens because stratum can't handle disconnects currently, right?

[Roy Badami]

I've noticed two problems with stratum backup pools, that still exist on 2.10.1. The bigger problem is that stratum backup pools can become permanently dead. This is only happening on my rigs with wireless connections, so maybe it's a problem with latency / packet loss? Second problem is that with failover-only disabled, most leaked shares seem to go to my getwork backup pool, even though it's last on the list. I have two stratum backup pools with higher priority than the getwork pool, but they rarely (if ever) get leaked shares. This is only a small matter, since share leakage is very low.

I need to investigate the dead pool issue. I haven't seen it happen myself.
As for leaking shares, stratum and gbt pools actually don't leak shares at all with or without failover-only mode. You only get leakage if the primary pool is getwork and you're not in failover only mode.

I think this is probably the same issue that I hit.  It seems easy to reproduce. [EDIT: the dead pools issue, that is]  I have pools configured as follows (2.10.1-ish build).  Pool management is failover, failover only is disabled.

stratum+tcp://us1.eclipsemc.com:3333
stratum+tcp://us2.eclipsemc.com:3333
stratum+tcp://eustratum.ozco.in:3333
http://api.bitcoin.cz:8332 (which upgrades to Stratum anyway)

Steps to reproduce:

1. Ensure you are happily mining on pool 0, with cgminer showing all pools as alive
2. Pull the network connection and wait until cgminer declares all pools dead (may take a few minutes)
3. Restore the network connection.  cgminer will declare pool 0 alive and start mining.  Pools 1-3 remain dead indefinitely.

roy

[-ck]

Roger those comments, that gives me something to work with. Yes there is no way to reconnect stratum (yet?) and submit shares you were working on last time you were connected unfortunately.

[mdude77]

Just upgrade to 2.10.1 from 2.9.7.

The hanging problem when the connection goes down/unstable seems to be gone under windows.  Yay!!  It wasn't just stratum, btw, I saw it on my p2pool nodes as well.

However I'm having a problem with it dividing work up across my backup pools.  I had to remove one of my p2pool nodes because it was sending work to 3 nodes almost all the time.  I'm not sure why 2.9.7 was able to send all 2g/h of work to one node, and now 2.10.1 sends most, but not all of it, there, and the rest to other nodes.  Is this intended?

M

[-ck]

Just upgrade to 2.10.1 from 2.9.7.

The hanging problem when the connection goes down/unstable seems to be gone under windows.  Yay!!  It wasn't just stratum, btw, I saw it on my p2pool nodes as well.

However I'm having a problem with it dividing work up across my backup pools.  I had to remove one of my p2pool nodes because it was sending work to 3 nodes almost all the time.  I'm not sure why 2.9.7 was able to send all 2g/h of work to one node, and now 2.10.1 sends most, but not all of it, there, and the rest to other nodes.  Is this intended?

M

It's a problem with the balancing with plain non-rolltime getwork based pools in the current version. This can be alleviated with the failover-only option for the time being which can be enabled on the command line or via the menu under pools. You should hardly ever get share leakage or run out of work with the latest work scheduler anyway so I'm considering making failover only the default.

[Roy Badami]

Steps to reproduce:

1. Ensure you are happily mining on pool 0, with cgminer showing all pools as alive
2. Pull the network connection and wait until cgminer declares all pools dead (may take a few minutes)
3. Restore the network connection.  cgminer will declare pool 0 alive and start mining.  Pools 1-3 remain dead indefinitely.

roy

Just to add, in this state I see cgminer maintaining TCP connections to all pools (including the ones it thinks are still dead) and I'm 90% sure i've seen it report that pool 3 (slush) saw a new block, even when it thought pool 3 was dead.

So some part of cgminer knows the pools are alive and is talking Stratum to them, but for whatever reason they're not getting marked as alive for pool  management purporses.

roy

[-ck]

Steps to reproduce:

1. Ensure you are happily mining on pool 0, with cgminer showing all pools as alive
2. Pull the network connection and wait until cgminer declares all pools dead (may take a few minutes)
3. Restore the network connection.  cgminer will declare pool 0 alive and start mining.  Pools 1-3 remain dead indefinitely.

Just to add, in this state I see cgminer maintaining TCP connections to all pools (including the ones it thinks are still dead) and I'm 90% sure i've seen it report that pool 3 (slush) saw a new block, even when it thought pool 3 was dead.

So some part of cgminer knows the pools are alive and is talking Stratum to them, but for whatever reason they're not getting marked as alive for pool  management purporses.

And that helps too, thanks.

[Roy Badami]

[...] and I'm 90% sure i've seen it report that pool 3 (slush) saw a new block, even when it thought pool 3 was dead.

I should add, I (think I) saw that immediately after restoring the network connection.  I was assuming at the time it was just coincidence that a new block happened then - but maybe it's an artifact of the network outage...

[scifimike12]

Just wanted to report that I haven't had any crashes with 2.10.1 in the past few days (knocks on wood).   

[Unclegogi]

Hello!
cgminer 2.9.7-1 works fine on one my rig, and doesn't start on second rig, both rigs with hd79xx cards.
The error message is:

[2012-12-13 20:22:02] Started cgminer 2.9.7
[2012-12-13 20:22:02] Error -1: Getting Device IDs (num)
[2012-12-13 20:22:02] clDevicesNum returned error, no GPUs usable
All devices disabled, cannot mine!

I have tried to setup another version of graphics driver, another version of app sdk, disconnected 4 cards of 5, and I had this error message every time.
Cgminer 2.8.7, 2.9.6 and 2.9.7 work well on this rig.

Just started cgminer 2.10.1 on all my rigs and it works well.
So seems that bug is fixed...

[juhakall]

I've noticed that if primary pool is down when starting cgminer, it won't start mining there when the pool returns. I'm running 2.10.1 and pools 0 & 1 are stratum. If pool 0 goes down after startup, switching to pool 1 and back to pool 0 works fine. But if pool 0 is down during startup, cgminer doesn't switch to it when it comes back alive. The pool is marked alive and has priority 0, but cgminer keeps mining at pool 1 seemingly forever. This should be easy to reproduce: temporarily block network access to pool 0 with a firewall or hosts file, and then remove the block after cgminer has started mining on pool 1.

[Morblias]

I also noticed a problem when my stratum pool went down it switched to my backup, declared pool 0 DEAD, and when the pool came back up it never reconnected just said DEAD and kept on mining pool 1. I had to manually restart cgminer for it to show pool 0 as alive again. This was on 2.10.1

EDIT: I am using the debug version if that matters? this one (http://ck.kolivas.org/apps/cgminer/debug/): 14-Dec-2012 14:53   1.1M

[-ck]

Hopefully these issues are now fixed in git.

[tacotime]

The first stratum pool is available for scrypt:
https://bitcointalk.org/index.php?topic=92522.0

Can you please add support?  I don't know if that just involves removing the return false from detect_stratum in cgminer.c

Also, did you do anything weird to the kernel?  I lost 35% of my hash rate going to 2.10.1 from 2.8.7 with a 6970

edit: rolled back to 2.8.7 and I'm still getting weird rates -- I guess something is wrong with the 12.10 display driver or something

[cypherdoc]

darn, i went 4 days w/o a crash but today 2/3 miners win7 just shut off.

[chungenhung]

cgminer 2.10.1, Win7 x64, 12.10 driver, 2.1SDK, AMD 5850.
It hashes at full speed, but shows 0 accepted, 0 rejected shares.

When I use the same settings on cgminer 2.8.7, I got the error -42 Building Program (clBuildProgram). Is this related? But on 2.10.1, i didn't see the error message.

[-ck]

cgminer 2.10.1, Win7 x64, 12.10 driver, 2.1SDK, AMD 5850.
It hashes at full speed, but shows 0 accepted, 0 rejected shares.

When I use the same settings on cgminer 2.8.7, I got the error -42 Building Program (clBuildProgram). Is this related? But on 2.10.1, i didn't see the error message.

That driver and that SDK are incompatible. It broke that SDK after the 12.3 driver.