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

[kano]

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

I followed the instructions (seems basic enough), but how can I verify that cgminer is the new version? I went to System > Software > Cgminer, and it still says 3.12.0-1. Is this normal?

https://github.com/kanoi/cgminer-binaries/issues/2

Added an extra comment there:

Also, the "cgminer-api version" command, when logged it, will show the cgminer version of what is running.
For cgminer-ants1-4.2.2a-7b8fb34 it will report:
[VERSION] =>
(
[ 0] => VERSION
[CGMiner] => 4.2.2a
[API] => 3.3
)

Edit: and
https://github.com/kanoi/cgminer-binaries/commit/abc6d019adc62bb6e41c2f3a165cd18f0b69b20b

[1534465952]

1534465952

[1534465952]

1534465952

[1534465952]

1534465952

[1534465952]

1534465952

[1534465952]

1534465952

[os2sam]

I'm pretty happy with my testing so far.  But the memory utilization is still climbing, 408MB so far.

Found this memory leak and it's now fixed in git, but there won't be a new version out just yet as I fix other issues first.

Thanks for the update.  I look forward to testing the new version when it's ready.

I've been testing version 4.2.2 for 2 days now and it looks like the memory utilization is stable at 16.5 MB RAM with GBT now.  Also it seems stable and reliable with BE's.

I would still like the ability to sign the block though.

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

I sent a donation for solo mining support.
Thanks,
Sam

[-ck]

I've been testing version 4.2.2 for 2 days now and it looks like the memory utilization is stable at 16.5 MB RAM with GBT now.  Also it seems stable and reliable with BE's.

I would still like the ability to sign the block though.

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

I sent a donation for solo mining support.

Thanks Sam. The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

[os2sam]

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

Maybe a "T" hotkey to do a toggle?

Thanks again,
Sam

[-ck]

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

Maybe a "T" hotkey to do a toggle?

Thanks again,
Sam

You can already toggle it from the display menu.

[os2sam]

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

Maybe a "T" hotkey to do a toggle?

Thanks again,
Sam

You can already toggle it from the display menu.

Toggle it or just enable/disable the switching every 5 seconds?

Anyway being able to toggle it on the fly from the main menu would be more better if that is possible, hopefully without redrawing the screen and loosing the share submissions view.

Just a thought no biggie either way to me.  I didn't mind the wider screen and wouldn't mind it being wider yet to include all of the useful info.
Sam

[kano]

...
I also now noticed there is a bug in LSTime that was mentioned earlier, the time isn't displayed properly.

Thanks for the update

Yeah a fix for that is looking unlikely now ... I've been looking into it in the last few hours ...

They changed the code that outputs the "Last Share Time" somewhere recently between Ant S1 versions.

So it makes it a bit beyond silly having the API break it's extremely reliable backward compatibility for a silly change like that ...
If it was a new field, that's no issue to add to my API hack/fix, but changing an existing field from a unix time number to a h:m:s string is a problem.

The new binary works great!

I got it back to a normal appearance rather than just the UNIX timestamp.

vi /usr/lib/lua/luci/controller/cgminer.lua

Find the part where it says: "--lst_date = os.date("%c", lst)" and get rid of comment (the --).

Had to do a reboot to get the change to show, buy you guys here probably know a better solution to reload luci/lua/whatever it is. I'm very new to all of this so hope it was somewhat helpful.

From:
         if lst == "0" then
            lst_date = "Never"
         else
            --lst_date = os.date("%c", lst)
           lst_date = lst
         end

To:

         if lst == "0" then
            lst_date = "Never"
         else
            lst_date = os.date("%c", lst)
            --lst_date = lst
         end

Added a comment to my README:
https://github.com/kanoi/cgminer-binaries/commit/98099e278126ba9f917f12f1e57e3d9a986917aa

[daddyfatsax]

I just got one of the new 1 TH/s rigs from China. The unit is running cgminer 3.9 and each blade is showing up as BA1. This unit is run off of a pi. Can I compile a newer cgminer and run that instead of the software supplied with the miner?

Sorry if this is a dumb question, but had to ask.

[kano]

I just got one of the new 1 TH/s rigs from China. The unit is running cgminer 3.9 and each blade is showing up as BA1. This unit is run off of a pi. Can I compile a newer cgminer and run that instead of the software supplied with the miner?

Sorry if this is a dumb question, but had to ask.

I've no idea, I haven't seen one.
Does it use the SPI bus or is it USB?

Also - could you request the code from Bitmain?
Since you have a cgminer binary, you have the right to request the code for it and they must supply it.

... and a 3rd update, apparently it's a BBB (Beagle Bone Black) not an RPi?
Is that what you see?

... 4th update, can you login to it (with ssh or putty using the web user password) and check if the source code was left on the BBB?
Maybe they did that to solve the issue of not releasing it (suggestion I was given by a US bitmain distributor)

[daddyfatsax]

It uses the SPI.

This one has Bitmine-A1 chips inside. They show up as BA1 in the cgminer web interface.

It has an Rpi inside of it. The pi that came with it was DOA. So I replaced it with a spare, and now the image on the SD is corrupted so I am using a previous version. The unit will only hash at 800 GH/s now, so I am assuming it is a clock setting I need to change.

I can SSH in without an issue. I am trying to compile 4.2.2 on it, but cannot enable Bitmine-A1.

Edit: This is the Chinese miner from LKETC that I got from a group buy done with pcfli.

[kano]

It uses the SPI.

This one has Bitmine-A1 chips inside. They show up as BA1 in the cgminer web interface.

It has an Rpi inside of it. The pi that came with it was DOA. So I replaced it with a spare, and now the image on the SD is corrupted so I am using a previous version. The unit will only hash at 800 GH/s now, so I am assuming it is a clock setting I need to change.

I can SSH in without an issue. I am trying to compile 4.2.2 on it, but cannot enable Bitmine-A1.

Edit: This is the Chinese miner from LKETC that I got from a group buy done with pcfli.

Oh, it's not an S2.
I thought it was.
OK, yeah there is A1 code but we've never seen any of the hardware so don't really know much about it.

[daddyfatsax]

I got 4.2.2 to compile and enabled bitmine-A1 but I just get his error when I start cgminer:
 [2014-04-02 08:16:03] Failed to init board selector                   
 [2014-04-02 08:16:03] SPI '/dev/spidev0.0': mode=1, bits=8, speed=2000000                   
 [2014-04-02 08:16:03] checking board 0...                   
 [2014-04-02 08:16:03] Failed to write to fdesc -1: Bad file descriptor

I will just stick with what I got for now.

Thanks.

[UselessCargo]

Trying to get an Adafruit "PiMiner" (http://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/initial-setup-and-assembly) up and running using Antminer U1's with the 16x2 LCD Display.

I was able to get 3.8.4 to work and display the information on the mini LCD screen correctly, but the sticks would not mine over 500Mhz, I'm assuming because I could only get them to be recognized and mine with Icarus enabled.

When I finally figured out that CGMiner 3.8.4 didn't seem to have the ability to enable Antminer U1 support (or at least it didn't seem to recognize the --enable-ants1 command after trying to configure it) I decided to try CGMiner 4.2.1 - it worked and solve my previous issue of the U1's hashing at ~500Mhz.  They now hash at 1.6Ghz as they're supposed to.

The problem now, though, is that the LCD display gives a formatting error - I'm assuming because of the changes in the way the software displays its mining information the 3.x.x versions of CGminer and the newer 4.x.x versions.  I'll admit I haven't yet tried using other 3.x.x versions (perhaps one of the 3.9.x's?) to see if they have Antminer U1 support and the original format for displaying mining information - I was hoping not to have to go through each of them looking and it seems that the README on ckolivas is only for the most up to date version (I couldn't find older versions of the README, if they exist, could someone point me to them?) - is there such a version of CGminer?

I do apologize if this has been covered already in this thread, but with over 700 pages of posts I felt that posting something fresh might provide a quicker solution.  If it does, and someone knows where to find it, could you point me to the correct page to look for it on?

Thanks for your time and thanks for all the work that goes into CGMiner

[kano]

...
The problem now, though, is that the LCD display gives a formatting error - I'm assuming because of the changes in the way the software displays its mining information the 3.x.x versions of CGminer and the newer 4.x.x versions.  I'll admit I haven't yet tried using other 3.x.x versions (perhaps one of the 3.9.x's?) to see if they have Antminer U1 support and the original format for displaying mining information - I was hoping not to have to go through each of them looking and it seems that the README on ckolivas is only for the most up to date version (I couldn't find older versions of the README, if they exist, could someone point me to them?) - is there such a version of CGminer?

I do apologize if this has been covered already in this thread, but with over 700 pages of posts I felt that posting something fresh might provide a quicker solution.  If it does, and someone knows where to find it, could you point me to the correct page to look for it on?

Thanks for your time and thanks for all the work that goes into CGMiner

The data source for external programs is usually the cgminer API.
API backward compatibility is pretty much as good as it can get - so that shouldn't be a problem unless software is making bad assumptions about the API replies.
The data returned from the API is Name/Key based and there should be no issues there.

If the program getting the data source from cgminer is using screen scraping or text log processing, then yep that will fail each time we change the screen layout or the text log output format.

Since you are referring to something that is not part of cgminer, you'll need to provide more info

[UselessCargo]

If the program getting the data source from cgminer is using screen scraping or text log processing, then yep that will fail each time we change the screen layout or the text log output format.

Since you are referring to something that is not part of cgminer, you'll need to provide more info

Can you be more specific about what info would be helpful and where I might find it?  The program which runs the LCD is in python.  I really don't know python at all, and I could go through some of the files in the package from that Adafruit Tutorial I linked in order to find that information, but I'm not really sure what information would be informative.  And as long as you're asking for more information: the screen has some push buttons that cycle through different displays - only one screen reads a format error, the others read "connecting to cgminer...", and the last display works correctly.  That last one which works, though, is just recent market prices and so doesn't rely on cgminer for data.

How about one of the older versions before the screen layout change?  Do any support Antminer U1 configuration?  I know I had to --enable-icarus and --enable-ants1 in order for 4.2.1 to recognize the U1, so I probably will try enabling all support for 3.8.4 (maybe one of the 3.9.x's) to see if I can get the U1's hash speed up - that would also be an acceptable solution.  With just --enable-ants1, 4.2.1 didn't notice they were there.  Any maybe this makes perfect sense to people here who have a greater understanding of hardware/software interaction and communication.  It has been an adventure getting this far off that tutorial and some old forum posts.

[-ck]

How about one of the older versions before the screen layout change?  Do any support Antminer U1 configuration?  I know I had to --enable-icarus and --enable-ants1 in order for 4.2.1 to recognize the U1, so I probably will try enabling all support for 3.8.4 (maybe one of the 3.9.x's) to see if I can get the U1's hash speed up - that would also be an acceptable solution.  With just --enable-ants1, 4.2.1 didn't notice they were there.  Any maybe this makes perfect sense to people here who have a greater understanding of hardware/software interaction and communication.  It has been an adventure getting this far off that tutorial and some old forum posts.

There's no such command as --enable-ants1 I have no idea where you got that. Ancient versions did not support the U1s so the icarus driver randomly ran them not much better than a block erupter. You can always check the extensively documented NEWS file to see when U1 support was added if you want to use an old version.

[UselessCargo]

There's no such command as --enable-ants1 I have no idea where you got that. Ancient versions did not support the U1s so the icarus driver randomly ran them not much better than a block erupter. You can always check the extensively documented NEWS file to see when U1 support was added if you want to use an old version.

https://www.dropbox.com/s/fvjes67wygg0ytd/CaptureCGMinerReadMe.PNG - from the ReadMe under "Building CGMiner For Yourself".  I included the URL so you could see it's kinda on the webpage with your name on it.

[-ck]

There's no such command as --enable-ants1 I have no idea where you got that. Ancient versions did not support the U1s so the icarus driver randomly ran them not much better than a block erupter. You can always check the extensively documented NEWS file to see when U1 support was added if you want to use an old version.

https://www.dropbox.com/s/fvjes67wygg0ytd/CaptureCGMinerReadMe.PNG - from the ReadMe under "Building CGMiner For Yourself".  I included the URL so you could see it's kinda on the webpage with your name on it.

Code:

--enable-ants1          Compile support for Antminer S1 Bitmain (default disabled)

Indeed even I forgot that sorry, since it was code added by Kano, but that says to build for Antminer S1 and you have U1.

[kano]

If the program getting the data source from cgminer is using screen scraping or text log processing, then yep that will fail each time we change the screen layout or the text log output format.

Since you are referring to something that is not part of cgminer, you'll need to provide more info

Can you be more specific about what info would be helpful and where I might find it?  The program which runs the LCD is in python.  I really don't know python at all, and I could go through some of the files in the package from that Adafruit Tutorial I linked in order to find that information, but I'm not really sure what information would be informative.  And as long as you're asking for more information: the screen has some push buttons that cycle through different displays - only one screen reads a format error, the others read "connecting to cgminer...", and the last display works correctly.  That last one which works, though, is just recent market prices and so doesn't rely on cgminer for data.

How about one of the older versions before the screen layout change?  Do any support Antminer U1 configuration?  I know I had to --enable-icarus and --enable-ants1 in order for 4.2.1 to recognize the U1, so I probably will try enabling all support for 3.8.4 (maybe one of the 3.9.x's) to see if I can get the U1's hash speed up - that would also be an acceptable solution.  With just --enable-ants1, 4.2.1 didn't notice they were there.  Any maybe this makes perfect sense to people here who have a greater understanding of hardware/software interaction and communication.  It has been an adventure getting this far off that tutorial and some old forum posts.

Firstly, yes as ckolivas said, --enable-ants1 has nothing to do with Ant U1s or U2s
It's for the AntMinerS1 that doesn't run on anything except the OpenWRT standalone device that Bitmain sells.
You'd never compile that into the code except on it's own when cross compiling for the AntS1.

Now, I'll go out on a limb here and say that what has happened is the people who wrote the Adafruit package did something REALLY dumb.
I'll say I'm 99.99% sure of that.
What has changed in the API is the order of fields.
I've never changed the field order before, however, as I said in my first reply, the fields are keyed by name.
My guess is that they are IGNORING the field names ... so you can expect to get the problems they have.

There has been for a long time an LCD screen app for the RPi written by cardcomm and I helped get it all working properly:
https://github.com/kanoi/cgminerLCDStats

Tell the Adafruit people to have a look at that from 7 or 8 months ago.
(Edit: I use it, and still use it ... and yes, no problems with it)

[UselessCargo]

You're entirely right - I had this feeling like I was saying something but seeing something else, but I wasn't quite sure what it was - but apparently that "--enable-ants1" does do something for the U1's in CGMiner as well.  Like I said in a post above, enabling the ants1 configuration with icarus allows the U1's to hash at or just under 1.6ghz each, which is better than the 500mhz block erupter speeds I was getting before with just the icarus configured.  Also, the section below has "anu-freq" which affects U1 hashing speeds, so I think I was probably mixing those two up as far as S1/U1 stuff goes.

Also, since both miners use the same chips, I'm guessing they both communicate the same way - so maybe that's part of why the ants1 configuration is fixing the hashing issue.

If the ants1 configuration has nothing to do with the U1's, then why would the U1's be working differently with that enabled than without it?