I use cgminer version 1.2.8 and I am getting:
...
[2011-07-18 18:00:30] HTTP request failed: Empty reply from server
...
And those repeat every 60 seconds
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 838. (Read 5805677 times)
July 18, 2011, 10:04:30 AM
July 18, 2011, 10:04:02 AM
Conman, can you post the full description of what every abbreviation means?
It's in the README. 
July 18, 2011, 10:03:56 AM
Nvidia cards under win7 are working 100% with 1.2.8
How do i run cgminer to only use the cpu (disable Gpu) ? so that i can run 2 instances ? (one for cpu, one for gpu)
Also getting
How do i run cgminer to only use the cpu (disable Gpu) ? so that i can run 2 instances ? (one for cpu, one for gpu)
Also getting
Code:
[2011-07-18 17:01:37] HTTP request failed: Recv failure: Connection was rese
[2011-07-18 17:01:51] Share e34b098c accepted from GPU 0 thread 0
[2011-07-18 17:01:53] Share cad4e4ac accepted from GPU 0 thread 0
[2011-07-18 17:01:56] Share 86bbdd54 accepted from GPU 0 thread 2
[2011-07-18 17:02:03] Share 0a93ea28 accepted from GPU 0 thread 0
[2011-07-18 17:02:03] Share 1d0a2b8d accepted from GPU 0 thread 2
[2011-07-18 17:02:07] longpoll failed, sleeping for 30s
[2011-07-18 17:02:13] Share 57c1eff6 accepted from GPU 0 thread 2
[2011-07-18 17:02:22] Share ed20f93e accepted from GPU 0 thread 2
[2011-07-18 17:02:24] Share f8b59049 accepted from GPU 1 thread 3
[2011-07-18 17:02:29] Share 37edc62c accepted from GPU 1 thread 1
[2011-07-18 17:02:38] HTTP request failed: Recv failure: Connection was reset
July 18, 2011, 10:01:35 AM
Conman, can you post the full description of what every abbreviation means?
July 18, 2011, 07:42:13 AM
With the latest version from git, long polling keeps failing for deepbit. Since it is working fine with DiabloMiner, I'm assuming there's something wrong with cgminer (I changed the waiting time to 5s so that there would be less clutter between LP failure messages):
Since mining works fine, otherwise, I doubt the data I entered is incorrect.
Code:
cgminer version 1.2.8 - Started: [2011-07-18 14:29:21]
--------------------------------------------------------------------------------
[(5s):32.9 (avg):32.8 Mh/s] [Q:4 A:1 R:0 HW:0 E:25% U:0.20/m]
TQ: 0 ST: 0 LS: 0 SS: 0 DW: 0 NB: 0 LW: 0 LO: 0 RF: 0 I: 1
Connected to http://pit.deepbit.net:8332 as user [email protected]_Miner
Block 0001629b4228b4b61b8ecb6c68e0ec32 started: [2011-07-18 14:29:22]
--------------------------------------------------------------------------------
GPU 0: [32.8 Mh/s] [Q:4 A:1 R:0 HW:0 E:50% U:0.26/m]
--------------------------------------------------------------------------------
[2011-07-18 14:29:52] HTTP request failed: Failure when receiving data from the peer
[2011-07-18 14:29:57] longpoll failed, sleeping for 5s
[2011-07-18 14:31:03] longpoll failed, sleeping for 5s
[2011-07-18 14:31:38] longpoll failed, sleeping for 5s
[2011-07-18 14:32:13] longpoll failed, sleeping for 5s
[2011-07-18 14:32:44] HTTP request failed: Failure when receiving data from the peer
[2011-07-18 14:33:14] Share 4e1edfe2 accepted from GPU 0 thread 1
[2011-07-18 14:33:19] longpoll failed, sleeping for 5s
[2011-07-18 14:33:49] HTTP request failed: Failure when receiving data from the peer
[2011-07-18 14:33:54] longpoll failed, sleeping for 5s
July 18, 2011, 05:51:36 AM
Updated git tree:
The longpoll message was almost always being dropped in 1.2.8 and it thought it always detected the new block itself - should be fixed in the git tree.
It was possible to queue an ever increasing amount of staged work which would eventually lead to a rise in rejects as the shares submitted would eventually be quite old. Fixed.
The longpoll message was almost always being dropped in 1.2.8 and it thought it always detected the new block itself - should be fixed in the git tree.
It was possible to queue an ever increasing amount of staged work which would eventually lead to a rise in rejects as the shares submitted would eventually be quite old. Fixed.
July 18, 2011, 05:42:53 AM
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? cgminer.exe -I 8 on win 7 64bit : 2x 6970, AMD x6
July 18, 2011, 04:51:01 AM
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...
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...
July 18, 2011, 04:08:16 AM
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
I have a unclocked AMD Radeoon 6950
I run: -d 0 -g 2 -I 7 and it kicks ass!
Thank you ckolivas
July 18, 2011, 03:37:04 AM
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
ufasoft_cpu.exe -g no -t 6
cgminer.exe -I 8 -t 0
July 18, 2011, 03:27:25 AM
CPU + GPU = broken
cgminer.exe -I 8 on win 7 64bit : 2x 6970, AMD x6
cgminer.exe -I 8 -t 6 on win 7 64bit : 2x 6970, AMD x6
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]
--------------------------------------------------------------------------------
July 18, 2011, 02:21:47 AM
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
July 17, 2011, 09:31:53 PM
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.
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.
July 17, 2011, 05:08:18 PM
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:
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?
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?
July 17, 2011, 04:41:23 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.
).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.
July 17, 2011, 04:33:10 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:
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:
Unfortunately, I'm still getting the following error when makeing:
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
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.
July 17, 2011, 04:04:00 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:
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:
Unfortunately, I'm still getting the following error when makeing:
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
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.
July 17, 2011, 01:33:40 PM
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.
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.
July 17, 2011, 01:21:05 PM
I ran it with intensity 9 for 15 minutes:
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.
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.
July 17, 2011, 12:36:28 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
setting intensity to higher values gives me more hashes/second but less shares/minute
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.
Jump to: