<<  >> (p.266)
    Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5806592 times)
    This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)

    • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4606
    Merit: 1701


    Ruu \o/


    View Profile WWW
    May 03, 2012, 12:35:00 PM
     #5301
    Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • ancow
    Full Member
    ***
    Offline Offline

    Activity: 373
    Merit: 100


    View Profile WWW
    May 03, 2012, 01:17:42 PM
     #5302
    Quote from: af_newbie on May 03, 2012, 01:12:09 PM
    Quote from: ckolivas on May 03, 2012, 11: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.
    BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4606
    Merit: 1701


    Ruu \o/


    View Profile WWW
    May 03, 2012, 01:19:23 PM
     #5303
    Quote from: af_newbie on May 03, 2012, 01:12:09 PM
    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.
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4606
    Merit: 1701


    Ruu \o/


    View Profile WWW
    May 03, 2012, 01:26:47 PM
     #5304
    Quote from: ancow on May 03, 2012, 01:17:42 PM
    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.
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • xzion
    Member
    **
    Offline Offline

    Activity: 96
    Merit: 10


    View Profile
    May 03, 2012, 02:34:42 PM
     #5305
    Quote from: ckolivas on May 03, 2012, 10:29:13 AM
    Quote from: OpytZabilParol on May 03, 2012, 10: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.
    Tips: 1xzionJBueq1AkPSmexA7suWkztAkNwSs

  • Epoch
    Legendary
    *
    Offline Offline

    Activity: 922
    Merit: 1003



    View Profile
    May 03, 2012, 02:36:22 PM
    Last edit: May 03, 2012, 03:06:46 PM by Epoch
     #5306
    Quote from: ckolivas on May 03, 2012, 06: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?

  • ancow
    Full Member
    ***
    Offline Offline

    Activity: 373
    Merit: 100


    View Profile WWW
    May 03, 2012, 02:53:49 PM
     #5307
    Quote from: ckolivas on May 03, 2012, 12:35:00 PM
    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...
    BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4

  • Inaba
    Legendary
    *
    Offline Offline

    Activity: 1260
    Merit: 1000



    View Profile WWW
    May 03, 2012, 02:56:32 PM
     #5308
    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.
    If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.

  • fred0
    Sr. Member
    ****
    Offline Offline

    Activity: 349
    Merit: 250


    View Profile
    May 03, 2012, 04:07:36 PM
     #5309
    Quote from: Inaba on May 03, 2012, 02:56:32 PM
    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://bt.irlbtc.com/view/28402.msg875407#msg875407

  • twmz
    Hero Member
    *****
    Offline Offline

    Activity: 737
    Merit: 500



    View Profile
    May 03, 2012, 04:19:54 PM
     #5310
    Quote from: Epoch on May 03, 2012, 02:36:22 PM
    Quote from: ckolivas on May 03, 2012, 06: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).
    Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
    WoT, GPG

    Bitrated user: ewal.

  • Epoch
    Legendary
    *
    Offline Offline

    Activity: 922
    Merit: 1003



    View Profile
    May 03, 2012, 04:34:44 PM
     #5311
    Quote from: twmz on May 03, 2012, 04:19:54 PM
    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
    Sr. Member
    ****
    Offline Offline

    Activity: 446
    Merit: 250



    View Profile
    May 03, 2012, 04:48:24 PM
    Last edit: May 03, 2012, 05:50:56 PM by jddebug
     #5312
    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
    Hero Member
    *****
    Offline Offline

    Activity: 868
    Merit: 1000


    View Profile
    May 03, 2012, 05:14:16 PM
     #5313
    Quote from: jddebug on May 03, 2012, 04:48:24 PM
    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
    Hero Member
    *****
    Offline Offline

    Activity: 518
    Merit: 500



    View Profile
    May 03, 2012, 05:56:11 PM
     #5314
    Quote from: OpytZabilParol on May 03, 2012, 10: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 ?

  • Cobra
    Sr. Member
    ****
    Offline Offline

    Activity: 289
    Merit: 250



    View Profile
    May 03, 2012, 06:30:59 PM
     #5315
    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
    Hero Member
    *****
    Offline Offline

    Activity: 868
    Merit: 1000


    View Profile
    May 03, 2012, 06:42:07 PM
     #5316
    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
    Legendary
    *
    Offline Offline

    Activity: 1274
    Merit: 1004


    View Profile
    May 03, 2012, 08:05:17 PM
     #5317
    Would it be possible to get an option to reset the stats (queued/accepted/stales and all that) without having to restart CGMiner?

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4606
    Merit: 1701


    Ruu \o/


    View Profile WWW
    May 03, 2012, 08:58:33 PM
     #5318
    Quote from: DutchBrat on May 03, 2012, 06: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
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4606
    Merit: 1701


    Ruu \o/


    View Profile WWW
    May 03, 2012, 09:15:12 PM
     #5319
    Quote from: xzion on May 03, 2012, 02:34:42 PM
    Quote from: ckolivas on May 03, 2012, 10:29:13 AM
    Quote from: OpytZabilParol on May 03, 2012, 10: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.
    Thanks a lot.

    So far the fallout for a fairly substantial version upgrade hasn't been too bad.
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • DutchBrat
    Hero Member
    *****
    Offline Offline

    Activity: 868
    Merit: 1000


    View Profile
    May 03, 2012, 09:24:12 PM
     #5320
    Quote from: ckolivas on May 03, 2012, 08:58:33 PM
    Quote from: DutchBrat on May 03, 2012, 06: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


    Ah thanks, that explains it !
    Pages: « 1 ... 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 [266] 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 ... 843 »
      Print  
Page 265
Viewing Page: 266

IRLBTC™ © 2025 IRLBTC.com