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

[DeathAndTaxes]

... and if anyone didn't realise:
If you use the api command "devdetails" it will tell you which "Kernel" it is using and the "Model" for each gpu

Nice.

[Luke-Jr]

... and if anyone didn't realise:
If you use the api command "devdetails" it will tell you which "Kernel" it is using and the "Model" for each gpu

You forget to mention that I wrote this, both the back-end code shared by CGMiner and BFGMiner, and the original implementation of "devdetail" which you rejected so you could rewrite it less efficiently...

[fred0]

I don't know what to tell you ... it didn't work before, now it works with gpu disabled.  Is there a reason why bfl's are not auto detected like they are in ufasoft's miner?

Ufasoft doesn't really autodetect, it just spams every serial port with a probe every few seconds. I'm working on a proper autodetect for Windows.

That would be fantastic.

Possible to detect if one has throttled and/or a way to know which one is which? I have a number of them and one is running a bit hot. I have no way of figuring out which one it is except removing them all and trying them one at a time.

I have found that the easiest way to identify a particular single is to disable it then reenable it using kano's api calls.  When pgadisable is sent to a particular device the red led on the right side(when looking at the front panel status led) will toggle off. Then send the pgeenable to the same device to confirm the light is on. Simple bash script follows:

Code:

#!/bin/bash
BFLHOST=192.168.0.199
BFLPORT=4028
if [ $# -eq 2 ] ; then
    if [ $1 == "d" ] ; then
        echo -n "pgadisable|$2" | nc $BFLHOST $BFLPORT | awk 'BEGIN { FS=","; } ; { for (i=1;i<=NF;i++) { print $i } exit; }'
    elif [ $1 == "e" ] ; then
        echo -n "pgaenable|$2" | nc $BFLHOST $BFLPORT | awk 'BEGIN { FS=","; } ; { for (i=1;i<=NF;i++) { print $i } exit; }'
    fi
else
    echo "Enable/Disable fpga "
    echo " arg1 e or d enable/disable a device"
    echo " arg2 device number to enable/disable"
fi

[The00Dustin]

- Use longpolls from backup pools with failover-only enabled just to check for
block changes, but don't use them as work.

I don't have enough data or it to be definitive yet, but I'm wondering if this didn't slightly lower my Utility.  I am mining on a a merged pool that sometimes uses submitold, but have a backup pool that doesn't.  Both use merged mining, and I am using --failover-only.  So, I'm wondering, when a pool other than 0 sends an LP before pool 0, is pool 0's work discarded even though it might still be good?  It seems to me like it would be, and then for the time between the LP on the backup pool and the LP on the primary pool, work wouldn't be done.  This may not be true, because it may immediately request new work that may then also be discarded when my pool does LP (I have seen this take 20 seconds with no share submitted, but sometimes it takes significantly longer than that to find a share at ~318 MH/s).  That having been said, I am asking because my U is at 4.35 (which rounds to 4.4 in the main stats, over only 6125 shares) where it was at 4.41 before (over tens of thousands of shares over weeks of work).  Obviously we are only talking about a difference of .06 in my U, which may be statistically insignificant, but it is still potentially 1.5% less shares being submitted over >12 hours.

[check_status]

I'd like to reduce stales/DOA for p2pool, rejected shares and Longpolling (hardware errors are zero). Is this more a combination of engine/mem, gpu threads, intensity, vectors, and worksize rather than a specific kernel?

There is only one phatk in cgminer and it's called -k phatk, and it's actually phatk2.2 as you would know it. If you do not specify anything, it is chosen by default on pretty much all 5X and 6X cards with any SDK before 2.6. If you have 5X cards, STICK TO AN OLDER SDK, 2.1, 2.4 or 2.5 and let it choose phatk.

Thanks. Maybe because someone says you must use the phatk2 kernel in cgminer I became confused because of the 3 .bin files labled phatk120223bart.....8l8.bin and the 1 phatk .cl file, assuming, because there are 4 phatk files, I could migrate to another kernel that might offer different performance.

To do the best with p2pool, read the readme.

But is intensity and threads the only factors that will increase how many BTC my system will generate with p2pool? Can a particular mem clock frequency affect how much BTC is produce in p2pool?

[kano]

... and if anyone didn't realise:
If you use the api command "devdetails" it will tell you which "Kernel" it is using and the "Model" for each gpu

You forget to mention that I wrote this, both the back-end code shared by CGMiner and BFGMiner, and the original implementation of "devdetail" which you rejected so you could rewrite it less efficiently...

Firstly, why do I need to mention what small parts of api.c you wrote?
(Especially after you did the back-end refactor of cgminer but didn't bother to fix the problems that caused in api.c - and you still have one I can see - line 917, see below)

Secondly:

22:55 < luke-jr> kanoi: in other words, you want to be able to pull api.c out and put it with any other cgminer version?
22:56 < kanoi> sort of - but the reverse of that - I want cgmine version changes to mininise any affect onthe api
22:56 < kanoi> (the reports)
22:57 < kanoi> also fo ryour new info - that should be it's own 'report'
22:57 < kanoi> since it never changes, resending it every time is a waste
22:57 < kanoi> like the 'notify' - not always needed (but notify does change)
22:58 < kanoi> but in the case of the extra info - not needed more than once (unless the target forgets it)
22:58 < luke-jr> I suppose.
22:58 < kanoi> so that would be a new devs style command that just returns that extra new info
22:59 < luke-jr> what do you propose?
22:59 < luke-jr> "devdetail" ?
23:00 < kanoi> probably - sounds OK I guess

Hmm - so (as can be seen above) I told you to move the extra info to it's own command rather than have it the way that you designed to send that extra static never changing info EVERY time you request 'devs', 'gpu|N' or 'pga|N' - and that was less efficient?
Which - you did make that change as I said to.

The main differences I can see in the code is that you moved the GPU specific information OUT of api.c and instead call append_kv over and over again to append that data on the end instead of where it was before (miner.php looks crap in your version now) and instead of using a single (faster) print command
Also, the devdetails command removes fields that are blank so the external code processing the API output has to check for missing fields
You should correct line 917 the way I said it should be (and is in my version)
Hmm - and you send your "get_extra_device_detail(cgpu)" both with the 'devs' command and the 'devdetail' command - i.e. duplicating it.

The git "blame" page for api.c ... well anyway

Please stop trying to make it seem like there is some advantage to your clone (with not many changes) in this thread - especially when you've given an example that's not even true.
Go praise your miner in your own thread where your acolytes are less discerning than the folk here

[check_status]

Do you guys argue like this only to keep CGMiner as the top thread posting? You guys sound like either side of a Miller Lite commercial; crowd A: Great Taste! Crowd B: Less Filling!, then begin to look like a fight is about to occur over different perspectives for the same beer. 

[cmdr001]

I have come up with an issue on CG Miner which I'm not being quite able to sort through, so if any help would be possible.
I tried searching on the thread, and while some mentions to adjusting engine clock were around it didn't quite fit my situation.

For a while now I had been using CG  Miner 2.3.1 without any issues, but last night came up a problem where I couldn't seem to be able to adjust the clock speed below a certain value on neither of both cards (2x 6870). Wondering if it could be some odd bug I had struck on, I checked the thread, updated CG Miner, took the chance to update the video drivers, and on a new attempt I'm now able to adjust the speed of one of the cards to about any value, but not the other one.

I saw a mention that this could be driver related, but these cards are twins, worked always well before, but suddenly this came up even before I updated the drivers.

Any help?

[-ck]

- Use longpolls from backup pools with failover-only enabled just to check for
block changes, but don't use them as work.

I don't have enough data or it to be definitive yet, but I'm wondering if this didn't slightly lower my Utility.  I am mining on a a merged pool that sometimes uses submitold, but have a backup pool that doesn't.  Both use merged mining, and I am using --failover-only.  So, I'm wondering, when a pool other than 0 sends an LP before pool 0, is pool 0's work discarded even though it might still be good?  It seems to me like it would be, and then for the time between the LP on the backup pool and the LP on the primary pool, work wouldn't be done.  This may not be true, because it may immediately request new work that may then also be discarded when my pool does LP (I have seen this take 20 seconds with no share submitted, but sometimes it takes significantly longer than that to find a share at ~318 MH/s).  That having been said, I am asking because my U is at 4.35 (which rounds to 4.4 in the main stats, over only 6125 shares) where it was at 4.41 before (over tens of thousands of shares over weeks of work).  Obviously we are only talking about a difference of .06 in my U, which may be statistically insignificant, but it is still potentially 1.5% less shares being submitted over >12 hours.

That difference is surely enough to be accounted by in variance which in U is usually +/-10%, but the full discussion of its effects is here:
https://bitcointalk.org/index.php?topic=28402.msg873742#msg873742
Theoretically you might be losing a *tiny* bit of work across longpolls with --failover-only but in my experience it is less than 2 seconds' worth of work every 10 minutes.

[phorensic]

ckolivas, any chance you can take a look at the possibility of churning some code out to take advantage of the Intel HD GPU's integrated into Sandy Bridge CPU's (and now Ivy Bridge)?  Apparently they just released OpenCL SDK to allow access to the GPU portion of the CPU instead of just the CPU itself.  See post #22 here - https://bitcointalk.org/index.php?topic=71366.msg870723#msg870723

[Luke-Jr]

Firstly, why do I need to mention what small parts of api.c you wrote?

You should attribute things like that, because it sure did look like you were trying to claim credit for it.

Hmm - so (as can be seen above) I told you to move the extra info to it's own command rather than have it the way that you designed to send that extra static never changing info EVERY time you request 'devs', 'gpu|N' or 'pga|N' - and that was less efficient?

I'm talking about the implementation. As you noted, I did move it to a new command, as you requested.

Hmm - and you send your "get_extra_device_detail(cgpu)" both with the 'devs' command and the 'devdetail' command - i.e. duplicating it.

No, 'devs' uses get_extra_device_status, and 'devdetail' uses get_extra_device_detail. Different methods for different purposes.

[Zenitur]

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.

Code:

  CC     usage.o
  AR     libccan.a
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6/ccan'
make[2]: Entering directory `/home/kanotix/cgminer-2.3.6'
  CC     cgminer-cgminer.o
  CC     cgminer-util.o
  CC     cgminer-sha2.o
  CC     cgminer-api.o
api.c: In function ‘api’:
api.c:2409: error: label at end of compound statement
make[2]: *** [cgminer-api.o] Error 1
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make: *** [all] Error 2

Tested with NVIDIA and ATi/AMD OpenCL's. OS: Linux x86. GCC: 4.3.

[-ck]

ckolivas, any chance you can take a look at the possibility of churning some code out to take advantage of the Intel HD GPU's integrated into Sandy Bridge CPU's (and now Ivy Bridge)?  Apparently they just released OpenCL SDK to allow access to the GPU portion of the CPU instead of just the CPU itself.  See post #22 here - https://bitcointalk.org/index.php?topic=71366.msg870723#msg870723

If it's opencl then they should already work. Performance, on the other hand, is likely to be shit. Not because of my opencl code, but because they are pissweak.

[kano]

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.

Code:

  CC     usage.o
  AR     libccan.a
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6/ccan'
make[2]: Entering directory `/home/kanotix/cgminer-2.3.6'
  CC     cgminer-cgminer.o
  CC     cgminer-util.o
  CC     cgminer-sha2.o
  CC     cgminer-api.o
api.c: In function ‘api’:
api.c:2409: error: label at end of compound statement
make[2]: *** [cgminer-api.o] Error 1
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make: *** [all] Error 2

Tested with NVIDIA and ATi/AMD OpenCL's. OS: Linux x86. GCC: 4.3.

Well all I can guess is there must be something wrong with your compiler or something messed up about your git pull/clone or some issue with the ./configure options you used.

The "die:" label has been there since 2011-11-24 (go to https://github.com/ckolivas/cgminer/blame/master/api.c to check for yourself)
Also the code compiles fine on quite a few architectures including xubuntu, fedora 16, debian, MinGW on windows
I've even just done another git pull and compiled it.

What git pull/clone command did you use and what ./configure command did you use?

If you pulled on top of an old version, make sure you './autogen.sh' './configure --xxx' and 'make clean' again before compiling.

[Zenitur]

Well all I can guess is there must be something wrong with your compiler or something messed up about your git pull/clone or some issue with the ./configure options you used.

The "die:" label has been there since 2011-11-24 (go to https://github.com/ckolivas/cgminer/blame/master/api.c to check for yourself)
Also the code compiles fine on quite a few architectures including xubuntu, fedora 16, debian, MinGW on windows
I've even just done another git pull and compiled it.

What git pull/clone command did you use and what ./configure command did you use?

If you pulled on top of an old version, make sure you './autogen.sh' './configure --xxx' and 'make clean' again before compiling.

I have not used GIT to get the latest copy of CGMINER. I've downloaded all archives of 2.3.x versions of it, and tried to compile in Debian 5.0 "Lenny". All versions before 2.3.4 compiled successfully.

[Inaba]

I've run into that problem.  Try:

make clean
./autogen.sh
./configure
make

[ancow]

I have not used GIT to get the latest copy of CGMINER. I've downloaded all archives of 2.3.x versions of it, and tried to compile in Debian 5.0 "Lenny". All versions before 2.3.4 compiled successfully.

In case Inaba's suggestion doesn't work, could you try the latest git pull to see if that compiles? And if not, do a git bisect to trace the commit that is causing your problems?

[Tinua]

cgminer does not seem to detect my connected bfl single ... is there a setting that i'm missing?

If you are in Windows, your basic command line should look something like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6

The '-S COM6' is the relevant part for your Single. It happens to be COM6 for me, but it will likely be something else for you.

You'll need to open up Device Manager, go to the Ports section, and you should see an entry that looks like 'USB Serial Port (COMx)'. Whatever 'COMx' is in your case, that's what you put into cgminer's '-S COMx' setting. Then your Single should be detected.

edit: I should add that if your COM port is greater than 9, you need to use the 'longhand' form for cgminer. So if, for example, your assigned COM port for your Single was COM12, your command line would need to look like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S \\.\COM12

Hi folks

If I connect more then 10 BFL's....cgminer crash by starting?
If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

[check_status]

Using cgminer 2.3.2
Cgminer hangs or freezes, the curl display is unresponsive not accepting any keyboard commands, mining has stopped, system is not frozen or locked up.
What is the recommended method to start up mining again?
Is it OK to 'kill <cgminer pid>' before starting a new session?

[phorensic]

cgminer does not seem to detect my connected bfl single ... is there a setting that i'm missing?

If you are in Windows, your basic command line should look something like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6

The '-S COM6' is the relevant part for your Single. It happens to be COM6 for me, but it will likely be something else for you.

You'll need to open up Device Manager, go to the Ports section, and you should see an entry that looks like 'USB Serial Port (COMx)'. Whatever 'COMx' is in your case, that's what you put into cgminer's '-S COMx' setting. Then your Single should be detected.

edit: I should add that if your COM port is greater than 9, you need to use the 'longhand' form for cgminer. So if, for example, your assigned COM port for your Single was COM12, your command line would need to look like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S \\.\COM12

Hi folks

If I connect more then 10 BFL's....cgminer crash by starting?
If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

Before anyone bashes him on using Windows 8, I would like to say I'm using Windows 8 to mine, with cgminer, and it's working flawlessly.  Mind you I don't have FPGA's or 10+ devices, though.