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

[vickz]

Hello -CK may we ask if I'll start to this one do i need a miner(Hardware I mean) or just my computer/laptop?

That's a noob question kindly answer..

Thanks,

[os2sam]

Hello -CK may we ask if I'll start to this one do i need a miner(Hardware I mean) or just my computer/laptop?

That's a noob question kindly answer..

Thanks,

From the Top Post

This is the official thread for support and development of cgminer, the ASIC bitcoin miner ... There is NO SUPPORT for CPU, GPU or altcoin mining in this thread, nor older versions with that functionality, nor any support for unofficial forks of this code.

[mutluit]

Hello -CK may we ask if I'll start to this one do i need a miner(Hardware I mean) or just my computer/laptop?

That's a noob question kindly answer..

Thanks,

As os2sam wrote, CPU and GPU mining have become "obsolete" in profitable bitcoin mining. Nowadays one needs fast ASIC mining device(s) to have a chance in finding a block, or to participate in pool mining.
Current state of the art miner seems to be the AntMiner S9 or T9 or something.
Check also ebay for used miners. If you can afford then get one with more than 1 TH/s hashing speed, better would be > 4 TH/s, or the above mentioned one with about 14 TH/s.
You have to pay the electricity these devices consume (for example my S3 consumes about 0.36 kW/h, and the electricity cost for running it a month is 30 * 24 * 0.36 * $0.12 = $31.10 )
Before investing I would suggest to consult an online calculator for cryptocoin mining to get an idea about the profitability or lack of it...
The more hashing power your device(s) have and the cheaper your electricity is, the better...
But beware: these bigger devices are very loud (caused by their hi-speed/hi-power fans to cool the ASICs)  :-)

As said, you should ask non-cgminer related questions in the other discussion threads here.

[mutluit]

Hi ck,
there is an unimportant, but nasty :-), warning when doing make:

   --define-variable argument does not have a value for the variable

I think this has to be fixed in configure.ac somewhere in or around these lines:

PKG_PROG_PKG_CONFIG()

if test "x$have_cgminer_sdk" = "xtrue"; then
        if test "x$have_x86_64" = xtrue; then
                ARCH_DIR=x86_64
        else
                ARCH_DIR=x86
        fi
        PKG_CONFIG="${PKG_CONFIG:-pkg-config} --define-variable=arch=$ARCH_DIR --define-variable=target=$target --define-variable=cgminersdkdir=$CGMINER_SDK"
        PKG_CONFIG_PATH="$CGMINER_SDK/lib/pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}"
fi


or maybe in one of the *.in files?
Or should one set an environment variable CGMINER_SDK ?

[vayvanne]

Is it only me or others also constantly getting messages about testing pool on solo mining?
One more issue to mention, 4.10.0 does not write config file and does not load working in v.4.9.2 (and pretty trivial one) config file.

[mutluit]

Is it only me or others also constantly getting messages about testing pool on solo mining?
One more issue to mention, 4.10.0 does not write config file and does not load working in v.4.9.2 (and pretty trivial one) config file.

Don't know if related, but the parameter --fix-protocol seems to prevent switching from gbt to stratum if the http server offers both.

Regarding the other issues: don't know, haven't tried yet; I'm passing all parameters via commandline (actually in a batch script file).

[mutluit]

Hi ck, please take a look at this:

driver-bitmain.c, line# ~ 2753:

                        sendret = bitmain_send_data(sendbuf, sendlen, bitmain);
                        if (unlikely(sendret == BTM_SEND_ERROR)) {
                                applog(LOG_ERR, "%s%d: send status comms error",
                                                bitmain->drv->name, bitmain->device_id);
                                //dev_error(bitmain, REASON_DEV_COMMS_ERROR);
                                info->reset = true;
                                info->errorcount++;
                                senderror = 1;
                                if (info->errorcount > 1000) {
                                        info->errorcount = 0;
                                        applog(LOG_ERR, "%s%d: Device disappeared,"
                                                        " shutting down thread",
                                                        bitmain->drv->name, bitmain->device_id);
                                        bitmain->shutdown = true;
                                }
                        } else {
                                info->errorcount = 0;
                                if (info->fifo_space <= 0) {
                                        senderror = 1;
                                }
                        }

In this code block bitmain_send_data() succeeds and it goes into the else branch.
But there "senderror = 1" will be executed if fifo_space <= 0.
And if senderror is set to 1 then in later part of the code a penalty pausing of 50ms is done.
I don't understand why senderror gets set if the bitmain_send_data() already succeeded.
I think in the success case the testing for fifo_space shouldn't be done, IMO. Isn't it?

[vayvanne]

Is it only me or others also constantly getting messages about testing pool on solo mining?
One more issue to mention, 4.10.0 does not write config file and does not load working in v.4.9.2 (and pretty trivial one) config file.

Don't know if related, but the parameter --fix-protocol seems to prevent switching from gbt to stratum if the http server offers both.

Regarding the other issues: don't know, haven't tried yet; I'm passing all parameters via commandline (actually in a batch script file).

Thanks for the reply. Do I need to upgrade the miner to 4.10.0 at all to mine a segwit blocks? The backend is bitcoin core 0.14.2.

[-ck]

Is it only me or others also constantly getting messages about testing pool on solo mining?
One more issue to mention, 4.10.0 does not write config file and does not load working in v.4.9.2 (and pretty trivial one) config file.

Don't know if related, but the parameter --fix-protocol seems to prevent switching from gbt to stratum if the http server offers both.

Regarding the other issues: don't know, haven't tried yet; I'm passing all parameters via commandline (actually in a batch script file).

Thanks for the reply. Do I need to upgrade the miner to 4.10.0 at all to mine a segwit blocks? The backend is bitcoin core 0.14.2.

No. Current cgminer is segwit compatible.

[vayvanne]

Is it only me or others also constantly getting messages about testing pool on solo mining?
One more issue to mention, 4.10.0 does not write config file and does not load working in v.4.9.2 (and pretty trivial one) config file.

Don't know if related, but the parameter --fix-protocol seems to prevent switching from gbt to stratum if the http server offers both.

Regarding the other issues: don't know, haven't tried yet; I'm passing all parameters via commandline (actually in a batch script file).

Thanks for the reply. Do I need to upgrade the miner to 4.10.0 at all to mine a segwit blocks? The backend is bitcoin core 0.14.2.

No. Current cgminer is segwit compatible.

Hi -ck,
I see the release notes for 4.10.0 regarding the segwit support, but it has memory leak in windows build in solo mode and I would prefer 4.9.2 to continue to use.
Theoretically, segwit could be implemented totally in bitcoin core, under the RPC calls so that the miner software would not need any changes to support it. My question (and my setup in general) is for learning purposes mainly.
So do I get correctly, that cgminer 4.9.2 does not have (requiring) segwit support and blocks found would be discarded now?
Many thanks.

[o_solo_miner]

I am not ck but the answer to that question is:
you can use older cgminer Versions, but not an old core version.
So you need as minimum core version 14.0.0 (Segwit support)
AND
you have to add a patch to it so you are not building up on wrong blocks!

[Anonymailer]

Hey, it's been a while but I'm going to finally update the compiled version of cgminer for mac I distribute and update MacMiner with it (the link you provide for Mac versions only goes up to 4.3.3 btw, I distribute mine at http://macminer.fabulouspanda.com/commandline/cgminer/ )

Since it's been so long, could you please let me know which devices I can --enable for maximum support without causing any conflicts?
Sorry to be an idiot, found the readme suggesting
--enable-avalon
--enable-avalon2
--enable-avalon4
--enable-bflsc
--enable-bitfury
--enable-cointerra
--enable-drillbit
--enable-hashfast
--enable-hashratio
--enable-icarus
--enable-klondike

[nkamitaki]

Is it only me or others also constantly getting messages about testing pool on solo mining?
One more issue to mention, 4.10.0 does not write config file and does not load working in v.4.9.2 (and pretty trivial one) config file.

Dear CK,

I am experiencing a Segmentation Fault (core dumped) error when trying to write config file in version 4.10.0.   (I do not have this error with version 4.9.2).  

(it seems to write over cgminer.conf with an empty file, then crash)

I am running on R-PI, ARCH.    

Any advice?

Thanks!

This didn't seem to get any kind of acknowledgement. I'm following it up here to see if anyone can help??

Just registered to chime in as I happened to be running into this myself and had thought it might be a quirk from compiling/running with MacOSX.  I haven't done much digging into it, and when I get a chance I'll try the debug backtrace mentioned already.  I can also confirm that on my system the problem arises between 4.9.2 and 4.10.0 releases.

In case it might be useful to those more familiar with the code, a few crude tests by way of re-building seem to isolate the problem to setting '--enable-icarus' during configuration.   That is, including all of the non-standalone drivers minus icarus seems to have a functioning write_config on my system.  So do not think this is something to do with all parsing/writing for settings, but may be specific to one or more introduced with icarus support.

[-ck]

Just registered to chime in as I happened to be running into this myself and had thought it might be a quirk from compiling/running with MacOSX.  I haven't done much digging into it, and when I get a chance I'll try the debug backtrace mentioned already.  I can also confirm that on my system the problem arises between 4.9.2 and 4.10.0 releases.

In case it might be useful to those more familiar with the code, a few crude tests by way of re-building seem to isolate the problem to setting '--enable-icarus' during configuration.   That is, including all of the non-standalone drivers minus icarus seems to have a functioning write_config on my system.  So do not think this is something to do with all parsing/writing for settings, but may be specific to one or more introduced with icarus support.

Sounds feasible. It's likely to be missing save for the options added to icarus post 4.9.2

[nkamitaki]

Just registered to chime in as I happened to be running into this myself and had thought it might be a quirk from compiling/running with MacOSX.  I haven't done much digging into it, and when I get a chance I'll try the debug backtrace mentioned already.  I can also confirm that on my system the problem arises between 4.9.2 and 4.10.0 releases.

In case it might be useful to those more familiar with the code, a few crude tests by way of re-building seem to isolate the problem to setting '--enable-icarus' during configuration.   That is, including all of the non-standalone drivers minus icarus seems to have a functioning write_config on my system.  So do not think this is something to do with all parsing/writing for settings, but may be specific to one or more introduced with icarus support.

Sounds feasible. It's likely to be missing save for the options added to icarus post 4.9.2

Hmm, I think I found it after that suggestion - it looks like a line is needed in the write_config of cgminer.c for the newly introduced 'set_float_100_500', such as at L5459:

if (opt->type & OPT_HASARG &&
             ((void *)opt->cb_arg == (void *)set_float_125_to_500 ||
             (void *)opt->cb_arg == (void *)set_float_100_to_500 ||
              (void *)opt->cb_arg == (void *)set_float_100_to_250)) {
            fprintf(fcfg, ",\n\"%s\" : \"%.1f\"", p+2, *(float *)opt->u.arg);
            continue;
         }

This was necessitated upon expanding the Compac GekkoScience frequency range here: https://github.com/ckolivas/cgminer/commit/702b37007caa9605d3adabf646f8df47fe86e83c

Making that change now has config writing when setting '--enable-icarus' during configuation for me.

[vayvanne]

I am not ck but the answer to that question is:
you can use older cgminer Versions, but not an old core version.
So you need as minimum core version 14.0.0 (Segwit support)
AND
you have to add a patch to it so you are not building up on wrong blocks!

Can -ck confirm this please?

[-ck]

I am not ck but the answer to that question is:
you can use older cgminer Versions, but not an old core version.
So you need as minimum core version 14.0.0 (Segwit support)
AND
you have to add a patch to it so you are not building up on wrong blocks!

Can -ck confirm this please?

You need minimum bitcoin core 0.14.0, correct. Older versions of cgminer that don't explicitly have segwit support but have solo mining support will still be able to mine valid blocks but they will only mine classic transactions without the segwit commitment or any segwit transactions so realistically you should be using the latest cgminer as well.

[mutluit]

isdupnonce() tests whether a found nonce was already found.
I wonder under what circumstances such a dupe nonce ever can happen at all.
Can it ever happen with solo mining?

[mutluit]

Every 2 minutes or so the device reports a nonce error.
What is the definition of such a nonce error? Why does it happen?

[DrakonX]

Does every USB port have an ID that can be optained via cgminer in order to see which of your ASIC miners is broken?