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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: DutchBrat on May 03, 2012, 01:42:07 PM

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

MrTeal

legendary

Activity: 1274

Merit: 1004

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

DutchBrat

hero member

Activity: 868

Merit: 1000

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 ?

Cobra

sr. member

Activity: 289

Merit: 250

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.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: -ck on May 03, 2012, 06:59:24 AM

Quote from: af_newbie on May 03, 2012, 06:57:00 AM

Con, sorry, maybe I was not clear. Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name. When the user upgrades to next version of cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate. When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?

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 implementing it.

bulanula

hero member

Activity: 518

Merit: 500

Quote from: OpytZabilParol on May 03, 2012, 05:27:20 AM

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 Shocked

?

DutchBrat

hero member

Activity: 868

Merit: 1000

Quote from: jddebug on May 03, 2012, 11:48:24 AM

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

jddebug

sr. member

Activity: 446

Merit: 250

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.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: twmz on May 03, 2012, 11:19:54 AM

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?

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: -ck on May 03, 2012, 06:33:01 AM

Quote from: af_newbie on May 03, 2012, 06:28:33 AM

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

I cannot seem to win with this never ending SDK upgrade fail problem. At least people have the option of keeping around a .bin file from an older SDK installation and use it on the current cgminer provided the kernel hasn't changed in the interim. No solution seems optimal, and most of the problem seems to surround the optimisation cgminer does by caching the .bin file which speeds startup of cgminer significantly. If I forced it to build the kernel every single startup, there would never be this confusion, but startup would be butt slow if you had lots of GPUs whereas now it starts hashing in the blink of an eye after the very first startup.

Con, sorry, maybe I was not clear. Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name. When the user upgrades to next version of cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate. When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?

twmz

hero member

Activity: 737

Merit: 500

Quote from: Epoch on May 03, 2012, 09:36:22 AM

Quote from: -ck on May 03, 2012, 01:43:11 AM

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).

fred0

sr. member

Activity: 349

Merit: 250

Quote from: Inaba on May 03, 2012, 09:56:32 AM

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://bitcointalksearch.org/topic/m.875407

Inaba

legendary

Activity: 1260

Merit: 1000

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.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: -ck on May 03, 2012, 06:06:23 AM

Quote from: OpytZabilParol on May 03, 2012, 06:02:38 AM

Quote

I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s

Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

ancow

full member

Activity: 373

Merit: 100

Quote from: -ck on May 03, 2012, 07:35:00 AM

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=) 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...

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: -ck on May 03, 2012, 01:43:11 AM

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?

xzion

member

Activity: 96

Merit: 10

Quote from: -ck on May 03, 2012, 05:29:13 AM

Quote from: OpytZabilParol on May 03, 2012, 05:27:20 AM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ancow on May 03, 2012, 08:17:42 AM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: af_newbie on May 03, 2012, 08:12:09 AM

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.

ancow

full member

Activity: 373

Merit: 100

Quote from: af_newbie on May 03, 2012, 08:12:09 AM

Quote from: -ck on May 03, 2012, 06:59:24 AM

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.

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