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

[coblee]

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!

[-ck]

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.

[-ck]

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?

[coblee]

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.

[-ck]

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.

[dostortugas]

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]

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.

[coblee]

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.

[dishwara]

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]

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.

[OCedHrt]

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.

[ancow]

[...]

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

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.

[coblee]

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?

[-ck]

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.

[dostortugas]

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]

CPU + GPU = broken 


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]
--------------------------------------------------------------------------------

[xcooling]

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

[EskimoBob]

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

[dikidera]

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]

CPU + GPU = broken 


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?