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

[canford]

4.2.2 breaks Cgminer Status Summary display on the Avalon Mini, reverted to 4.2.1.  4.2.2 working on Windows 7 with BE's.

To state that correctly: the luci code to display the API has been broken since it was first written - both in the Avalon and the Ant (the Ant simply copied the Avalon code and then broke it even more)
It doesn't use the field names to find the data, it numerically indexes into the data.

The API output (since I first wrote it) has always had the same key names to the same data, and that hasn't changed with 4.2.2
4.2.2 has simply added more fields to the summary between "MHS 5s" and "Found Blocks"

When you have a set of "Name"->"Data", it is foolish to not use "Name" to locate "Data"

Thanks kano, I thought that might be the case.  Rather than dig through the lua code, I just reverted back to the 4.2.1 Avalon image that ckolivas had posted.  I figured it was the luci code making an incorrect assumption about the API data.  Annoying that both the Antminer and Avalon have these assumptions in them.

[kano]

4.2.2 breaks Cgminer Status Summary display on the Avalon Mini, reverted to 4.2.1.  4.2.2 working on Windows 7 with BE's.

To state that correctly: the luci code to display the API has been broken since it was first written - both in the Avalon and the Ant (the Ant simply copied the Avalon code and then broke it even more)
It doesn't use the field names to find the data, it numerically indexes into the data.

The API output (since I first wrote it) has always had the same key names to the same data, and that hasn't changed with 4.2.2
4.2.2 has simply added more fields to the summary between "MHS 5s" and "Found Blocks"

When you have a set of "Name"->"Data", it is foolish to not use "Name" to locate "Data"

Thanks kano, I thought that might be the case.  Rather than dig through the lua code, I just reverted back to the 4.2.1 Avalon image that ckolivas had posted.  I figured it was the luci code making an incorrect assumption about the API data.  Annoying that both the Antminer and Avalon have these assumptions in them.

When I next see Xiangfu in IRC I'll ask if he can fix the lua in their master git.

[KNK]

New release: 4.2.2, 29th March 2014

It seems getwork is broken with this release (and 4.2.1) - all shares are rejected, but going back to 4.2 fixes the problem

[-ck]

New release: 4.2.2, 29th March 2014

It seems getwork is broken with this release (and 4.2.1) - all shares are rejected, but going back to 4.2 fixes the problem

Where would you use getwork today?

[kano]

Hi all.
I've made a full release of linux 4.2.2a/bab binaries in my cgminer-binaries git.
https://github.com/kanoi/cgminer-binaries

As before, there are Fedora 18, Ubuntu 11.04, RPi Arch and RPi Raspbian
... and of course now Ant OpenWrt

The Ant OpenWRT binary cgminer-ants1-4.2.2a-7b8fb34 is (as always) described here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

To get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-4.2.2a
chmod +x cgminer-4.2.2a
mv cgminer-4.2.2a cgminer

The 5 others are:
https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-4.2.2a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-4.2.2a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-4.2.2bab
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-4.2.2a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-4.2.2bab

All 4.2.2a are all USB only:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-avalon --enable-bflsc --enable-bitforce --enable-bitfury --enable-drillbit --enable-hashfast --enable-icarus --enable-klondike --enable-modminer

All RPi 4.2.2bab are BlackArrow Bitfury GPIO and all USB:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-avalon --enable-bflsc --enable-bitforce --enable-bitfury --enable-drillbit --enable-hashfast --enable-icarus --enable-klondike --enable-modminer --enable-bab
If you only have BlackArrow Bitfury GPIO devices - i.e. no USB mining devices attached also - then you can add the command line option --usb :0 when you run cgminer and it won't look for any USB devices

The BaB driver with 7 boards uses less than 10% CPU on RPI Arch - and for my 7 BA BaB boards, mines at over 270GH/s
It seems to be limited to 2 boards per SPI channel. More tends to get all sorts of errors.
Will look into resolving that ... one day.

The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.

Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 4.2.2) then click on the file you want then right-click save-as the "View Raw" link.

[KNK]

Where would you use getwork today?

DeepBit is still getwork only ... almost dead, because of that.

[-ck]

Where would you use getwork today?

DeepBit is still getwork only ... almost dead, because of that.

Ah yes, out of sight, out of mind because of it too. I wasn't even sure there was anywhere I could even test it to fix it.

[-ck]

Where would you use getwork today?

DeepBit is still getwork only ... almost dead, because of that.

Ah yes, out of sight, out of mind because of it too. I wasn't even sure there was anywhere I could even test it to fix it.

Okay, fixed it in git.

[KNK]

Okay, fixed it in git.

Thanks, that was fast. It works now.

And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
If I switch to nonces, the results for 1min, 5min etc are correct, but will loose the information about the actual hashes done ... is there a way/API to have them both or i should do it inside get_statline_before() call?
EDIT: Ended with a new line of details in get_statline() showing the expected hashrate based on the hashes done. /EDIT

Oh and one more minor bug - the details returned from get_statline_before() are destroyed and do no longer appear when zero api is called with 'all,true', but is OK with false i.e. print_summary() is causing it.
Te reason is that at line 8567 inside that function the calls are set to blank_get_statline_before and never restored

[Fraggle]

Hi all.
Just got an antminer U2. for trial but cant get it to run. I keep getting  " err-99 libusb failed to start "
Running win 7  64 bit, installed driver using zadig , WinUSB v6.1.7600.16385 .
Tried driver updates, running in and out of admin, restarting and or repluging after , even get this message with just Cgminer exe , no u2 , no command line.
Got me frizzed.
Any help would be good !

[-ck]

Hi all.
Just got an antminer U2. for trial but cant get it to run. I keep getting  " err-99 libusb failed to start "
Running win 7  64 bit, installed driver using zadig , WinUSB v6.1.7600.16385 .
Tried driver updates, running in and out of admin, restarting and or repluging after , even get this message with just Cgminer exe , no u2 , no command line.
Got me frizzed.
Any help would be good !

What version of cgminer? There were some generic changes done to the windows libusb for 4.2.2 but no one has tested them or reported back. If you were on 4.2.2, try 4.2.1 which doesn't have those changes, or vice versa.

[techman05]

Hi I would like to know if there is a way to api an antminer s1. I thought I saw an enable command for cgminer for antminer s1 in your readme but I don't think I saw a command to call an antminer to a pc or Linux box. Where would I look for further to this.

Thanks

[crazyates]

Hi I would like to know if there is a way to api an antminer s1. I thought I saw an enable command for cgminer for antminer s1 in your readme but I don't think I saw a command to call an antminer to a pc or Linux box. Where would I look for further to this.

Thanks

https://bitcointalk.org/index.php?topic=499837.0

[-ck]

There were some generic changes done to the windows libusb for 4.2.2 but no one has tested them or reported back.

Further to this discussion, are there any windows users who can confirm any change or otherwise of the latest version? Specifically any change from working to non-working, or those with USB3 slots that previously never worked that have tried this version?

[Fraggle]

Well that could be the problem in a nut shell. I unpacked V 3.12.3- windows.
I will punctually get 4.2.2 and post the results.
Thanks

[kano]

...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...

All drivers return the number of hashes done.
You must have messed something (else?) up somewhere.

[Fraggle]

Well ver 4.2.2 resulted in the exact same message. " libusb_failed to load err -99 "
Wondering if I may have installed the wrong driver first.
Does reinstalling the driver completely over write the first attempt ?
This has stumped 2 other IT guys.  lol

[kano]

Well ver 4.2.2 resulted in the exact same message. " libusb_failed to load err -99 "
Wondering if I may have installed the wrong driver first.
Does reinstalling the driver completely over write the first attempt ?
This has stumped 2 other IT guys.  lol

zadig will tell you which driver is loaded for each mining device.

[KNK]

...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...

All drivers return the number of hashes done.
You must have messed something (else?) up somewhere.

Not true - BaB driver returns the nonces found:

Code:

hashcount += 0xffffffffull * babinfo->new_nonces;

My driver was returning the actual hashrate of the chip, which does not change with the luck and hardware errors, but with voltage fluctuations only.
I have switched to nonces found and provide the actual hashrate separately now. (EDIT: it doesn't fluctuate much anyway)

[-ck]

...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...

All drivers return the number of hashes done.
You must have messed something (else?) up somewhere.

Not true - BaB driver returns the nonces found:

Code:

hashcount += 0xffffffffull * babinfo->new_nonces;

My driver was returning the actual hashrate of the chip, which does not change with the luck and hardware errors, but with voltage fluctuations only.
I have switched to nonces found and provide the actual hashrate separately now. (EDIT: it doesn't fluctuate much anyway)

No driver directly displays the raw hashrate because virtually every piece of hardware has a wastage rate, be that lost work or hardware errors, and as a rule in our mainline drivers only the effective hashrate is shown based on share return since that is the one that most accurately represents the effective useful hashrate to the miner. Some drivers like to have their raw hashrate in the API as well but it's mostly used for debugging or finding when a large discrepancy occurs between that and the share based return hashrate. The most comprehensive hashrate breakdown exists in the cointerra driver, as per the example below:

From API devs (all drivers get this from cgminer but it's still a share based hashrate):

Code:

  [MHS av] => 799191.36
   [MHS 5s] => 835744.05
   [MHS 1m] => 802133.15
   [MHS 5m] => 814257.17
   [MHS 15m] => 813622.90

From API stats (device specific implementation):

Code:

  [Calc hashrate] => 809023317013
   [Hashrate] => 809235851416
   [Share hashrate] => 799187431945
   [Total calc hashes] => 66713335626117819
   [Total hashes] => 66730861547342974
   [Total raw hashes] => 66856703711606415
   [Total share hashes] => 65902253067730944
   [Total flushed hashes] => 5497557985280
   [Accepted hashes] => 66573727231544920
   [Accepted hashrate] => 807330305483
   [Rejected hashes] => 370758174404046
   [Rejected hashrate] => 4496132673
   [Core0 hashrate] => 98977953653
   [Core1 hashrate] => 72667358378
   [Core2 hashrate] => 101483724632
   [Core3 hashrate] => 102736610121
   [Core4 hashrate] => 101483724632
   [Core5 hashrate] => 120277006971
   [Core6 hashrate] => 85196213271
   [Core7 hashrate] => 96472182675
   [Asic0Core0] => 120:fffefffefffefffefffefffefffefffe
   [Asic0Core1] => 120:fffefffefffefffefffefffefffefffe
   [Asic0Core2] => 120:fffefffefffefffefffefffefffefffe
   [Asic0Core3] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core0] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core1] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core2] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core3] => 120:fffefffefffefffefffefffefffefffe