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

[mutluit]

You are always mining at the current network diff when solo mining so any "shares" submitted are effectively considered the network diff so any rejects will be shown to be at the network diff as well. "Diff shares" is number of shares (in this case 1) multiplied by the difficulty you're mining at (in this case network diff). You definitely didn't even get close to the network diff but the software decided to try submitting a share anyway and it got rejected. You can see what your best share was, it was only 26,500 when network diff is 708 billion.

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

[-ck]

You are always mining at the current network diff when solo mining so any "shares" submitted are effectively considered the network diff so any rejects will be shown to be at the network diff as well. "Diff shares" is number of shares (in this case 1) multiplied by the difficulty you're mining at (in this case network diff). You definitely didn't even get close to the network diff but the software decided to try submitting a share anyway and it got rejected. You can see what your best share was, it was only 26,500 when network diff is 708 billion.

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

A harmless bug, but a bug yes. Are you running the current version?

[mutluit]

You are always mining at the current network diff when solo mining so any "shares" submitted are effectively considered the network diff so any rejects will be shown to be at the network diff as well. "Diff shares" is number of shares (in this case 1) multiplied by the difficulty you're mining at (in this case network diff). You definitely didn't even get close to the network diff but the software decided to try submitting a share anyway and it got rejected. You can see what your best share was, it was only 26,500 when network diff is 708 billion.

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

A harmless bug, but a bug yes. Are you running the current version?

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

[-ck]

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

Well that would explain the breakage then. No idea about opkg versions, but additionally I don't believe any of the antminer forks remotely tried to stay in sync with the master cgminer.

[mutluit]

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

Well that would explain the breakage then. No idea about opkg versions, but additionally I don't believe any of the antminer forks remotely tried to stay in sync with the master cgminer.

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.

[-ck]

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

Well that would explain the breakage then. No idea about opkg versions, but additionally I don't believe any of the antminer forks remotely tried to stay in sync with the master cgminer.

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.

And as I said, I have no idea about opkg packages. I have nothing to do with their maintenance.

[bgibso01]

Anyone happen to know if I run CGMiner solo (w/ btc address) and point to a pruned node without a wallet, would the miner still receive the block rewards or is it based on bitcoind wallet address?

[mutluit]

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

Well that would explain the breakage then. No idea about opkg versions, but additionally I don't believe any of the antminer forks remotely tried to stay in sync with the master cgminer.

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.

And as I said, I have no idea about opkg packages. I have nothing to do with their maintenance.

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

[traderyo]

newb question so I apologise in advance:

What coins does CGminer actually support, where can I find this information? I cannot seem to find it anywhere?

[-ck]

newb question so I apologise in advance:

What coins does CGminer actually support, where can I find this information? I cannot seem to find it anywhere?

"Anywhere"? First line of the readme, last word.

[Dropwise]

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

[-ck]

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

Any chance you could get a backtrace? Google's gone crazy with blocking my website again so you may have to override security settings if you're on chrome.

http://ck.kolivas.org/apps/cgminer/debug/README-debug

[Dropwise]

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

Any chance you could get a backtrace? Google's gone crazy with blocking my website again so you may have to override security settings if you're on chrome.

http://ck.kolivas.org/apps/cgminer/debug/README-debug

Sorry, not completely sure I follow you here.  You want me to rebuild with debugging and send you the logs, or you want me to sign up for backtrace service?  Can I please ask you to elaborate?

[-ck]

Any chance you could get a backtrace? Google's gone crazy with blocking my website again so you may have to override security settings if you're on chrome.

http://ck.kolivas.org/apps/cgminer/debug/README-debug

Sorry, not completely sure I follow you here.  You want me to rebuild with debugging and send you the logs, or you want me to sign up for backtrace service?  Can I please ask you to elaborate?

Rebuild with debugging and get backtrace output as described in the README-debug I linked above.

[mutluit]

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

[cameloid]

Hi mutluit,

you may try to use my cgminer 4.10 build for S3: https://yadi.sk/d/CVhgXxmN3K2SBw

It works flawlessly.

[mutluit]

Hi mutluit,

you may try to use my cgminer 4.10 build for S3: https://yadi.sk/d/CVhgXxmN3K2SBw

It works flawlessly.

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

[mutluit]

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.

[-ck]

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.

The S3 code in master cgminer filters out low diff nonces.

[mutluit]

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.

The S3 code in master cgminer filters out low diff nonces.

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