Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 791. (Read 5805728 times)
August 29, 2011, 06:28:07 PM
Indeed as ancow said, I completely ignored that fact. bash DOES cache the location and if you remove it after you've already used it, it will stupidly continue to try and use that one.
August 29, 2011, 06:24:28 PM
When I make cgminer 1.6.1 and try to run it from the source directory (and after running make install), it returns this error:
Code:
-bash: /usr/local/bin/cgminer: No such file or directory
I'd like to point out that this is bash not finding cgminer where it expects it to. This has nothing to do with cgminer.
I'm not sure why bash would keep looking in the old location - perhaps it's somehow caching where it found it previously? Anyway, you should probably ask in some Fedora/bash forum.
You might try opening another instance of bash/whichever terminal you're using and see whether it finds cgminer in its current location then.
August 29, 2011, 06:11:42 PM
Because the least work and most portable was to add the --prefix value to the directories cgminer checks. If you grab the precompiled binary it will be set to /usr, if you don't set --prefix it will be set to /usr, if you set --prefix it will be wherever you choose and it ends up when you do 'make install'. The last part was the most important.
August 29, 2011, 06:08:30 PM
That's because it has to have some default prefix if none is specified, and (perhaps foolishly) I chose /usr since most distros install everything there (even though most configure scripts default to /usr/local, I know). Ideally it should have a custom location for kernels, in something like $prefix/lib/cgminer or share/cgminer or some other crap, but I couldn't decide where would work cross platform and my care factor dropped to negative levels once I got it working at all.
Fair enough, and I know very little about coding, but if you chose that default and I didn't override it, shouldn't the software be looking there instead of failing by looking at the distro's default? Or alternatively, if it knows the distro's default after compile, why couldn't that be imported during configure? Additionally, couldn't it check the CWD before checking/looking up the default directory? You don't have to explain/answer any of that, I just figured I'd put it all out there in case it made you think of a way to deal with that. In the meantime (or indefinitely), I have no problem using --prefix. August 29, 2011, 06:03:14 PM
You must specify your install directory with --prefix= and compile it yourself if you want to install it somewhere specific.
In case you were responding to me, I wasn't clear. I am fine with the default install path. However, historically the default install path has been /usr/local/bin and for some reason, the default install path is /usr/bin on 1.6.1, but I get the error about cgminer not being in /usr/local/bin. This is after I install (and before, obviously), and I did manually compile from source (hence the comment about configure not checking the JSON version and dealing with it appropriately [using the included source if the installed source is too old]). I will try with --prefix, and I imagine that will solve the problem, but I didn't do anything different for 1.6.1 than I did for 1.5.8. 1.5.8 installed in /usr/local/bin again after I uninstalled 1.6.1 and re-installed 1.5.8, so something it seems like is different about this version that causes that error if --prefix isn't provided in Fedora 15. August 29, 2011, 05:58:52 PM
You must specify your install directory with --prefix= and compile it yourself if you want to install it somewhere specific.
In case you were responding to me, I wasn't clear. I am fine with the default install path. However, historically the default install path has been /usr/local/bin and for some reason, the default install path is /usr/bin on 1.6.1, but I get the error about cgminer not being in /usr/local/bin. This is after I install (and before, obviously), and I did manually compile from source (hence the comment about configure not checking the JSON version and dealing with it appropriately [using the included source if the installed source is too old]). I will try with --prefix, and I imagine that will solve the problem, but I didn't do anything different for 1.6.1 than I did for 1.5.8. 1.5.8 installed in /usr/local/bin again after I uninstalled 1.6.1 and re-installed 1.5.8, so something it seems like is different about this version that causes that error if --prefix isn't provided in Fedora 15. August 29, 2011, 05:54:05 PM
2: When i start with cpu mining disabled everything works perfectly fine. But when i enable cpu mining with -t7 (8 core machine) it looses connection with the first 2 pools but after 1 minute it reconnects.
I noticed this when I last experimented with CPU mining (2-3 weeks ago). My impression was that the connection loss happens whenever a CPU thread finds a share, although I have no empirical evidence (it wasn't important enough for me to do a run with debugging enabled). August 29, 2011, 04:12:40 PM
You must specify your install directory with --prefix= and compile it yourself if you want to install it somewhere specific.
August 29, 2011, 02:24:06 PM
First I want to report an issue:
When I make cgminer 1.6.1 and try to run it from the source directory (and after running make install), it returns this error:This is happening because it installs to /usr/bin for some reason (never did that on any previous source [I never tried 1.6.0]). I assume I could potentially fix this using --with-prefix or something, but for now, I am still running 1.5.8.
EDIT: This is on Fedora 15, let me know if you need any other version information.
Second, as you have been working to clean up the compilation and installation process, I thought I'd make a suggestion... Could you make the configure script check the JSON version and appropriately set the makefile asinstead ofwhen the version of JSON is too old to compile with?
When I make cgminer 1.6.1 and try to run it from the source directory (and after running make install), it returns this error:
Code:
-bash: /usr/local/bin/cgminer: No such file or directory
EDIT: This is on Fedora 15, let me know if you need any other version information.
Second, as you have been working to clean up the compilation and installation process, I thought I'd make a suggestion... Could you make the configure script check the JSON version and appropriately set the makefile as
Code:
#JANSSON_INCLUDES =
JANSSON_INCLUDES = -I$(top_srcdir)/compat/jansson
Code:
JANSSON_INCLUDES =
#JANSSON_INCLUDES = -I$(top_srcdir)/compat/jansson
August 29, 2011, 11:45:11 AM
2: When i start with cpu mining disabled everything works perfectly fine. But when i enable cpu mining with -t7 (8 core machine) it looses connection with the first 2 pools but after 1 minute it reconnects.
I noticed this when I last experimented with CPU mining (2-3 weeks ago). My impression was that the connection loss happens whenever a CPU thread finds a share, although I have no empirical evidence (it wasn't important enough for me to do a run with debugging enabled). 
August 29, 2011, 11:40:00 AM
I never had any compile errors form cgminer so this is the first one:
Code:
.../usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/xmmintrin.h:32:3: error: #error "SSE instruction set not enabled"
That's the new 32 bit assembly cpu mining code which is only being half compiled. A workaround for the moment is to add -msse2 to your CFLAGS till I can figure out how to fix it.
Ckolivas, thank you. Looks like its fixed in 1.6.1
August 29, 2011, 10:28:38 AM
Hi,
Thanx for the work on 1.6.1.
I just switched over my miners to the new code and it seems to work well.
There are two things though...
1: Would you consider making the -t flag imply --enable-cpu (yeah its a itsy bitsy thing)
2: When i start with cpu mining disabled everything works perfectly fine. But when i enable cpu mining with -t7 (8 core machine) it looses connection with the first 2 pools but after 1 minute it reconnects.
Best
//GoK
Thanx for the work on 1.6.1.
I just switched over my miners to the new code and it seems to work well.
There are two things though...
1: Would you consider making the -t flag imply --enable-cpu (yeah its a itsy bitsy thing)
2: When i start with cpu mining disabled everything works perfectly fine. But when i enable cpu mining with -t7 (8 core machine) it looses connection with the first 2 pools but after 1 minute it reconnects.
Best
//GoK
Code:
[2011-07-29 06:49:00] Started cgminer 1.6.1
[2011-07-29 06:49:00] Testing pool http://pool1:8332
[2011-07-29 06:49:01] Successfully retrieved and deciphered work from pool 0 http://pool1:8332
[2011-07-29 06:49:01] Pool 0 http://pool1:8332 active
[2011-07-29 06:49:01] Testing pool http://pool0:8332
[2011-07-29 06:49:02] Successfully retrieved and deciphered work from pool 1 http://pool0:8332
[2011-07-29 06:49:02] Pool 1 http://pool0:8332 active
[2011-07-29 06:49:02] Testing pool http://pool2:8332
[2011-07-29 06:49:02] Successfully retrieved and deciphered work from pool 2 http://pool2:8332
[2011-07-29 06:49:02] New block detected on network, waiting on fresh work
[2011-07-29 06:49:02] Pool 2 http://pool2:8332 active
[2011-07-29 06:49:02] Init GPU thread 0
[2011-07-29 06:49:02] List of devices:
[2011-07-29 06:49:02] 0 Juniper
[2011-07-29 06:49:02] Selected 0: Juniper
[2011-07-29 06:49:02] Long-polling activated for http://pool1:8332/LP
[2011-07-29 06:49:02] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-07-29 06:49:02] initCl() finished. Found Juniper
[2011-07-29 06:49:02] Init GPU thread 1
[2011-07-29 06:49:02] List of devices:
[2011-07-29 06:49:02] 0 Juniper
[2011-07-29 06:49:02] Selected 0: Juniper
[2011-07-29 06:49:02] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-07-29 06:49:02] initCl() finished. Found Juniper
[2011-07-29 06:49:02] 2 gpu miner threads started
[2011-07-29 06:49:02] 7 cpu miner threads started, using SHA256 'sse2_64' algorithm.
[2011-07-29 06:49:03] Pool 0 http://pool1:8332 not responding!
[2011-07-29 06:49:03] Switching to http://pool0:8332
[2011-07-29 06:49:03] Pool 1 http://pool0:8332 not responding!
[2011-07-29 06:49:03] Switching to http://pool2:8332
[2011-07-29 06:49:03] Long-polling activated for http://pool2:8344
[2011-07-29 06:49:04] Pool 2 http://pool2:8332 not responding!
[2011-07-29 06:49:04] Pool 2 http://pool2:8332 recovered
[2011-07-29 06:49:04] Pool 2 http://pool2:8332 not responding!
...
[2011-07-29 06:50:04] Testing pool http://pool1:8332
[2011-07-29 06:50:05] Successfully retrieved and deciphered work from pool 0 http://pool1:8332
[2011-07-29 06:50:05] Pool 0 http://pool1:8332 recovered
[2011-07-29 06:50:05] Switching to http://pool1:8332
[2011-07-29 06:50:05] Testing pool http://pool0:8332
[2011-07-29 06:50:05] Long-polling activated for http://pool1:8332/LP
[2011-07-29 06:50:06] Successfully retrieved and deciphered work from pool 1 http://pool0:8332
August 29, 2011, 09:02:18 AM
1.6.1 finally fixes this zero byte problem..good work
Performance problem with HD6970 still exists. GPU clock is jumping up&down every second, resulting in approx 80MHash less output.
Performance problem with HD6970 still exists. GPU clock is jumping up&down every second, resulting in approx 80MHash less output.
Is that for one GPU (80 Mhash)?
My 6970's can varry 1-10 Mhash each.
My 5870's seem to vary about 1-10 Mhash each.
Which is probably normal for the way this miner software works.
Guiminer I get 417-423.5 Mhash on a 6970. It fluctuates as well.
All of my GPU's are below 78 deg C.
Edit: I'm told that the first number is the 5 sec average (the number's I posted above) and the 2nd number is what to look at. That 2nd hash rate is pretty consistent for me with very little fluctuation.
Maybe you have a Power Supply issue. As in cgminer pushing your cards harder and they are consuming more power than before.
August 29, 2011, 08:46:35 AM
All true but even with very underclocked config there is this GPU clock up/down problem.
Does not exists with 1.5.5 or even Phoenix 1.6.2 at 100Mhz higher core clock. So I am sure it's not a temperature problem.
Does not exists with 1.5.5 or even Phoenix 1.6.2 at 100Mhz higher core clock. So I am sure it's not a temperature problem.
August 29, 2011, 08:37:57 AM
Thanks. Again, it's not a temperature problem!
Card is well cooled and staying around ~75°C.
Mmh. Is the temperature measured on the GPU die, or is there an external temperature sensor on the heat sink?Card is well cooled and staying around ~75°C.
If the latter ⇒ bad heat transfer paste could still be the reason.
August 29, 2011, 08:09:00 AM
Thanks. Again, it's not a temperature problem!
Card is well cooled and staying around ~75°C.
I already tried different intensities (3,5,7,8,9 and dynamic) and also lowering the GPU clock. Still same behaviour.
btw.. tried Catalyst 11.6, 11.7 and 11.8 too
Card is well cooled and staying around ~75°C.
I already tried different intensities (3,5,7,8,9 and dynamic) and also lowering the GPU clock. Still same behaviour.
btw.. tried Catalyst 11.6, 11.7 and 11.8 too
August 29, 2011, 07:56:37 AM
I agree but this is not the case here..
Till version 1.5.5 I reach constant 421MHash with my HD6970 at a temperature of ~75°C.
Since version 1.5.6 and with all recent versions the problem occurs. I think it may have something to do with the new kernels used..
Till version 1.5.5 I reach constant 421MHash with my HD6970 at a temperature of ~75°C.
Since version 1.5.6 and with all recent versions the problem occurs. I think it may have something to do with the new kernels used..
The problem might be that the newer kernels (1.5.6+) pushes the card harder.
Pushes the card harder -> generating more heat -> GPU freq. starts to oscillate.
So try lowering the intensity and see what happens. It might solve your problems....
/GoK
I remembered this came up in an earlier post:
Decreasing intensity can help as well. It's the combination of the latest phatk kernel and the high intensity in cgminer that pushes cards to their limit. You may find the reduction in hash rate to be insignificant but the stability to increase. Try -I 7 instead of 8.
August 29, 2011, 07:32:09 AM
I agree but this is not the case here..
Till version 1.5.5 I reach constant 421MHash with my HD6970 at a temperature of ~75°C.
Since version 1.5.6 and with all recent versions the problem occurs. I think it may have something to do with the new kernels used..
Till version 1.5.5 I reach constant 421MHash with my HD6970 at a temperature of ~75°C.
Since version 1.5.6 and with all recent versions the problem occurs. I think it may have something to do with the new kernels used..
August 29, 2011, 07:12:39 AM
1.6.1 finally fixes this zero byte problem..good work
Performance problem with HD6970 still exists. GPU clock is jumping up&down every second, resulting in approx 80MHash less output.
Performance problem with HD6970 still exists. GPU clock is jumping up&down every second, resulting in approx 80MHash less output.
August 29, 2011, 06:59:07 AM
I found some temporarily fix to reduce the cpu consumption in windows...
use this tool http://www.adsciengineering.com/StartAffinity/
to set the affinity of cgminer to one core. Use quotes on your cgminer cmdline and the id you would set in the taskmanager.
Or is there a way to actually get rid of it yet?
It only uses a total amount of CPU that amounts to 100% of one CPU core due to the strange way the ATI driver is written, and binding the application to one core just means all the work will go to that one core; it does not actually decrease CPU usage.use this tool http://www.adsciengineering.com/StartAffinity/
to set the affinity of cgminer to one core. Use quotes on your cgminer cmdline and the id you would set in the taskmanager.
Or is there a way to actually get rid of it yet?
(1 core with 100% / 1 GPU)
Jump to: