Bitcoin Forum
December 07, 2016, 10:54:08 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4821091 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.
coblee
Donator
Legendary
*
Offline Offline

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
July 17, 2011, 12:15:20 PM
 #181

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!

1481108048
Hero Member
*
Offline Offline

Posts: 1481108048

View Profile Personal Message (Offline)

Ignore
1481108048
Reply with quote  #2

1481108048
Report to moderator
1481108048
Hero Member
*
Offline Offline

Posts: 1481108048

View Profile Personal Message (Offline)

Ignore
1481108048
Reply with quote  #2

1481108048
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481108048
Hero Member
*
Offline Offline

Posts: 1481108048

View Profile Personal Message (Offline)

Ignore
1481108048
Reply with quote  #2

1481108048
Report to moderator
1481108048
Hero Member
*
Offline Offline

Posts: 1481108048

View Profile Personal Message (Offline)

Ignore
1481108048
Reply with quote  #2

1481108048
Report to moderator
1481108048
Hero Member
*
Offline Offline

Posts: 1481108048

View Profile Personal Message (Offline)

Ignore
1481108048
Reply with quote  #2

1481108048
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
July 17, 2011, 12:17:45 PM
 #182

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
July 17, 2011, 12:22:46 PM
 #183

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?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
coblee
Donator
Legendary
*
Offline Offline

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
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.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
July 17, 2011, 12:32:19 PM
 #185

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
dostortugas
Jr. Member
*
Offline Offline

Activity: 36


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

19mX5f3YzMSWpDmEwznJNkPBnMSjcTGjPc
coblee
Donator
Legendary
*
Offline Offline

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
July 17, 2011, 05:36:28 PM
 #187

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
Donator
Legendary
*
Offline Offline

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
July 17, 2011, 06:21:05 PM
 #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.

dishwara
Legendary
*
Offline Offline

Activity: 1372

Truth may get delay, but NEVER fails


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



View Profile WWW
July 17, 2011, 09:04:00 PM
 #190

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: 98


View Profile
July 17, 2011, 09:33:10 PM
 #191

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
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
July 17, 2011, 09:41:23 PM
 #192

[...]
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: 1078


firstbits.com/1ce5j


View Profile WWW
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?

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
dostortugas
Jr. Member
*
Offline Offline

Activity: 36


View Profile
July 18, 2011, 07:21:47 AM
 #195

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

19mX5f3YzMSWpDmEwznJNkPBnMSjcTGjPc
xcooling
Full Member
***
Offline Offline

Activity: 145


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

xcooling
Full Member
***
Offline Offline

Activity: 145


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

EskimoBob
Legendary
*
Offline Offline

Activity: 910


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


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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
July 18, 2011, 10:42:53 AM
 #200

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?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine 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 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!