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

ancow

full member

Activity: 373

Merit: 100

Quote from: d3m0n1q_733rz on July 17, 2011, 04:04:00 PM

Quote from: ancow on July 16, 2011, 07:26:54 PM

[...]

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.

OCedHrt

member

Activity: 111

Merit: 10

Quote from: d3m0n1q_733rz on July 17, 2011, 04:04:00 PM

Quote from: ancow on July 16, 2011, 07:26:54 PM

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.

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

Quote from: ancow on July 16, 2011, 07:26:54 PM

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.

dishwara

legendary

Activity: 1855

Merit: 1016

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.

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

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.

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: dostortugas on July 17, 2011, 08:21:16 AM

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.

dostortugas

newbie

Activity: 49

Merit: 0

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: coblee on July 17, 2011, 07:26:43 AM

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.

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: coblee on July 17, 2011, 07:15:20 AM

Quote from: -ck on July 17, 2011, 06: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?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: xcooling on July 17, 2011, 07:14:03 AM

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.

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: -ck on July 17, 2011, 06: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!

xcooling

member

Activity: 145

Merit: 10

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: -ck on July 17, 2011, 06:50:36 AM

Your efficiency is particularly low. That may be the result of setting the intensity too high. Drop it from 14 to 8.

I've tried 8 and I was not getting good hashrate. Would 9 work?
Why would the hashrate reported here not be accurate versus what the pool sees?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Your efficiency is particularly low. That may be the result of setting the intensity too high. Drop it from 14 to 8.

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

And after I stopped it, here's the summary:

Code:

Summary of runtime statistics:

Started at [2011-07-17 04:12:34]
Runtime: 0 hrs : 35 mins : 37 secs
Average hashrate: 2255.4 Megahash/s
Queued work requests: 1533
Share submissions: 765
Accepted shares: 760
Rejected shares: 5
Reject ratio: 0.7
Hardware errors: 0
Efficiency (accepted / queued): 50%
Utility (accepted shares / min): 21.39/min

Discarded work due to new blocks: 18
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 4
Work items generated locally: 13
Submitting work remotely delay occasions: 0
New blocks detected on network: 5

Summary of per device statistics:

 GPU 0: [376.2 Mh/s] [Q:254  A:108  R:0  HW:0  E:43%  U:3.08/m]
 GPU 1: [375.7 Mh/s] [Q:254  A:143  R:1  HW:0  E:57%  U:4.05/m]
 GPU 2: [375.7 Mh/s] [Q:254  A:116  R:1  HW:0  E:46%  U:3.27/m]
 GPU 3: [375.7 Mh/s] [Q:253  A:123  R:2  HW:0  E:49%  U:3.51/m]
 GPU 4: [376.2 Mh/s] [Q:254  A:128  R:0  HW:0  E:50%  U:3.60/m]
 GPU 5: [376.2 Mh/s] [Q:254  A:142  R:1  HW:0  E:56%  U:4.00/m]

coblee

donator

Activity: 1654

Merit: 1354

Creator of Litecoin. Cryptocurrency enthusiast.

I have a weird problem. cgminer is reporting a hashrate that is a bit better than what I had before. BUT my pool (arsbitcoin) is reporting something much lower after I switched. And I did wait 30 minutes to make sure since the stats are for the last 10 minutes.

Here's what cgminer is showing:

Code:

 cgminer version 1.2.7 - Started: [2011-07-17 04:12:34]
--------------------------------------------------------------------------------
 [(5s):2201.5  (avg):2249.4 Mh/s] [Q:1380  A:690  R:2  HW:0  E:50%  U:21.43/m]
 TQ: 6  ST: 6  LS: 0  SS: 0  DW: 13  NB: 4  LW: 13  LO: 4  RF: 0  I: 14
 Connected to http://arsbitcoin.com:8344 as user ChocoboLee.12
 Block 0001aa09e56fefcc16d9935ed9e1e9b6  started: [2011-07-17 04:30:40]
--------------------------------------------------------------------------------
 GPU 0: [376.3 Mh/s] [Q:230  A:101  R:0  HW:0  E:44%  U:3.15/m]
 GPU 1: [376.3 Mh/s] [Q:229  A:127  R:0  HW:0  E:56%  U:3.97/m]
 GPU 2: [375.7 Mh/s] [Q:230  A:110  R:0  HW:0  E:49%  U:3.52/m]
 GPU 3: [375.7 Mh/s] [Q:229  A:115  R:1  HW:0  E:50%  U:3.58/m]
 GPU 4: [376.3 Mh/s] [Q:230  A:112  R:0  HW:0  E:49%  U:3.50/m]
 GPU 5: [376.3 Mh/s] [Q:230  A:125  R:1  HW:0  E:56%  U:3.99/m]
--------------------------------------------------------------------------------

Here's what my pool is saying:

ChocoboLee.12 Y 1460

Any ideas? I've been running this for 35 minutes. Can someone do a quick calculation to see if the amount of accepted shares is correct for my hashrate?

dikidera

full member

Activity: 126

Merit: 100

Quote from: xcooling on July 17, 2011, 04:29:46 AM

Ideal would be to add a flag to disable the gpu mining.
eg
-g 0 would disable gpu mining.

cgminer.exe -o http://localhost:8332 -u username.1 -p 1234 -t 4 -g 0

could then be used to force only cpu mining with 4 threads..

why would one want todo this: if u wanted to play a game or use the gpus for something else.. my cpu averages 40Mh/s

currently
i use bitcoin-miner.exe for cpu mining

Wow, do you have some dual xeon or something? 40 megahashes for a cpu is quite a lot.

xcooling

member

Activity: 145

Merit: 10

Ideal would be to add a flag to disable the gpu mining.
eg
-g 0 would disable gpu mining.

cgminer.exe -o http://localhost:8332 -u username.1 -p 1234 -t 4 -g 0

could then be used to force only cpu mining with 4 threads..

why would one want todo this: if u wanted to play a game or use the gpus for something else.. my cpu averages 40Mh/s

currently
i use bitcoin-miner.exe for cpu mining

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