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

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?

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?

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

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 ?

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.

Ah, good to know about that filtering.
What rule gets used in the filtering? Where in the code is it done?
Thx


UPDATE:
ok, I think I found the location in driver-bitmain.c:

                diffbits = (int)floor(log2(DATAW(witem)->work->sdiff));
                if (diffbits < 0)
                        diffbits = 0;
                // Limit to 4096 so solo mining has reasonable mining stats
                if (diffbits > 12)
                        diffbits = 12;

Replacing this block of code with just "diffbits = 0;" seems to revert it to the default behavior.
But this of course leads to eating up much CPU cycles and the hash rate of the device falls significantly.
Yes, the filtering makes much sense; I'll need to modify my test-code to adapt to the original filtering...

Hmm. maybe discovered a new problem with 4.10.0:

in previous versions for each found nonce it had printed such lines (with --debug option enabled)
Proof: %s
Target: %s
TrgVal?...

But in this version I don't see any such lines printed ever, eventhough work units get counted in the stats.

FYI: a submit_work for a new block happens only after the above things, ie. if the former isn't called ever then a submit can never happen... :-)

Can anybody confirm this?


UPDATE:
The ASIC's usually return a nonce if at least the first 32 bits of the found hash are 0 (I think this is called a Work Unit).
But something doesn't fit with 4.10.0 as it finds only a few nonces (ie. the "Proof" lines printed).
I'm testing this on AntMiner S3. Or is the definition of such a WU differrent under AntMiner S3?

Dear author, can you please comment on this important issue as it could be a big bug affecting many people, thx.

Hi, thank you.
But here this too prints some gigantic/unrealistic WU rates, and hash rates in the TH/s range, see below.
If we assume that the TH/s means GH/s then I observed that the hash rate after a few hours sinks down from 450 to about 200 GH/s. Does this not happen with your S3?
BTW, I think your binary has all drivers included as the size of the binary is about twice the size compared to mine that has only the code for S3 enabled.


^C [2017-07-24 09:58:30.888] Shutdown signal received.                    
 [2017-07-24 09:58:30.979]
Summary of runtime statistics:
                    
 [2017-07-24 09:58:30.979] Started at [2017-07-24 09:56:36.980]                    
 [2017-07-24 09:58:30.979] Pool: http://37.139.71.2:8332                    
 [2017-07-24 09:58:30.979] Runtime: 0 hrs : 1 mins : 53 secs                    
 [2017-07-24 09:58:30.979] Average hashrate: 416358026.8 Mhash/s                    
 [2017-07-24 09:58:30.979] Solved blocks: 0                    
 [2017-07-24 09:58:30.980] Best share difficulty: 1.36K                    
 [2017-07-24 09:58:30.980] Share submissions: 0                    
 [2017-07-24 09:58:30.980] Accepted shares: 0                    
 [2017-07-24 09:58:30.980] Rejected shares: 0                    
 [2017-07-24 09:58:30.980] Accepted difficulty shares: 0                    
 [2017-07-24 09:58:30.980] Rejected difficulty shares: 0                    
 [2017-07-24 09:58:30.980] Hardware errors: 0                    
 [2017-07-24 09:58:30.980] Utility (accepted shares / min): 0.00/min                    
 [2017-07-24 09:58:30.980] Work Utility (diff1 shares solved / min): 5816454.46/min
                    
 [2017-07-24 09:58:30.980] Stale submissions discarded due to new blocks: 0                    
 [2017-07-24 09:58:30.981] Unable to get work from server occasions: 0                    
 [2017-07-24 09:58:30.981] Work items generated locally: 9290                    
 [2017-07-24 09:58:30.981] Submitting work remotely delay occasions: 0                    
 [2017-07-24 09:58:30.981] New blocks detected on network: 2
                    
 [2017-07-24 09:58:30.981] Summary of per device statistics:
                    
 [2017-07-24 09:58:30.981] AS3 0 (10s):422.0T (avg):416.4Th/s | A:0 R:0 HW:0 WU:5816454.5/m                    
 [2017-07-24 09:58:30.981]                      


'''''''''''''''''''''''''''
UPDATE:
'''''''''''''''''''''''''''
It seems that since version 4.7.0 some of the bitmain parameters have changed.
So, after renaming the config file /etc/config/cgminer, and using the following params
now version 4.10.0 seems to work fine in the console:

     --bitmain-voltage 0725 \
     --bitmain-freq    16:250:0982 \
     --bitmain-options 115200:32:32:16:250:0982 \
     --bitmain-fan     20-100 \
     --bitmain-auto \
     --bitmain-notempoverctrl --bitmain-nobeeper --bitmain-checkn2diff --bitmain-hwerror \
     ...

So, then this case can be closed :-)


But I think the above given compiler warnings need to be fixed in the code. I had made the following modification in driver-bitmain.h to eliminate the warnings:

// #define BITMAIN_MAX_CHAIN_NUM      8
#define BITMAIN_MAX_CHAIN_NUM      16

Dear ck,

when compiling from the git master (and also the standalone 4.10.0) for the target AntMiner S3,
then the following warnings happen (IMHO it seems that a define in driver-bitmain.h is possibly set wrong):

driver-bitmain.c: In function 'bitmain_api_stats':
driver-bitmain.c:2952:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn10", &(info->chain_asic_num[9]), false);
       ^
driver-bitmain.c:2953:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn11", &(info->chain_asic_num[10]), false);
       ^
driver-bitmain.c:2954:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn12", &(info->chain_asic_num[11]), false);
       ^
driver-bitmain.c:2955:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn13", &(info->chain_asic_num[12]), false);
       ^
driver-bitmain.c:2956:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn14", &(info->chain_asic_num[13]), false);
       ^
driver-bitmain.c:2957:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn15", &(info->chain_asic_num[14]), false);
       ^
driver-bitmain.c:2958:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_int(root, "chain_acn16", &(info->chain_asic_num[15]), false);
       ^
driver-bitmain.c:2971:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs10", info->chain_asic_status_t[9], false);
       ^
driver-bitmain.c:2972:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs11", info->chain_asic_status_t[10], false);
       ^
driver-bitmain.c:2973:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs12", info->chain_asic_status_t[11], false);
       ^
driver-bitmain.c:2974:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs13", info->chain_asic_status_t[12], false);
       ^
driver-bitmain.c:2975:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs14", info->chain_asic_status_t[13], false);
       ^
driver-bitmain.c:2976:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs15", info->chain_asic_status_t[14], false);
       ^
driver-bitmain.c:2977:7: warning: array subscript is above array bounds [-Warray-bounds]
  root = api_add_string(root, "chain_acs16", info->chain_asic_status_t[15], false);
       ^


And a 2nd issue is this: instead of using the unit Giga it uses the unit Tera, with such gigantic results

 cgminer version 4.10.0 - Started: [2017-07-21 20:57:24.298]
 --------------------------------------------------------------------------------
  (30s):432.7T (1m):423.2T (5m):387.7T (15m):256.9T (avg):406.4Th/s
  A:0  R:0  HW:5  WU:5681473.1/m
  Connected to (null) diff 805G without LP as user xxx
  Block: b205ee53...  Diff:805G  Started: [21:12:29.503]  Best share: 7.93K
 --------------------------------------------------------------------------------
  USB management Pool management Settings Display options Quit
  0: AS3 0       : 34/ 37C 0900R           | 426.2T / 406.6Th/s WU:5680506.0/m
 --------------------------------------------------------------------------------

(testing solo-mining against a local bitcoind)

And when quitting it repeats the gigantic numbers/units:

 [2017-07-21 21:12:48.364] Shutdown signal received.
 [2017-07-21 21:12:48.457]
Summary of runtime statistics:

 [2017-07-21 21:12:48.457] Started at [2017-07-21 20:57:24.298]
 [2017-07-21 21:12:48.457] Pool: http://37.139.71.2:8332
 [2017-07-21 21:12:48.457] Runtime: 0 hrs : 15 mins : 24 secs
 [2017-07-21 21:12:48.457] Average hashrate: 406601478.9 Mhash/s
 [2017-07-21 21:12:48.458] Solved blocks: 0
 [2017-07-21 21:12:48.458] Best share difficulty: 7.93K
 [2017-07-21 21:12:48.458] Share submissions: 0
 [2017-07-21 21:12:48.458] Accepted shares: 0
 [2017-07-21 21:12:48.458] Rejected shares: 0
 [2017-07-21 21:12:48.458] Accepted difficulty shares: 0
 [2017-07-21 21:12:48.458] Rejected difficulty shares: 0
 [2017-07-21 21:12:48.458] Hardware errors: 5
 [2017-07-21 21:12:48.458] Utility (accepted shares / min): 0.00/min
 [2017-07-21 21:12:48.458] Work Utility (diff1 shares solved / min): 5681222.25/min

 [2017-07-21 21:12:48.458] Stale submissions discarded due to new blocks: 0
 [2017-07-21 21:12:48.459] Unable to get work from server occasions: 0
 [2017-07-21 21:12:48.459] Work items generated locally: 74893
 [2017-07-21 21:12:48.459] Submitting work remotely delay occasions: 0
 [2017-07-21 21:12:48.459] New blocks detected on network: 5

 [2017-07-21 21:12:48.459] Summary of per device statistics:

 [2017-07-21 21:12:48.459] AS3 0 (30s):425.2T (avg):406.6Th/s | A:0 R:0 HW:5 WU:5681222.3/m
 [2017-07-21 21:12:48.459]


A 3rd issue is that it wrongly says "Connected to (null)", cf. above.

Thx

Ah, it seems that the said cgminer version for openwrt was created some years ago with this fork: https://github.com/kanoi/cgminer/tree/ants1-4.9.1c-e6ad32a
as was announced then here: https://bitcointalk.org/index.php?topic=1249569.0

Maybe you got me wrong: I mean whether there is a newer binary version of cgminer available for the openwrt platform, ie. as a opkg-package.

It's cgminer version 4.7.1
Is there a newer openwrt opkg version available?

But why did the software do that? Isn't that a bug?

Either you are using this option:
  --text-only|-T      Disable ncurses formatted screen output

or else maybe your device lacks the library libncurses:

# opkg list libncurses
libncurses - 5.9-1 - Terminal handling library

Check, and if really missing then try to install it.

Hi,
while solo mining I got this log entry:

 [2017-07-06 12:14:52] Share submissions: 1
 [2017-07-06 12:14:52] Accepted shares: 0
 [2017-07-06 12:14:52] Rejected shares: 1
 [2017-07-06 12:14:52] Accepted difficulty shares: 0
 [2017-07-06 12:14:52] Rejected difficulty shares: 708659466230

At 2017-07-06 19:56 UTC:
$ bin/bitcoin-cli getdifficulty
  708659466230.332

Does it mean I missed it by the decimals??? :-(


UPDATE: today again such a case happened:

Summary of runtime statistics:
                   
 [2017-07-09 17:31:41] Started at [2017-07-09 17:04:34]                   
 [2017-07-09 17:31:41] Pool: http://37.139.71.2:8332                   
 [2017-07-09 17:31:41] Runtime: 0 hrs : 27 mins : 6 secs                   
 [2017-07-09 17:31:41] Average hashrate: 177583.4 Mhash/s                   
 [2017-07-09 17:31:41] Solved blocks: 0                   
 [2017-07-09 17:31:41] Best share difficulty: 26.5K                   
 [2017-07-09 17:31:41] Share submissions: 1                   
 [2017-07-09 17:31:41] Accepted shares: 0                   
 [2017-07-09 17:31:41] Rejected shares: 1                   
 [2017-07-09 17:31:41] Accepted difficulty shares: 0                   
 [2017-07-09 17:31:41] Rejected difficulty shares: 708659466230                   
 [2017-07-09 17:31:41] Reject ratio: 100.0%                   
 [2017-07-09 17:31:41] Hardware errors: 30                   
 [2017-07-09 17:31:41] Utility (accepted shares / min): 0.00/min                   
 [2017-07-09 17:31:41] Work Utility (diff1 shares solved / min): 2480.90/min
                   
 [2017-07-09 17:31:41] Stale submissions discarded due to new blocks: 0                   
 [2017-07-09 17:31:41] Unable to get work from server occasions: 0                   
 [2017-07-09 17:31:41] Work items generated locally: 69978                   
 [2017-07-09 17:31:41] Submitting work remotely delay occasions: 0                   
 [2017-07-09 17:31:41] New blocks detected on network: 2
                   
 [2017-07-09 17:31:41] Summary of per device statistics:
                   
 [2017-07-09 17:31:41] S1A0 (30s):180.8G (avg):177.6Gh/s | A:0 R:708659466230 HW:30 WU:2480                   
 [2017-07-09 17:31:41]                     


# cat share.log
1499619895,reject:high-hash,000000000000000000000000000000000000000000308d010000000000000000,http://37.139.71.2:8332,S1A0,0,0000000000000000000000000000000000000000000000000000000000000000,200000020829b3bff0c10fd348e41756aea13ad0d504ba28003d3b630000000000000000af3e784c5bfedc4b79b6f07c32e663759b2a9fc9755887d283e893ba5d7343ea5962622618018d3000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


Can the author or anybody else please tell me why and what's going on here? Thx

I need to compile the recent version to be run on AntMiner S1.
On the S1 there is not much space and also no gcc compiler installed.
I can compile it on the PC, but then I wonder if I need a cross-compiler since the target HW seems to be MIPS?

EDIT:
Ok, I finally figured it out: one of the methods is by using qemu and starting a linux mips distribution therein, and then the usual steps to build the binary...
Since qemu is an emulator, everything runs much slower, but no problem, I'm currently compiling it...

I think there is a big bug in cgminer's driver-icarus.c:

ICARUS_UNUSED_SIZE is defined as 16. IMO this should be 20.
ICARUS_WORK_DATA_OFFSET is defined as 64. IMO this should be 68.
(there are maybe even more wrong values)

Can you verify/confirm this?

So, have all the miners who use cgminer with icarus devices been misled?

BTW. the source code of this program is really a PITA to study :-(

I think video cards are not supported anymore in latest cgminer.
My tip: learn it first with a cheap USB stick miner (333 MH/s) --> configure with the parameter --enable-icarus
The method is similar with the bigger machines.

Wenn Sie mir die 50k leihen, dann bin ich dabei! :-)