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

[-ck]

Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.

[1713543881]

1713543881

[1713543881]

1713543881

[1713543881]

1713543881

[1713543881]

1713543881

[1713543881]

1713543881

[ancow]

Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.

You're right.  You probably would need an SDK version in there as well.  Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch.  But over time, SDK-cgminer versions in the bins might be the ticket.  Just an idea might be worth considering.

I don't think it is. After all, then you'd have an even harder time getting the precompiled bins ckolivas provides (assuming he still does) to run on a less optimal SDK version. This way, at least you can get a faster .bin without having to fuck up your system trying to install different SDKs.

[-ck]

You're right.  You probably would need an SDK version in there as well.  Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch.  But over time, SDK-cgminer versions in the bins might be the ticket.  Just an idea might be worth considering.

I've actually considered it in the past but the limitation was the way the SDK reported back its version: "OpenCL 1.1 AMD-APP (844.4)" for example. It's a rather long name to add to the filename and doesn't say anything about SDK 2.6, and each of linux, windows, 32, 64 bit have different versions as well (by the way cgminer tries to detect each of them but the list is getting longer every day). The only purpose it would serve is debugging for me on the forum when someone says their hashrate is slow. However, if their hashrate is slow, I can say with 101% certainty they're on SDK 2.6 or later.

[-ck]

I don't think it is. After all, then you'd have an even harder time getting the precompiled bins ckolivas provides (assuming he still does) to run on a less optimal SDK version. This way, at least you can get a faster .bin without having to fuck up your system trying to install different SDKs.

I stopped collecting these because the number of downloads was very small and I removed the directory. Part of the reason i was collecting them was that long term bug where it would fail to build the kernel .bin files (due to amazing AMD stupidity on a scale I could never have imagined). That bug has since been fixed.

[xzion]

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER

Wrong, you should downgrade your driver and read the FAQ.

the shit you go through for this software, man, i don't know how you do it.
have a couple more btc for your troubles.

[Epoch]

NEW VERSION: 2.4.0 - May 3, 2012

Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.

I'd like clarification on this point, please.

I understand that if cgminer is mining, a Single is unplugged, cgminer will continue mining. What isn't clear from the changelog is what happens when the Single is plugged back in. Will an automatic attempt be made to re-detected it? If so, will cgminer stop trying after some time limit, or will it continue the attempt indefinitely? Or is there something that needs to be done manually in the UI re-enable the device?

[ancow]

Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.

Since I'll be out for a while and haven't seen any more commits in a while here's the current git's backtrace:

Code:

Core was generated by `. cgminer -k poclbm --benchmark -I 4'.
Program terminated with signal 11, Segmentation fault.
#0  __list_add (next=0x0, prev=0x1ce2bc0, new=0x40edcc8) at elist.h:37
37              next->prev = new;
(gdb) bt
#0  __list_add (next=0x0, prev=0x1ce2bc0, new=0x40edcc8) at elist.h:37
#1  list_add (head=0x1ce2bc0, new=0x40edcc8) at elist.h:53
#2  recruit_curl (pool=0x1ce2ac0) at cgminer.c:1991
#3  pop_curl_entry (pool=0x1ce2ac0) at cgminer.c:2005
#4  0x0000000000409785 in get_work_thread (userdata=0x4146770) at cgminer.c:2046
#5  0x00007fdfb8fa7b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#6  0x00007fdfb7fb690d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

This includes https://github.com/ckolivas/cgminer/commit/852f6a0eb02f1c5a715a62e6b1142ca684aa4611 and a clean rebuild. Hopefully it'll help...

[Inaba]

It would be nice to have the ability to enable/disable a specific PGA unit.  I have a couple of slow units, but no clue which ones they are on the rack... if I could disable them, at least i could see which light switches off.

[fred0]

It would be nice to have the ability to enable/disable a specific PGA unit.  I have a couple of slow units, but no clue which ones they are on the rack... if I could disable them, at least i could see which light switches off.

You can do this using the API

https://bitcointalk.org/index.php?topic=28402.msg875407#msg875407

[twmz]

NEW VERSION: 2.4.0 - May 3, 2012

Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.

I'd like clarification on this point, please.

I understand that if cgminer is mining, a Single is unplugged, cgminer will continue mining. What isn't clear from the changelog is what happens when the Single is plugged back in. Will an automatic attempt be made to re-detected it? If so, will cgminer stop trying after some time limit, or will it continue the attempt indefinitely? Or is there something that needs to be done manually in the UI re-enable the device?

This wasn't about unplugging and plugging a device in.  It was about crashes.  If the BFL unit fails at some point (as is happening with one of mine), it used to just die and be dead forever.  Now, it goes into a disabled state and you can attempt to restart it from the API without having to completely restart cgminer.

I don't think anything has changed with hotplug support (i.e. it's still not supported).

[Epoch]

This wasn't about unplugging and plugging a device in.  It was about crashes.  If the BFL unit fails at some point (as is happening with one of mine), it used to just die and be dead forever.  Now, it goes into a disabled state and you can attempt to restart it from the API without having to completely restart cgminer.

I don't think anything has changed with hotplug support (i.e. it's still not supported).

From your description I assume you are running Linux. I'm on Windows, where cgminer 2.3.6 quits to the command prompt if a BFL dies. I'll have to do some testing of 2.4.0 to characterize its new behavior before general deployment.

Currently I launch 2.3.6 from a (Windows) batch file containing a loop; if a BFL unit dies, 2.3.6 exists and the batch file simply restarts it automatically. Works well for me, which is why I hesitate to jump onto 2.4.0 without first understanding its changed behavior.

Regarding cgminer's API, anyone have experience using it under Windows?

[jddebug]

Problem with version 2.4.0 that has been reported by one other than me.

If cgminer switches to your configured backup pool, it will not switch back on its own. At least for 2 of us.

FYI

EDIT: My config was set to --failover-only in case that has something to do with the bug.

[DutchBrat]

Problem with version 2.4.0 that has been reported by one other than me.

If cgminer switches to your configured backup pool, it will not switch back on its own. At least for 2 of us.

FYI

I experienced that on 1 of 7 mining rigs

All have the same setup, all were running 2.4.0.

So not sure what the trigger was for this to happen

All WinXp 12.4 58XX series

[bulanula]

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER

How the hell are you getting 460 MHash/s on a 5870 ?

[Cobra]

Very happy with 2.4 here.

For the longest time I had stuck to using 2.1.2 on a Win7 rig with (2) 5970's at 830/300. with -I 9, -w 256, -k phatk making 380 Mh/sec per core. It seemed as soon as I would upgrade past that version with no other changes it would drop me down to 330 Mh/sec per core. At first I thought it was because intensity of first gpu was dynamic (main daily driver PC) but changing to 9 on that had no effect.

On 2.4 simply using Diablo kernel instead I am up to 372/core which I am satisfied with. So many new changes since 2.1.2, if there are any holdouts out there I urge you to upgrade, it is worth it, you just may need to change kernels. On the old version BAMT would only see 1 of my cards via cgsnoop, that is now working properly and seeing both.

Time to donate again, 1BTC sent, keep up the great work.

[DutchBrat]

Just happened to another one of my rigs

My main pool shows as disabled, mining on my 1st backup pool, while the other rigs mine happily on my main pool

So second time today with 2 different rigs

Code:

 cgminer version 2.4.0 - Started: [2012-05-03 10:31:14]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):302.1 Mh/s | Q:4804  A:2429  R:149  HW:0  E:51%  U:4.0/m
 TQ: 1  ST: 3  SS: 50  DW: 1276  NB: 77  LW: 5384  GF: 26  RF: 26
 Connected to http://pool.ABCPool.co:8332 with LP as user XXXXXX
 Block: 000004aaff274ef6bfc969765f953f1a...  Started: [20:33:38]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2391RPM | 311.8/302.1Mh/s | A:2429 R:149 HW:0 U: 4.00/m I: 6
--------------------------------------------------------------------------------

0: Disabled Alive Priority 0: http://pool.bonuspool.co.cc:80  User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332  User:XXX
2: Enabled Alive Priority 2: http://pit.deepbit.net:8332  User:XXXX
3: Enabled Alive Priority 3: http://mine2.btcguild.com:8332  User:XXXXX

Current pool management strategy: Failover
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue

Any idea what's causing this CKolivas ?

[MrTeal]

Would it be possible to get an option to reset the stats (queued/accepted/stales and all that) without having to restart CGMiner?

[-ck]

Just happened to another one of my rigs

My main pool shows as disabled, mining on my 1st backup pool, while the other rigs mine happily on my main pool

So second time today with 2 different rigs

Code:

 cgminer version 2.4.0 - Started: [2012-05-03 10:31:14]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):302.1 Mh/s | Q:4804  A:2429  R:149  HW:0  E:51%  U:4.0/m
 TQ: 1  ST: 3  SS: 50  DW: 1276  NB: 77  LW: 5384  GF: 26  RF: 26
 Connected to http://pool.ABCPool.co:8332 with LP as user XXXXXX
 Block: 000004aaff274ef6bfc969765f953f1a...  Started: [20:33:38]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2391RPM | 311.8/302.1Mh/s | A:2429 R:149 HW:0 U: 4.00/m I: 6
--------------------------------------------------------------------------------

0: Disabled Alive Priority 0: http://pool.bonuspool.co.cc:80  User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332  User:XXX
2: Enabled Alive Priority 2: http://pit.deepbit.net:8332  User:XXXX
3: Enabled Alive Priority 3: http://mine2.btcguild.com:8332  User:XXXXX

Current pool management strategy: Failover
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue

Any idea what's causing this CKolivas ?

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable   Do not automatically disable pools that continually reject shares

[-ck]

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER

Wrong, you should downgrade your driver and read the FAQ.

the shit you go through for this software, man, i don't know how you do it.
have a couple more btc for your troubles.

Thanks a lot.

So far the fallout for a fairly substantial version upgrade hasn't been too bad.

[DutchBrat]

Just happened to another one of my rigs

My main pool shows as disabled, mining on my 1st backup pool, while the other rigs mine happily on my main pool

So second time today with 2 different rigs

Code:

 cgminer version 2.4.0 - Started: [2012-05-03 10:31:14]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):302.1 Mh/s | Q:4804  A:2429  R:149  HW:0  E:51%  U:4.0/m
 TQ: 1  ST: 3  SS: 50  DW: 1276  NB: 77  LW: 5384  GF: 26  RF: 26
 Connected to http://pool.ABCPool.co:8332 with LP as user XXXXXX
 Block: 000004aaff274ef6bfc969765f953f1a...  Started: [20:33:38]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2391RPM | 311.8/302.1Mh/s | A:2429 R:149 HW:0 U: 4.00/m I: 6
--------------------------------------------------------------------------------

0: Disabled Alive Priority 0: http://pool.bonuspool.co.cc:80  User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332  User:XXX
2: Enabled Alive Priority 2: http://pit.deepbit.net:8332  User:XXXX
3: Enabled Alive Priority 3: http://mine2.btcguild.com:8332  User:XXXXX

Current pool management strategy: Failover
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue

Any idea what's causing this CKolivas ?

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable   Do not automatically disable pools that continually reject shares

Ah thanks, that explains it !