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

[-ck]

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.

[1713572822]

1713572822

[1713572822]

1713572822

[-ck]

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.

[The LT]

Nice commits yesterday, thanks! Really polishing it up.

[ElectricMucus]

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.

Yeah but 100% of one core is less than ~70% of 4 cores. (I'm sure i can say that since the cpu fan runs much slower then)

[-ck]

New release: Version 1.6.1, Links in first post.

Executive summary of user visible changes:
Hopefully fixed the zero sized binary bug \o/
Hopefully fixed the (old ncurses) resize crash
Hopefully fixed the memory leak in cpu mining and the inappropriately high rejects
Tidier build and smarter config and new --disable-opencl option
Less false positives for "unable to provide work fast enough"
New --shares option (mine X shares and exit)
New --enable-cpu and --disable-gpu options
Version info


Full changelog:
- Copy cgminer path, not cat it.
- Switching between redrawing windows does not fix the crash with old
libncurses, so redraw both windows, but only when the window size hasn't
changed.
- Reinstate minimum 1 extra in queue to make it extremely unlikely to ever have
0 staged work items and any idle time.
- Return -1 if no input is detected from the menu to prevent it being
interpreted as a 0.
- Make pthread, libcurl and libcurses library checks mandatory or fail.
- Add a --disable-opencl configure option to make it possible to override
detection of opencl and build without GPU mining support.
- Confusion over the variable name for number of devices was passing a bogus
value which likely was causing the zero sized binary issue.
- cgminer no longer supports default url user and pass so remove them.
- Don't show value of intensity since it's dynamic by default.
- Add options to explicitly enable CPU mining or disable GPU mining.
- Convert the opt queue into a minimum number of work items to have queued
instead of an extra number to decrease risk of getting idle devices without
increasing risk of higher rejects.
- Statify tv_sort.
- Check for SSE2 before trying to build 32 bit SSE2 assembly version. Prevents
build failure when yasm is installed but -msse2 is not specified.
- Add some defines to configure.ac to enable exporting of values and packaging,
and clean up output.
- Give convenient summary at end of ./configure.
- Display version information and add --version command line option, and make
sure we flush stdout.
- Enable curses after the mining threads are set up so that failure messages
won't be lost in the curses interface.
- Disable curses after inputting a pool if we requested no curses interface.
- Add an option to break out after successfully mining a number of accepted
shares.
- Exit with a failed return code if we did not reach opt_shares.
- The cpu mining work data can get modified before we copy it if we submit it
async, and the sync submission is not truly sync anyway, so just submit it sync.


---
If you're wondering why I include the entire build in the linux binary tarball, it's so you can do 'make install' to install it into a system location. 

[-ck]

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.

Yeah but 100% of one core is less than ~70% of 4 cores. (I'm sure i can say that since the cpu fan runs much slower then)

Okay that is much crappier than I'd even imagined it would be on windows.

[PLaci1982]

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.

Yeah but 100% of one core is less than ~70% of 4 cores. (I'm sure i can say that since the cpu fan runs much slower then)

~70% of 4 = 3 GPU
(1 core with 100% / 1 GPU)

[Endeavour79]

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.

[Endeavour79]

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

[Ghostofkobra]

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

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.

[Endeavour79]

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

[smurfix]

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?

If the latter ⇒ bad heat transfer paste could still be the reason.

[Endeavour79]

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.

[sharky112065]

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.

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.

[Ghostofkobra]

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

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 

[EskimoBob]

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

[ancow]

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

[The00Dustin]

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:

Code:

-bash: /usr/local/bin/cgminer: No such file or directory

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 as

Code:

#JANSSON_INCLUDES =
JANSSON_INCLUDES = -I$(top_srcdir)/compat/jansson

instead of

Code:

JANSSON_INCLUDES =
#JANSSON_INCLUDES = -I$(top_srcdir)/compat/jansson

when the version of JSON is too old to compile with?

[-ck]

You must specify your install directory with --prefix= and compile it yourself if you want to install it somewhere specific.

[-ck]

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

This can probably be alleviated by increasing the -Q value (default is 1). This can be done while it's still running in ettings -> [Q]ueue. Experiment and see.