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

[Vbs]

Maybe this a stupid question, I don't know.. I tried searching quite a bit but didn't find anything regarding special settings. I just began mining again after a long break and I made the switch from guiminer to cgminer. My computer has 2x 5850's. With guiminer and the tags -v -w256, I get about 340mh/s per card with 875/300. With cgminer, I get 305-310mh/s. I'm running Catalyst 12.1 drivers. I've played with the intensity and checked the clock speed with Afterburner, and the cards are running at about 60*C each. Is there something I should be doing differently?

You need -v 2 for low mem clocks, no if's or but's here!

Please check the graph for vector and work sizes at http://bitcointalk.org/index.php?topic=7964.0
For a worksize of 256 on a 5870 at 300MHz ram, the difference between v1 and v2 is ~85MH/s!

[mmortal03]

With all this intensity setting talk, I thought I'd bring up a recent discovery of mine. On my dedicated rig, I've been trying to find a sweet spot of wattage and hash rate for maximum profitability, and intensity seems to play an important role in this.

First off, in my rig I'm running a single 5870 GPU, along with an Atom N270 processor. I've already long had my gpu's memory underclocked to 150, and the gpu engine overclocked to 999, which seems to be a sweet spot for wattage and stability when running it with CGMINER.  When originally testing my rig's power consumption with a KillAWatt, I found that with intensities higher than 9, while I was able to achieve a higher average hash rate, my CPU usage increased more than linearly, which, in turn, used more wattage and actually lowered my profitability.  So, up until recently, I found that my sweet spot was to leave intensity set to 9.

However, this was before I realized the potential capabilities of Advanced Power Options -> Processor Power Management -> Maximum processor state in Windows.  By default, maximum processor state is set to 100%. Using CPU-Z, I've been able to demonstrate that once I increase the intensity setting to 10 or more in CGMINER, my Atom processor in fact scales up from 800 MHz to 1600 MHz along with the increase in CPU usage.  My thinking here is that this may likely have been where the additional increase in wattage had been coming from when I'd originally found that intensity settings higher than 9 were detrimental to profitability.

So, I've just experimented with setting my maximum processor state down to 50%, and, as expected, when testing CGMINER at intensities higher than 9 (up to 12 so far), and my processor now no longer scales up to 1600 MHz in CPU-Z. My thinking is that this should allow me to squeeze a few more megahashes out of this setup without raising my overall wattage quite as much, if at all.

All this said, I don't have physical access to my rig to actually test any of this out with a KillAWatt at the moment, so others will need to confirm based on their setups. I'm pretty sure, though, that, theoretically speaking, that's the whole point of having the processor frequency scaling, to conserve electricity when you don't need a higher clock speed. My idea here is that in certain special cases like ours, we may be able to outsmart the automatic frequency scaling to our benefit, by lowering our maximum processor state to lock in a lower scaling (and a lower effective wattage), and then raising the intensity in CGMINER to still get the benefit of higher hash rates, for an overall win-win.

[kano]

...
Any pointers into having CGMINER startup automatically on linux ? i have a script in the "startup" folder in windows, but in linux, i found no way of having cgminer actually start either using a script in init.d or via startup applications (gui sesion automatically starts and logs in, i can run other miners via startup applications, but cgminer is my prefered one)

You need the computer to boot into X (login auto)
You need to run the script as the user who "auto login"s
You need the script to set DISPLAY correctly
... and you need to wait until X has started before starting cgminer.

[Vbs]

So, I've just experimented with setting my maximum processor state down to 50%, and, as expected, when testing CGMINER at intensities higher than 9 (up to 12 so far), and my processor now no longer scales up to 1600 MHz in CPU-Z. My thinking is that this should allow me to squeeze a few more megahashes out of this setup without raising my overall wattage quite as much, if at all.

Your only metric should be U/W mate, MH/W may show better results with increased intensity but in most cases you will be lowering U, and only U matters.

* Vbs bows to U!

[os2sam]

I completely missed the 2.2.x releases till today.

2.2.1 doesn't create the bin files in WinXP.  Are the ones from CGMiner 2.0.0 compatible with the 2.2.x?
Thanks,
Sam

[DeathAndTaxes]

I completely missed the 2.2.x releases till today.

2.2.1 doesn't create the bin files in WinXP.  Are the ones from CGMiner 2.0.0 compatible with the 2.2.x?
Thanks,
Sam

It should be.  The bin is actually produced by the kernel (cl files) which hasn't been updated in 6 months?

Well kernel + installed SDK = bin file.

[os2sam]

I completely missed the 2.2.x releases till today.

2.2.1 doesn't create the bin files in WinXP.  Are the ones from CGMiner 2.0.0 compatible with the 2.2.x?
Thanks,
Sam

It should be.  The bin is actually produced by the kernel (cl files) which hasn't been updated in 6 months?

Well kernel + installed SDK = bin file.

Copied them over and it seems to be fine.
Thanks,
Sam

[kentrolla]

on windows xp im getting an error that says "All devices disabled. Cannot mine!"

help please!

[os2sam]

on windows xp im getting an error that says "All devices disabled. Cannot mine!"

help please!

That could be related to my post.

Check your CGMiner directory and see if the two *.bin files got created or not.
Sam

[kentrolla]

no bin files got created.  and when put in -n  it says 0 gpu devices found

[os2sam]

no bin files got created.  and when put in -n  it says 0 gpu devices found

OK, that's a different problem at the moment.

What version of Catalyst and OpenCL do you have installed?

Have you successfully used previous versions of CGMiner?
Sam

[kentrolla]

I have windows 7 64 bit and i was just doing some testing to see if i would get faster hashrate on a virtual machine running windows XP 32bit with a fresh install. 2.2.1 works just fine on my win7 64bit OS.  all i did was copy opencl.dll into the cgminer folder and that worked on version 2.1.2 on xp 32bit and windows7 64bit. but with version 2.2.x copying opencl.dll only works on windows7 64bit.  the opencl.dll file that i copied says its version 1.1.0.0 last modified 3/21/2011

i dont think it has anything to do with copying the opencl.dll

also, why don't you just include an opencl.dll in the package?

wow i just read my post and its so sloppy lol.

TLDR.  2.1.2 worked on both winxp 32bit and win7 64bit.  2.2.x only works on win7 64

[os2sam]

I have windows 7 64 bit and i was just doing some testing to see if i would get faster hashrate on a virtual machine running windows XP 32bit with a fresh install. 2.2.1 works just fine on my win7 64bit OS.  all i did was copy opencl.dll into the cgminer folder and that worked on version 2.1.2 on xp 32bit and windows7 64bit. but with version 2.2.x copying opencl.dll only works on windows7 64bit.  the opencl.dll file that i copied says its version 1.1.0.0 last modified 3/21/2011

i dont think it has anything to do with copying the opencl.dll

also, why don't you just include an opencl.dll in the package?

wow i just read my post and its so sloppy lol.

TLDR.  2.1.2 worked on both winxp 32bit and win7 64bit.  2.2.x only works on win7 64

Your GPU mining in a VM?  I wouldn't have thought that would ever work.  Don't VM's emulate the video card with a very generic driver such as an S3 Chipset?

I think that is a bit out of my depth as I'm using a dedicated machine running native WinXP SP3.
Sam

[zefir]

[...]

1 nonce range = 2^32 = 4 billion hashes.  An 300 MH/s card would take 11 seconds to complete.

An intensity of 8 might say do 300 million hashes and return results.
And inensity of 9 might say do 600 million hashes and return results.
An intensity of 10 might say do 1 billion hashes and return results.

All you are doing is increasing the "batch size" which takes longer to run.  You gain a small boost by eliminating the number of batches and thus overhead to complete a nonce but you also make the card unresponsive for longer and longer periods of time. 

However a hypothetical 1 GH/s card could do intensity 10 in 1 second.  So thus intensity 10 on this card is no different than intensity 8 on your card.

Make sense? 

[...]

Are these facts, or is it what you assume?

What I find contradictory is that the higher the intensity, the less responsive the PC becomes. With your explanation it should be the other way around, or am I missing something? After CPU asks for one billion hashes from the GPU, it can sleep for 2 seconds and collect the result, while with asking for only 100 millions it needs to get active after 200ms, right?

I'm not sure what causes the decayed responsivity with higher intensity. For sure it is not a matter of whether a multi GHz CPU is being woken up every 2 seconds or 2 msecs. Nor it should be caused by GPU being dumped with a big chunk of work - 2D and 3D units are independent, loading SPs should generally not impact desktop performance.

What am I missing?

[rcocchiararo]

...
Any pointers into having CGMINER startup automatically on linux ? i have a script in the "startup" folder in windows, but in linux, i found no way of having cgminer actually start either using a script in init.d or via startup applications (gui sesion automatically starts and logs in, i can run other miners via startup applications, but cgminer is my prefered one)

You need the computer to boot into X (login auto)
You need to run the script as the user who "auto login"s
You need the script to set DISPLAY correctly
... and you need to wait until X has started before starting cgminer.

im a failure :/

i originally had this on my script (double clicking it started cgminer correctly, or running it from terminal)

Code:

/home/rcocchiararo/bitcoin/cgminer-2.1.2/cgminer -o http://pit.deepbit.net:8332 -u user -p pass -o http://api2.bitcoin.cz:8332 -u user -p pass --auto-fan --auto-gpu --gpu-engine 950-975 --gpu-memclock 300 --gpu-fan 20-80 --temp-target 65 --temp-overheat 70 --api-listen --api-network -I 9

putting that in the "startup applications" did nothing.

So i changed it to this:
(the exports are what i had when i used other miners)

Code:

#!/bin/bash

export AMDAPPSDKROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
export AMDAPPSDKSAMPLESROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
export LD_LIBRARY_PATH=${AMDAPPSDKROOT}lib/x86:${LD_LIBRARY_PATH}

export DISPLAY=:0.0


cd /home/rcocchiararo/Desktop
killall -9 cgminer
sleep 5
/home/rcocchiararo/bitcoin/cgminer-2.1.2/cgminer -o http://pit.deepbit.net:8332 -u user -p pass -o http://api2.bitcoin.cz:8332 -u user -p pass --auto-fan --auto-gpu --gpu-engine 950-975 --gpu-memclock 300 --gpu-fan 20-80 --temp-target 65 --temp-overheat 70 --api-listen --api-network -I 9

still nothing (o do think that the VGA fans start spining faster tho)

[jake262144]

Are these facts, or is it what you assume?

What I find contradictory is that the higher the intensity, the less responsive the PC becomes. With your explanation it should be the other way around, or am I missing something? After CPU asks for one billion hashes from the GPU, it can sleep for 2 seconds and collect the result, while with asking for only 100 millions it needs to get active after 200ms, right?

I'm not sure what causes the decayed responsivity with higher intensity. For sure it is not a matter of whether a multi GHz CPU is being woken up every 2 seconds or 2 msecs. Nor it should be caused by GPU being dumped with a big chunk of work - 2D and 3D units are independent, loading SPs should generally not impact desktop performance.

What am I missing?

What you are missing is an obvious fact that the higher the intensity, the longer the uninterruptible busy cycles of your GPU are.
Hence, any attempt at communicating with the card is gonna have to wait until the device is done processing it's current batch of data.
The waiting low-level calls cause the parent code to "hang" as well while waiting for a response.
As a result the whole graphic subsystem becomes sluggish and unresponsive.
These are very much the facts.

[DeathAndTaxes]

Are these facts, or is it what you assume?

They are facts I just am not sure on the algorithm. Intensity x = # of hashes y.  I knew the alogrithm for pheonix at one time.

What I find contradictory is that the higher the intensity, the less responsive the PC becomes. With your explanation it should be the other way around, or am I missing something? After CPU asks for one billion hashes from the GPU, it can sleep for 2 seconds and collect the result, while with asking for only 100 millions it needs to get active after 200ms, right?

It has to do with the way AMD writes the drives.  The CPU has no idea when the GPU will finish so it spends clock cycles "checking".  The way it checked w/ older drivers is what caused the 100% CPU bug.  This has improved but the GPU doesn't go "idle" and then get the results at the end of the batch it continually checks to see if the batch has completed.

The OS GUI also can't dedraw the screen while the GPU is working so the longer the batches the more "laggy" the desktop will seem.  If intensity is too high it can crash windows (especially OS running Aero) because Windows isn't exactly OpenCL aware.  It doesn't understand that the GPU may be unavailable for a long time.  Prior to OpenCL there never was a time when GPU would be unavailable for graphical work.  If it can't reach the GPU in a reasonable amount of time it causes unpredictable results.

Remember when a batch is running the GPU is completely unresponsive.  It totally ignores (without even a "sorry busy" notification) any communication from any other component (even the process running the miner code) until it completes.

I'm not sure what causes the decayed responsivity with higher intensity. For sure it is not a matter of whether a multi GHz CPU is being woken up every 2 seconds or 2 msecs. Nor it should be caused by GPU being dumped with a big chunk of work - 2D and 3D units are independent, loading SPs should generally not impact desktop performance.

The CPU is being woken up when done.  The GPU is checking to see if the batch has completed.  
2D units aren't independent on modern graphics cards and for OS using Aero the desktop is no longer 2D anyways.  On Linux xorg also uses 3D acceleration to speed up desktop performance when using binary drivers.

[zefir]

Are these facts, or is it what you assume?

They are facts I just am not sure on the algorithm. Intensity x = # of hashes y.  I knew the alogrithm for pheonix at one time.

What I find contradictory is that the higher the intensity, the less responsive the PC becomes. With your explanation it should be the other way around, or am I missing something? After CPU asks for one billion hashes from the GPU, it can sleep for 2 seconds and collect the result, while with asking for only 100 millions it needs to get active after 200ms, right?

It has to do with the way AMD writes the drives.  The CPU has no idea when the GPU will finish so it spends clock cycles "checking".  The way it checked w/ older drivers is what caused the 100% CPU bug.  This has improved but the GPU doesn't go "idle" and then get the results at the end of the batch it continually checks to see if the batch has completed.

The OS GUI also can't dedraw the screen while the GPU is working so the longer the batches the more "laggy" the desktop will seem.  If intensity is too high it can crash windows (especially OS running Aero) because Windows isn't exactly OpenCL aware.  It doesn't understand that the GPU may be unavailable for a long time.  Prior to OpenCL there never was a time when GPU would be unavailable for graphical work.  If it can't reach the GPU in a reasonable amount of time it causes unpredictable results.

Remember when a batch is running the GPU is completely unresponsive.  It totally ignores (without even a "sorry busy" notification) any communication from any other component (even the process running the miner code) until it completes.

I'm not sure what causes the decayed responsivity with higher intensity. For sure it is not a matter of whether a multi GHz CPU is being woken up every 2 seconds or 2 msecs. Nor it should be caused by GPU being dumped with a big chunk of work - 2D and 3D units are independent, loading SPs should generally not impact desktop performance.

The CPU is being woken up when done.  The GPU is checking to see if the batch has completed. 
2D units aren't independent on modern graphics cards and for OS using Aero the desktop is no longer 2D anyways.

Sound's plausible. Well almost... Can't really believe that the AMD folks are not capable to design their driver in a way that does not require busy waiting/polling.

Anyhow, I forgot to mention that I am meanwhile using a headless Linux system for mining. The lags caused by 2D engine should therefore not apply. Now I need to check whether intensity has an impact on the system like I noticed with GUIminer before. If so, I'd wonder why busy-waiting 2 seconds is worse than busy waiting 10*0.2 seconds...

[kentrolla]

I have windows 7 64 bit and i was just doing some testing to see if i would get faster hashrate on a virtual machine running windows XP 32bit with a fresh install. 2.2.1 works just fine on my win7 64bit OS.  all i did was copy opencl.dll into the cgminer folder and that worked on version 2.1.2 on xp 32bit and windows7 64bit. but with version 2.2.x copying opencl.dll only works on windows7 64bit.  the opencl.dll file that i copied says its version 1.1.0.0 last modified 3/21/2011

i dont think it has anything to do with copying the opencl.dll

also, why don't you just include an opencl.dll in the package?

wow i just read my post and its so sloppy lol.

TLDR.  2.1.2 worked on both winxp 32bit and win7 64bit.  2.2.x only works on win7 64

Your GPU mining in a VM?  I wouldn't have thought that would ever work.  Don't VM's emulate the video card with a very generic driver such as an S3 Chipset?

I think that is a bit out of my depth as I'm using a dedicated machine running native WinXP SP3.
Sam

yea it works. well at least it worked in 2.1.2

[miscreanity]

im a failure :/

No worries, trial & error is a learning process - personally, I'd rather fail and learn than succeed without understanding why. Try going through this thread and experiment with different methods, then choose the one that works best for you.