<<  >> (p.10)
    Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5806443 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.)

    • coblee
    Donator
    Legendary
    *
    Offline Offline

    Activity: 1654
    Merit: 1356


    Creator of Litecoin. Cryptocurrency enthusiast.


    View Profile
    July 17, 2011, 12:15:20 PM
     #181
    Quote from: ckolivas on July 17, 2011, 11:56:51 AM
    Because your efficiency is low. The pool reports back what it thinks your hash rate is based on the number of accepted shares you return.

    Efficiency is just accepted share divided by requested work. A low efficiency just means that cgminer is calling more getworks than necessary. The hashrate should represent how many accepted share I generate.

    So the question still stands: why is cgminer reporting a higher hashrate? How is it calculating the hashrate if not using the accepted shares?

    Another question is what does the intensity actually mean? I'm running on a headless dedicated miner. Why not set it to 14? And why not 9 instead of 8?

    Thanks!
    Litecoin: https://litecoin.org

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4522
    Merit: 1669


    Ruu \o/


    View Profile WWW
    July 17, 2011, 12:17:45 PM
     #182
    Quote from: xcooling on July 17, 2011, 12:14:03 PM
    1.2.7 regression on nvidia cards.

    Mh/s are calculated, but after 1 hour no shares are submitted.

    With the 1.2.6 binary nvidia cards function 100%.


    win32 v1.2.7 still has problem with combined gpu+cpu mining and with cpu mining.


    Yes sorry, noted and fixed in the git tree with nvidia mining. The poclbm kernel was not updated to match the other changes and has been since fixed. Need to do a git clean -f and get the latest tree to fix it. The cpu mining issue... I dunno yet but the c algorithm seems dodgy though the assembly 64 bit one works fine here. Too much else to look at.
    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: 4522
    Merit: 1669


    Ruu \o/


    View Profile WWW
    July 17, 2011, 12:22:46 PM
     #183
    Quote from: coblee on July 17, 2011, 12:15:20 PM
    Quote from: ckolivas on July 17, 2011, 11:56:51 AM
    Because your efficiency is low. The pool reports back what it thinks your hash rate is based on the number of accepted shares you return.

    Efficiency is just accepted share divided by requested work. A low efficiency just means that cgminer is calling more getworks than necessary. The hashrate should represent how many accepted share I generate.

    So the question still stands: why is cgminer reporting a higher hashrate? How is it calculating the hashrate if not using the accepted shares?

    Another question is what does the intensity actually mean? I'm running on a headless dedicated miner. Why not set it to 14? And why not 9 instead of 8?

    Thanks!
    Efficiency 14 can take up to 15 seconds to return data from the GPU. That's a long time to not have reported back any shares. So it usually is less efficient to give such a big chunk of work to the GPU at any one time without reporting in more frequently, even though in theory it would be nice to keep the GPU as busy as possible. It's the law of diminishing returns where there doesn't seem to be any benefit beyond 8 or 9, and it starts introducing more problems.

    The hashrate reported by cgminer is just how many hashes it's doing. Nothing more, nothing less. The pool is reporting an estimated hash rate based on returns. If your returns are relatively low (for whatever reason) then the pool will think you're hashing less. Now as for why you're having a bad return, I'm not really sure, but the high intensity is only doing you harm. Are you putting in a big queue? Are you running lots of threads?
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • coblee
    Donator
    Legendary
    *
    Offline Offline

    Activity: 1654
    Merit: 1356


    Creator of Litecoin. Cryptocurrency enthusiast.


    View Profile
    July 17, 2011, 12:26:43 PM
     #184
    I was getting 760 shares in 35 minutes with cgminer. With my previous poclbm, I got 960 shares in 35 minutes. So I'm definitely returning less shares with cgminer at I 14. I will change it to I 8/9 and test it. But I won't have time to do that for until maybe 8 hours later. I will report back what I find out.

    Is it possible that I'm doing that many hashes but not reporting back to the pool all the hashes I found? Are some hashes lost when intensity is set so high? It would be nice if that information is captured somewhere.
    Litecoin: https://litecoin.org

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4522
    Merit: 1669


    Ruu \o/


    View Profile WWW
    July 17, 2011, 12:32:19 PM
     #185
    Quote from: coblee on July 17, 2011, 12:26:43 PM
    I was getting 760 shares in 35 minutes with cgminer. With my previous poclbm, I got 960 shares in 35 minutes. So I'm definitely returning less shares with cgminer at I 14. I will change it to I 8/9 and test it. But I won't have time to do that for until maybe 8 hours later. I will report back what I find out.

    Is it possible that I'm doing that many hashes but not reporting back to the pool all the hashes I found? Are some hashes lost when intensity is set so high? It would be nice if that information is captured somewhere.

    No hashes should be lost. It doesn't work that way. It queues everything asynchronously for upload in a separate thread that has nothing to do with the hashing so everything eventually gets pushed to the server if it was found.
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • dostortugas
    Newbie
    *
    Offline Offline

    Activity: 49
    Merit: 0


    View Profile
    July 17, 2011, 01:21:16 PM
     #186
    FYI (for coblee in special)
    3h and a bit into work
    about a third of coblee's hash rate but ~half of his shares/minute
    Code:
    [(5s):730.5  (avg):734.3 Mh/s] [Q:3332  A:2868  R:10  HW:0  E:86%  U:9.88/m]
     TQ: 5  ST: 5  LS: 0  SS: 0  DW: 91  NB: 36  LW: 41  LO: 13  RF: 0  I: 9
     Block 00014b8ee2314e0f883f034dff1e4a0f  started: [2011-07-17 15:08:25]
    --------------------------------------------------------------------------------
     GPU 0: [372.6 Mh/s] [Q:1660  A:1442  R:5  HW:0  E:87%  U:4.97/m]
     GPU 1: [361.9 Mh/s] [Q:1619  A:1426  R:5  HW:0  E:88%  U:4.91/m]


    setting intensity to higher values gives me more hashes/second but less shares/minute

  • coblee
    Donator
    Legendary
    *
    Offline Offline

    Activity: 1654
    Merit: 1356


    Creator of Litecoin. Cryptocurrency enthusiast.


    View Profile
    July 17, 2011, 05:36:28 PM
     #187
    Quote from: dostortugas on July 17, 2011, 01:21:16 PM
    FYI (for coblee in special)
    3h and a bit into work
    about a third of coblee's hash rate but ~half of his shares/minute
    Code:
    [(5s):730.5  (avg):734.3 Mh/s] [Q:3332  A:2868  R:10  HW:0  E:86%  U:9.88/m]
     TQ: 5  ST: 5  LS: 0  SS: 0  DW: 91  NB: 36  LW: 41  LO: 13  RF: 0  I: 9
     Block 00014b8ee2314e0f883f034dff1e4a0f  started: [2011-07-17 15:08:25]
    --------------------------------------------------------------------------------
     GPU 0: [372.6 Mh/s] [Q:1660  A:1442  R:5  HW:0  E:87%  U:4.97/m]
     GPU 1: [361.9 Mh/s] [Q:1619  A:1426  R:5  HW:0  E:88%  U:4.91/m]


    setting intensity to higher values gives me more hashes/second but less shares/minute

    Hmm, ok. I guess I was fooled by the hashrate. ckolivas, can you also display an effective hashrate number that is based on shares per minute? That way, people can easily see that something is wrong if the effective hashrate does not match up with the theoretical hashrate. Thanks.
    Litecoin: https://litecoin.org

  • coblee
    Donator
    Legendary
    *
    Offline Offline

    Activity: 1654
    Merit: 1356


    Creator of Litecoin. Cryptocurrency enthusiast.


    View Profile
    July 17, 2011, 06:21:05 PM
    Last edit: July 17, 2011, 09:59:42 PM by coblee
     #188
    I ran it with intensity 9 for 15 minutes:

    Code:
    cgminer version 1.2.7 - Started: [2011-07-17 11:02:12]
    --------------------------------------------------------------------------------
     [(5s):1483.6  (avg):1975.2 Mh/s] [Q:464  A:436  R:1  HW:0  E:94%  U:26.96/m]
     TQ: 3  ST: 3  LS: 0  SS: 0  DW: 6  NB: 1  LW: 13  LO: 2  RF: 0  I: 9
     Connected to http://arsbitcoin.com:8344 as user ChocoboLee.11
     Block 00016e74d2aca09b32d80651d4dee587  started: [2011-07-17 11:13:05]
    --------------------------------------------------------------------------------
     GPU 0: [374.9 Mh/s] [Q:87  A:92  R:0  HW:0  E:106%  U:5.72/m]
     GPU 1: [312.7 Mh/s] [Q:75  A:82  R:0  HW:0  E:109%  U:5.10/m]
     GPU 2: [324.2 Mh/s] [Q:77  A:87  R:1  HW:0  E:113%  U:5.38/m]
     GPU 3: [320.7 Mh/s] [Q:75  A:59  R:0  HW:0  E:82%  U:4.12/m]
     GPU 4: [273.8 Mh/s] [Q:67  A:41  R:0  HW:0  E:63%  U:3.10/m]
     GPU 5: [374.9 Mh/s] [Q:88  A:77  R:0  HW:0  E:88%  U:4.79/m]
    --------------------------------------------------------------------------------

    Funny thing is my pool is seeing a higher hashrate:
    ChocoboLee.11      Y   2126

    From poclbm, I was getting 374 mhash/s or a total of 2244 mhash/s.

    So something really needs to be fixed with the hashrate display for me to use this miner. I will try intensity 8 when I get a chance.
    Litecoin: https://litecoin.org

  • dishwara
    Legendary
    *
    Offline Offline

    Activity: 1855
    Merit: 1016



    View Profile
    July 17, 2011, 06:33:40 PM
     #189
    I downloaded & tried yesterday, ran it for around 30 minutes & slush reported 300+ as hash rate, while i usually get 400+ as hash rate.
    Used phoenix phatk & slush reported 400+ again.
    Its in windows.
    I cant make it to work on Ubuntu as it asking many thing to install & no proper guide i can able to find.
    Since its just released & used different language "C "than OpenCL, hopes soon many tweaks will be found.

  • d3m0n1q_733rz
    Sr. Member
    ****
    Offline Offline

    Activity: 378
    Merit: 250



    View Profile WWW
    July 17, 2011, 09:04:00 PM
     #190
    Quote from: ancow on July 17, 2011, 12:26:54 AM
    Just tried version 1.2.7 on a rather up-to-date Mac, and OpenCL still isn't detected. For now I'm assuming the following bit in the configure file is to blame:
    Code:
    case $target in
      *-*-mingw*)
        have_x86_64=false
        have_win32=true
        PTHREAD_FLAGS=""
        ;;
      x86_64-*)
        have_x86_64=true
        ;;
      *-*-darwin*)
        have_x86_64=false
        OPENCL_FLAGS="-framework OpenCL"
            ;;
      *)
        have_x86_64=false
        ;;
    esac
    The Mac I have here is a 64bit machine and identifies itself as "x86_64-apple-darwin10.8.0", which means that the "*-*-darwin*" case is never reached.

    Changing the case statement to the following enables OpenCL:
    Code:
    case $target in
      *-*-mingw*)
        have_x86_64=false
        have_win32=true
        PTHREAD_FLAGS=""
        ;;
      x86_64-*-darwin*)
        have_x86_64=true
        OPENCL_FLAGS="-framework OpenCL"
        ;;
      x86_64-*)
        have_x86_64=true
        ;;
      *-*-darwin*)
        have_x86_64=false
        OPENCL_FLAGS="-framework OpenCL"
            ;;
      *)
        have_x86_64=false
        ;;
    esac

    Unfortunately, I'm still getting the following error when makeing:
    Code:
    gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib   -O3 -Wall -MT cgminer-main.o -MD -MP -MF .deps/cgminer-main.Tpo -c -o cgminer-main.o `test -f 'main.c' || echo './'`main.c
    In file included from main.c:34:
    compat.h:5: error: conflicting types for 'suseconds_t'
    /usr/include/sys/types.h:250: error: previous declaration of 'suseconds_t' was here
    make[2]: *** [cgminer-main.o] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    Look at the code again.  The wildcards are used to allow for the x86_64 and apple portions of the name.  In this case, *-*-darwin* translates to "anything"-"anything"-darwin"anyrevision" which means that the darwin case is being reached.  I feel that they problem you are having may be more driver or dependency related.  But kudos on trying to fix it yourself.
    Funroll_Loops, the theoretically quicker breakfast cereal!
    Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq

  • OCedHrt
    Member
    **
    Offline Offline

    Activity: 111
    Merit: 10


    View Profile
    July 17, 2011, 09:33:10 PM
     #191
    Quote from: d3m0n1q_733rz on July 17, 2011, 09:04:00 PM
    Quote from: ancow on July 17, 2011, 12:26:54 AM
    Just tried version 1.2.7 on a rather up-to-date Mac, and OpenCL still isn't detected. For now I'm assuming the following bit in the configure file is to blame:
    Code:
    case $target in
      *-*-mingw*)
        have_x86_64=false
        have_win32=true
        PTHREAD_FLAGS=""
        ;;
      x86_64-*)
        have_x86_64=true
        ;;
      *-*-darwin*)
        have_x86_64=false
        OPENCL_FLAGS="-framework OpenCL"
            ;;
      *)
        have_x86_64=false
        ;;
    esac
    The Mac I have here is a 64bit machine and identifies itself as "x86_64-apple-darwin10.8.0", which means that the "*-*-darwin*" case is never reached.

    Changing the case statement to the following enables OpenCL:
    Code:
    case $target in
      *-*-mingw*)
        have_x86_64=false
        have_win32=true
        PTHREAD_FLAGS=""
        ;;
      x86_64-*-darwin*)
        have_x86_64=true
        OPENCL_FLAGS="-framework OpenCL"
        ;;
      x86_64-*)
        have_x86_64=true
        ;;
      *-*-darwin*)
        have_x86_64=false
        OPENCL_FLAGS="-framework OpenCL"
            ;;
      *)
        have_x86_64=false
        ;;
    esac

    Unfortunately, I'm still getting the following error when makeing:
    Code:
    gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib   -O3 -Wall -MT cgminer-main.o -MD -MP -MF .deps/cgminer-main.Tpo -c -o cgminer-main.o `test -f 'main.c' || echo './'`main.c
    In file included from main.c:34:
    compat.h:5: error: conflicting types for 'suseconds_t'
    /usr/include/sys/types.h:250: error: previous declaration of 'suseconds_t' was here
    make[2]: *** [cgminer-main.o] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    Look at the code again.  The wildcards are used to allow for the x86_64 and apple portions of the name.  In this case, *-*-darwin* translates to "anything"-"anything"-darwin"anyrevision" which means that the darwin case is being reached.  I feel that they problem you are having may be more driver or dependency related.  But kudos on trying to fix it yourself.

    But the darwin case sets x86_64 to false, so it isn't going to work.
    ALL.ME  ●●●  SOCIAL NETWORK OF THE BLOCKCHAIN TIME ●●●
    ▄▄▄▬▬▄▄▄  Bounty all.me ▶ Jan 29th - May 8th 2018  ▄▄▄▬▬▄▄▄
    Facebook   ▲   Twitter   ▲   Telegram

  • ancow
    Full Member
    ***
    Offline Offline

    Activity: 373
    Merit: 100


    View Profile WWW
    July 17, 2011, 09:41:23 PM
     #192
    Quote from: d3m0n1q_733rz on July 17, 2011, 09:04:00 PM
    Quote from: ancow on July 17, 2011, 12:26:54 AM
    [...]
    Code:
    case $target in
      *-*-mingw*)
        have_x86_64=false
        have_win32=true
        PTHREAD_FLAGS=""
        ;;
      x86_64-*-darwin*)
        have_x86_64=true
        OPENCL_FLAGS="-framework OpenCL"
        ;;
      x86_64-*)
        have_x86_64=true
        ;;
      *-*-darwin*)
        have_x86_64=false
        OPENCL_FLAGS="-framework OpenCL"
            ;;
      *)
        have_x86_64=false
        ;;
    esac
    [...]

    Look at the code again.  The wildcards are used to allow for the x86_64 and apple portions of the name.  In this case, *-*-darwin* translates to "anything"-"anything"-darwin"anyrevision" which means that the darwin case is being reached.  I feel that they problem you are having may be more driver or dependency related.  But kudos on trying to fix it yourself.
    There's no fallthrough in shell, so after the "x86_64-*" condition matches, the case statement is immediately left (thanks to the ";;" in there), and the darwin statement is ignored. Also, if you read carefully, before this change it said OpenCL not detected, afterwards it is detected. This is confirmation that I'm right (and know shell scripting syntax better than you Tongue ).

    Also, the following compile error was introduced in 1.2.6/1.2.6-1 (don't know exactly which) and has nothing to do with OpenCL being detected or not.
    BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4

  • coblee
    Donator
    Legendary
    *
    Offline Offline

    Activity: 1654
    Merit: 1356


    Creator of Litecoin. Cryptocurrency enthusiast.


    View Profile
    July 17, 2011, 10:08:18 PM
     #193
    I tried my other machine with 6x 6970 at intensity 8 with all other parameters using the defaults.
    With poclbm, I normally get 399 mhash/s for each card for a total of 2394 mhash/s.

    I ran it for 15 minutes:

    Code:
    cgminer version 1.2.7 - Started: [2011-07-17 14:51:54]
    --------------------------------------------------------------------------------
     [(5s):1927.3  (avg):1989.7 Mh/s] [Q:423  A:296  R:2  HW:0  E:70%  U:20.83/m]
     TQ: 8  ST: 7  LS: 0  SS: 0  DW: 10  NB: 1  LW: 10  LO: 4  RF: 1  I: 8
     Connected to http://arsbitcoin.com:8344 as user ChocoboLee.21
     Block 000119a00d89314ecd1621e344011ee7  started: [2011-07-17 15:01:23]
    --------------------------------------------------------------------------------
     GPU 0: [340.5 Mh/s] [Q:71  A:53  R:0  HW:0  E:75%  U:3.73/m]
     GPU 1: [331.3 Mh/s] [Q:70  A:49  R:0  HW:0  E:70%  U:3.45/m]
     GPU 2: [348.8 Mh/s] [Q:72  A:47  R:0  HW:0  E:66%  U:3.35/m]
     GPU 3: [369.7 Mh/s] [Q:76  A:70  R:1  HW:0  E:92%  U:4.93/m]
     GPU 4: [319.0 Mh/s] [Q:67  A:40  R:1  HW:0  E:60%  U:2.87/m]
     GPU 5: [287.0 Mh/s] [Q:62  A:44  R:0  HW:0  E:71%  U:3.58/m]
    --------------------------------------------------------------------------------

    Here's what my pool says:

    ChocoboLee.21      Y   1482   

    Have other people had success with running cgminer with 6 gpus? Is it possible that it's not able to handle all 6 efficiently? This is happening on both my machines. Should I try other things like setting number of threads per GPU?
    Litecoin: https://litecoin.org

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4522
    Merit: 1669


    Ruu \o/


    View Profile WWW
    July 18, 2011, 02:31:53 AM
     #194
    New release, version 1.2.8:
    Source tarball:
    http://ck.kolivas.org/apps/cgminer/cgminer-1.2.8.tar.bz2

    Windows build:
    http://ck.kolivas.org/apps/cgminer/cgminer-1.2.8-win32.zip

    Changes:
    - More OSX build fixes.
    - Add an sse4 algorithm to CPU mining.
    - Fix CPU mining with other algorithms not working.
    - Rename the poclbm file to ensure a new binary is built.
    - We now are guaranteed to have one fresh work item after a block change and we
    should only discard staged requests.
    - Don't waste the work we retrieve from a longpoll.
    - Provide a control lock around global bools to avoid racing on them.
    - Iterating over 1026 nonces when confirming data from the GPU is old code
    and unnecessary and can lead to repeats/stales.
    - The poclbm kernel needs to be updated to work with the change to 4k sized
    output buffers.
    - longpoll seems to work either way with post or get but some servers prefer
    get so change to httpget.


    Executive summary:
    Less rejects, less idle time at longpoll, less false messages, cpu mining fixed, nvidia gpu mining fixed, should build on osx.
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • dostortugas
    Newbie
    *
    Offline Offline

    Activity: 49
    Merit: 0


    View Profile
    July 18, 2011, 07:21:47 AM
     #195
    Quote from: coblee on July 17, 2011, 10:08:18 PM
    Have other people had success with running cgminer with 6 gpus? Is it possible that it's not able to handle all 6 efficiently? This is happening on both my machines. Should I try other things like setting number of threads per GPU?

    try -I 9 -Q 2 -g 3 for the start (aggro 9, 2 in queue 3 threads per GPU) as basic don't set anything else and then try through the different vector settings with -v
    6970 is just what I have but more shaders... (6950) for me the "basics" work and I do not set vectors by hand, you can have a look what it does when you run only 4 cores with adding -d 0 -d 1 -d 2 -d 3

    that's all I can guess from your readings

  • xcooling
    Member
    **
    Offline Offline

    Activity: 145
    Merit: 10


    View Profile
    July 18, 2011, 08:27:25 AM
     #196
    CPU + GPU = broken  Undecided


    cgminer.exe -I 8 on win 7 64bit : 2x 6970, AMD x6
    Code:
    cgminer version 1.2.8 - Started: [2011-07-18 10:11:21]
    --------------------------------------------------------------------------------
     [(5s):790.8  (avg):776.3 Mh/s] [Q:156  A:149  R:0  HW:0  E:96%  U:11.30/m]
     TQ: 2  ST: 2  LS: 0  SS: 0  DW: 0  NB: 2  LW: 0  LO: 0  RF: 0  I: 8
     Block 0001cb2d83f0716091aa77bd92889342  started: [2011-07-18 10:19:07]
    --------------------------------------------------------------------------------
     GPU 0: [389.5 Mh/s] [Q:80  A:72  R:0  HW:0  E:90%  U:5.46/m]
     GPU 1: [390.5 Mh/s] [Q:76  A:78  R:0  HW:0  E:103%  U:5.95/m]
    --------------------------------------------------------------------------------

    cgminer.exe -I 8 -t 6 on win 7 64bit : 2x 6970, AMD x6
    Code:
    cgminer version 1.2.8 - Started: [2011-07-18 10:27:35]
    --------------------------------------------------------------------------------
     [(5s):307.2  (avg):349.8 Mh/s] [Q:40  A:4  R:0  HW:0  E:10%  U:2.25/m]
     TQ: 0  ST: 0  LS: 0  SS: 0  DW: 0  NB: 1  LW: 0  LO: 0  RF: 0  I: 8
     Block 000162fb89e8989dec5746d111d3a117  started: [2011-07-18 10:28:58]
    --------------------------------------------------------------------------------
     GPU 0: [172.3 Mh/s] [Q:8  A:3  R:0  HW:0  E:38%  U:1.77/m]
     GPU 1: [171.0 Mh/s] [Q:8  A:1  R:0  HW:0  E:50%  U:2.33/m]
     CPU 0: [6.5 Mh/s] [Q:24  A:0  R:0  HW:0  E:0%  U:0.00/m]
    --------------------------------------------------------------------------------
    -- RENT MY RIGS ---
    https://www.betarigs.com/rig/1074
    https://www.betarigs.com/rig/533

  • xcooling
    Member
    **
    Offline Offline

    Activity: 145
    Merit: 10


    View Profile
    July 18, 2011, 08:37:04 AM
     #197
    Highest performance is gained by running both cgminer (gpu) and ufasoft (cpu) together.


    ufasoft_cpu.exe -g no -t 6
    cgminer.exe -I 8 -t 0
    -- RENT MY RIGS ---
    https://www.betarigs.com/rig/1074
    https://www.betarigs.com/rig/533

  • EskimoBob
    Legendary
    *
    Offline Offline

    Activity: 910
    Merit: 1000


    Quality Printing Services by Federal Reserve Bank


    View Profile
    July 18, 2011, 09:08:16 AM
     #198
    Min H/s jumped from 311 to 368.6 (avg)
    I have a unclocked AMD Radeoon 6950

    I run: -d 0 -g 2 -I 7 and it kicks ass!

    Thank you ckolivas Smiley


    While reading what I wrote, use the most friendliest and relaxing voice in your head.
    BTW, Things in BTC bubble universes are getting ugly....

  • dikidera
    Full Member
    ***
    Offline Offline

    Activity: 126
    Merit: 100


    View Profile
    July 18, 2011, 09:51:01 AM
     #199
    i have to confirm that with the latest versions, i as well cannot compile with OpenCL...weird.
    I had my MinGW window open since version 1.2.0 and earlier and since then i had my old ./configure which worked, but yesterday i closed it and lost my history with it. Now, every attempts at OpenCL fails...

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4522
    Merit: 1669


    Ruu \o/


    View Profile WWW
    July 18, 2011, 10:42:53 AM
     #200
    Quote from: xcooling on July 18, 2011, 08:27:25 AM
    CPU + GPU = broken  Undecided


    cgminer.exe -I 8 on win 7 64bit : 2x 6970, AMD x6
    Not sure, but it's likely due to the high CPU requirements of the windows build (which I can't do much about since I'm led to believe it's in the pthread library in use for the windows build). I can't reproduce the problem on linux. What happens if you run two instances of cgminer, one CPU mining and one GPU mining?
    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck
    Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 843 »
      Print  
Page 9
Viewing Page: 10

IRLBTC™ © 2025 IRLBTC.com