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

[-ck]

However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you,

No you're reading it wrong.

You should add a cgminer donate command like cgwatcher has if you want a cut of my miniscule pie.

Um, are these guys really upset because the executive summary has your bitcoin address for an example?  Or am I missing something?

They're upset about this:

Code:

Restart bitcoind, then start cgminer, pointing to the bitcoind and choose a
btc address with the following options, altering to suit their setup:

cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

If you do NOT specify a btc address, you WILL be mining solo for me instead.

[PatMan]

Greets Kano,

Great work on this - well done. I just installed it on one of my S1's for testing, cpu & memory usage are slightly less than it used to be which makes the web interface a little more responsive - thanks! I have noticed that the LSTime column on the Miner Status page is now maxed out at 1395366962 constantly - any ideas my man?

Really appreciate your work on this Kano - kudos 

[techman05]

No your missing something... like that all the instructions from other post I followed in the past didn't mention something like this and I missed out on coins regardless how I appropriate them.

If they have for example ckolivias's address hard coded I just want to have a way to remind myself that I screwed up and adjust my equipment properly

If I make a killing or someone accidentally tips me way to much or uses my reference codes I'll make sure it goes where it needs to go though I'd rather find a way for ckolivias  and company to get a cut of all the mining sites that charge fees and use cgminer as reference.

[kano]

Greets Kano,

Great work on this - well done. I just installed it on one of my S1's for testing, cpu & memory usage are slightly less than it used to be which makes the web interface a little more responsive - thanks! I have noticed that the LSTime column on the Miner Status page is now maxed out at 1395366962 constantly - any ideas my man?

Really appreciate your work on this Kano - kudos 

Hmm, yep I see that also on my new ant only though.
The old ant (and Con's ant) show up normal.
Must be another change in there they did to screw up the API somewhere between the early ants and the newest ones
I can track down the difference, since as I say in the README to keep the original executable - so looking at that should hopefully show what has changed between the different ants ... sigh ... why?!?!

[navigator]

Greets Kano,

Great work on this - well done. I just installed it on one of my S1's for testing, cpu & memory usage are slightly less than it used to be which makes the web interface a little more responsive - thanks! I have noticed that the LSTime column on the Miner Status page is now maxed out at 1395366962 constantly - any ideas my man?

Really appreciate your work on this Kano - kudos  

Hmm, yep I see that also on my new ant only though.
The old ant (and Con's ant) show up normal.
Must be another change in there they did to screw up the API somewhere between the early ants and the newest ones
I can track down the difference, since as I say in the README to keep the original executable - so looking at that should hopefully show what has changed between the different ants ... sigh ... why?!?!

My older ants display a full date and time for the LSTIME. One of my newer ants shows time since the last share for LSTIME.

[PatMan]

Right, I only have the newer ants.....

Be strong kano......

[Askit2]

However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you,

No you're reading it wrong.

You should add a cgminer donate command like cgwatcher has if you want a cut of my miniscule pie.

Um, are these guys really upset because the executive summary has your bitcoin address for an example?  Or am I missing something?

They're upset about this:

Code:

Restart bitcoind, then start cgminer, pointing to the bitcoind and choose a
btc address with the following options, altering to suit their setup:

cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

If you do NOT specify a btc address, you WILL be mining solo for me instead.

Isn't that a bit of an anti-feature?

The feature is GBT directly from the bitcoin daemon. The problem is that GBT REQUIRES an address. Not an anti-feature but not the way "get work" worked. Now Con can't possibly setup a binary with everyone's individual bitcoin address. People do see that I hope. Since it won't mine without an address one is put into the code so that if there is a problem solo mining would work. There is bold mention of it in the release notes. It is stated in the readme. It's not really a huge thing but people seem overly bothered by needing to read when upgrading. Things change. For having to put in a bitcoin address on the new version you get a much better work supply from your daemon.

[xyzzy099]

The feature is GBT directly from the bitcoin daemon. The problem is that GBT REQUIRES an address. Not an anti-feature but not the way "get work" worked. Now Con can't possibly setup a binary with everyone's individual bitcoin address. People do see that I hope. Since it won't mine without an address one is put into the code so that if there is a problem solo mining would work. There is bold mention of it in the release notes. It is stated in the readme. It's not really a huge thing but people seem overly bothered by needing to read when upgrading. Things change. For having to put in a bitcoin address on the new version you get a much better work supply from your daemon.

If you forget to fill in your pool credentials, should it then just default to mining using Con's credentials?

If you leave out a parameter necessary for mining on a given pool, it will just not mine on that pool, and will provide a message explaining the situation.

Solo mining requires a payout address, so if that parameter is not provided, then clearly, solo mining should not occur on anyone's address, and the user should be informed about the situation.

Am I missing something here?

[Askit2]

The feature is GBT directly from the bitcoin daemon. The problem is that GBT REQUIRES an address. Not an anti-feature but not the way "get work" worked. Now Con can't possibly setup a binary with everyone's individual bitcoin address. People do see that I hope. Since it won't mine without an address one is put into the code so that if there is a problem solo mining would work. There is bold mention of it in the release notes. It is stated in the readme. It's not really a huge thing but people seem overly bothered by needing to read when upgrading. Things change. For having to put in a bitcoin address on the new version you get a much better work supply from your daemon.

If you forget to fill in your pool credentials, should it then just default to mining using Con's credentials?

If you leave out a parameter necessary for mining on a given pool, it will just not mine on that pool, and will provide a message explaining the situation.

Solo mining requires a payout address, so if that parameter is not provided, then clearly, solo mining should not occur on anyone's address, and the user should be informed about the situation.

Am I missing something here?

I would like to think so. There could be a failure caused by not having an address. I'm not sure because I didn't have anything to do with GBT about how it handles no address. It's possible it just pays out to null. I am not sure.

The problem I usually see on here is people not reading the manual. Then they ask why it won't work or worse state flat out it doesn't work. Somewhat often providing no information on what doesn't work. Now this solution fixes one point. Solo mining would work. Now I am not a master of GBT and can find no info on how it's handled without a valid address to payout to and generate work from. Maybe everything looks fine I don't know. What I do know is that a solution that is clearly documented was put into place. Likely for a good reason. Maybe there is a crash associated with no address. The thing is that to your bitcoin daemon you would connect perfectly. You either make illegitimate work or have something else go wrong with nothing specified. I don't imagine the same people who can't be bothered to read and find out that there is a hard coded address would notice their work not paying out anything to them either. Worse if they did notice there is no possible recourse. You can't ask someone for a block you mined if it didn't go to a wallet.

How many people come on here complaining that cgminer just closes when they try to run it? Quite a few. They don't run from the command line so they don't see exit info. Some people ignore or can't read fast enough to actually notice what flashes on the screen when cgminer starts running. Could they dump it to a log and find out sure. I am not saying people should be punished for not reading directly. What I am saying is that sometimes things change and reading the release notes is a great way to find out. Con didn't hide what the default behavior is. He flat out said what it does. He told people in bold how to fix it. This is on top of it being listed in the readme.

[BoogieMan82]

I wish that these values were true on my Antminer U2's with the new rev of CGMiner!

http://www.getfreebitcoins.us/wp-content/uploads/2014/03/Bitminer-U21.jpg


My command line: --icarus-options 115200:2:2 --load-balance --anu-freq 250 --icarus-timing long

It appears that the new build of CG Miner is displaying double the value for my particular command line.  My hashrate on Slush's pool is still the same (I updated to 4.2 an hour ago).

It's not a critical error, just one that got my hopes up!

--BoogieMan

[Krak]

I wish that these values were true on my Antminer U2's with the new rev of CGMiner!

http://www.getfreebitcoins.us/wp-content/uploads/2014/03/Bitminer-U21.jpg


My command line: --icarus-options 115200:2:2 --load-balance --anu-freq 250 --icarus-timing long

It appears that the new build of CG Miner is displaying double the value for my particular command line.  My hashrate on Slush's pool is still the same (I updated to 4.2 an hour ago).

It's not a critical error, just one that got my hopes up!

--BoogieMan

Get rid of the --icarus-options and --icarus-timing flags as they are no longer necessary with Antminers.

[kano]

I wish that these values were true on my Antminer U2's with the new rev of CGMiner!

http://www.getfreebitcoins.us/wp-content/uploads/2014/03/Bitminer-U21.jpg


My command line: --icarus-options 115200:2:2 --load-balance --anu-freq 250 --icarus-timing long

It appears that the new build of CG Miner is displaying double the value for my particular command line.  My hashrate on Slush's pool is still the same (I updated to 4.2 an hour ago).

It's not a critical error, just one that got my hopes up!

--BoogieMan

:2:2 effectively means to double the hash rate saying it has 2 FPGA doing half the nonce range each ... which isn't the case.

--icarus-options are not for the U1/U2 ... but it also allows for anyone to make custom devices and adjust the chip information so the option is gonna stay

There's no problem with using --icarus-timing - I fixed that to work correctly with the U1/U2 recently, but of course you can put numbers in there that will mess up the performance as well as the reporting if you want

[xyzzy099]

The feature is GBT directly from the bitcoin daemon. The problem is that GBT REQUIRES an address. Not an anti-feature but not the way "get work" worked. Now Con can't possibly setup a binary with everyone's individual bitcoin address. People do see that I hope. Since it won't mine without an address one is put into the code so that if there is a problem solo mining would work. There is bold mention of it in the release notes. It is stated in the readme. It's not really a huge thing but people seem overly bothered by needing to read when upgrading. Things change. For having to put in a bitcoin address on the new version you get a much better work supply from your daemon.

If you forget to fill in your pool credentials, should it then just default to mining using Con's credentials?

If you leave out a parameter necessary for mining on a given pool, it will just not mine on that pool, and will provide a message explaining the situation.

Solo mining requires a payout address, so if that parameter is not provided, then clearly, solo mining should not occur on anyone's address, and the user should be informed about the situation.

Am I missing something here?

I would like to think so. There could be a failure caused by not having an address. I'm not sure because I didn't have anything to do with GBT about how it handles no address. It's possible it just pays out to null. I am not sure.

The problem I usually see on here is people not reading the manual. Then they ask why it won't work or worse state flat out it doesn't work. Somewhat often providing no information on what doesn't work. Now this solution fixes one point. Solo mining would work. Now I am not a master of GBT and can find no info on how it's handled without a valid address to payout to and generate work from. Maybe everything looks fine I don't know. What I do know is that a solution that is clearly documented was put into place. Likely for a good reason. Maybe there is a crash associated with no address. The thing is that to your bitcoin daemon you would connect perfectly. You either make illegitimate work or have something else go wrong with nothing specified. I don't imagine the same people who can't be bothered to read and find out that there is a hard coded address would notice their work not paying out anything to them either. Worse if they did notice there is no possible recourse. You can't ask someone for a block you mined if it didn't go to a wallet.

How many people come on here complaining that cgminer just closes when they try to run it? Quite a few. They don't run from the command line so they don't see exit info. Some people ignore or can't read fast enough to actually notice what flashes on the screen when cgminer starts running. Could they dump it to a log and find out sure. I am not saying people should be punished for not reading directly. What I am saying is that sometimes things change and reading the release notes is a great way to find out. Con didn't hide what the default behavior is. He flat out said what it does. He told people in bold how to fix it. This is on top of it being listed in the readme.

Again:

The historic behavior of cgminer when necessary parameters are not specified is to NOT MINE At ALL - and rightly so, because if you leave out your user name or password or whatever required parameter it cannot know how to go about mining so that you get paid.

Similarly, for solo mining with GBT, the address is a required parameter.  If it's missing, no mining should occur, because cgminer cannot know how to go about mining so that you get paid.

BFGMiner has supported GBT solo mining for a long time, and it simply won't use GBT unless you have specified a mining address.  That seems like correct behavior to me.

I certainly don't want to argue that people shouldn't read the documentation - but it seems very wrong that a miner with a known working configuration can start to silently lose mined coins just because they upgraded and forgot to read the release notes this time.

[BoogieMan82]

I wish that these values were true on my Antminer U2's with the new rev of CGMiner!

http://www.getfreebitcoins.us/wp-content/uploads/2014/03/Bitminer-U21.jpg


My command line: --icarus-options 115200:2:2 --load-balance --anu-freq 250 --icarus-timing long

It appears that the new build of CG Miner is displaying double the value for my particular command line.  My hashrate on Slush's pool is still the same (I updated to 4.2 an hour ago).

It's not a critical error, just one that got my hopes up!

--BoogieMan

Get rid of the --icarus-options and --icarus-timing flags as they are no longer necessary with Antminers.

Thanks for the info!  I think the --Icarus-timing now works properly (per the changelog: - Icarus - allow timing mode to work with ANU and not slow it down), but it may not change the hashrate very much, I guess I need to play!

I wish that these values were true on my Antminer U2's with the new rev of CGMiner!

http://www.getfreebitcoins.us/wp-content/uploads/2014/03/Bitminer-U21.jpg


My command line: --icarus-options 115200:2:2 --load-balance --anu-freq 250 --icarus-timing long

It appears that the new build of CG Miner is displaying double the value for my particular command line.  My hashrate on Slush's pool is still the same (I updated to 4.2 an hour ago).

It's not a critical error, just one that got my hopes up!

--BoogieMan

:2:2 effectively means to double the hash rate saying it has 2 FPGA doing half the nonce range each ... which isn't the case.

--icarus-options are not for the U1/U2 ... but it also allows for anyone to make custom devices and adjust the chip information so the option is gonna stay

There's no problem with using --icarus-timing - I fixed that to work correctly with the U1/U2 recently, but of course you can put numbers in there that will mess up the performance as well as the reporting if you want

Thanks for the information, this is what it looks like now (I still wish the values were doubled though)!

http://www.getfreebitcoins.us/wp-content/uploads/2014/03/Bitminer-U2b.jpg

[Terra Hash]

First post on Bitcoin Forum and I hope it's not a stupid one, but I've go a question about CGMiner and DNS.  Obviously CGMiner makes use of DNS to establish connections to pools when it starts up.  Once the connection is made and the mining process starts, does CGMiner need access to a DNS server on an ongoing basis??  The reason I ask is that we are making some changes in our server room that will require our DNS server to be brought down for an hour or so, and I was curious if this would disrupt my miners.

[Krak]

First post on Bitcoin Forum and I hope it's not a stupid one, but I've go a question about CGMiner and DNS.  Obviously CGMiner makes use of DNS to establish connections to pools when it starts up.  Once the connection is made and the mining process starts, does CGMiner need access to a DNS server on an ongoing basis??  The reason I ask is that we are making some changes in our server room that will require our DNS server to be brought down for an hour or so, and I was curious if this would disrupt my miners.

To be safe, you could just look up your pool's IP address and use that while the DNS server is down.

[-ck]

It's no big deal. I'll change the default to not work without an address for the next version.

[kano]

It's no big deal. I'll change the default to not work without an address for the next version.

That sux.

I wonder why you would do this?

If anyone goes out and pays for big mining hardware - like an Ant, or Avalon (and I don't know what else)
the device will be configured to mine for Ant or Avalon when it arrives.
You switch it on and it mines for them.
This was VERY prevalent in the past with Avalon, the number of people mining for them when they got devices.

But here when you give out free software, you have people complaining about how it might mine for you if they haven't configured it right.

I don't have any respect at all for those above complaining about it.

[kano]

Edit: there's a later 4.2.0 update here: https://bitcointalk.org/index.php?topic=28402.msg5856097#msg5856097

Well ... that was unexpected.

Here's another new AntS1 binary.

The comment I made about the last version having Temperature Management in it was wrong.
Oops.

I did enable the flag in the code (which doesn't work in Bitmain's version) but I didn't realise there was no code using the flag until someone pointed it out to me later.
In fact 7 of the 8 options passed to the Bitmain code are ignored:
bitmain_temp, bitmain_overheat, bitmain_fan_min, bitmain_fan_max, bitmain_freq_min, bitmain_freq_max and bitmain_auto

Anyway, this new binary DOES have Temperature Management code in it that I've written and tested for 24 hours now on all 3 of my ants.
It takes notice of bitmain_temp and bitmain_overheat

It uses the same patch as before for the luci display.
My source for this version is here:
https://github.com/kanoi/cgminer/tree/ants1-4.2.0-c85d846a

The binary and README are in my cgminer-binaries git here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1  <-- Follow this link to get the new binary

Read the README on the screen there for how to replace the /usr/bin/cgminer binary in your AntS1 with the new one.

This binary includes all cgminer changes up to 4.2.0 and forward after that up to:
https://github.com/ckolivas/cgminer/commit/4e05c30bfa12d658253ea670995156e069fdb5f0

The specific AntS1 changes this time really does include:
Perform temperature management (it doesn't work in the Bitmain code)

I have had one person report that they cannot run the binary.
I've no idea why - since others have had no trouble running yesterdays binary.
If you cannot run this binary please let me know.
I'm chasing up someone with literally hundreds of ants and hoping they'll use it and get expected results.

[n3xus]

Well ... that was unexpected.

Here's another new AntS1 binary.

The comment I made about the last version having Temperature Management in it was wrong.
Oops.

I did enable the flag in the code (which doesn't work in Bitmain's version) but I didn't realise there was no code using the flag until someone pointed it out to me later.
In fact 7 of the 8 options passed to the Bitmain code are ignored:
bitmain_temp, bitmain_overheat, bitmain_fan_min, bitmain_fan_max, bitmain_freq_min, bitmain_freq_max and bitmain_auto

Anyway, this new binary DOES have Temperature Management code in it that I've written and tested for 24 hours now on all 3 of my ants.
It takes notice of bitmain_temp and bitmain_overheat

It uses the same patch as before for the luci display.
My source for this version is here:
https://github.com/kanoi/cgminer/tree/ants1-4.2.0-c85d846a

The binary and README are in my cgminer-binaries git here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1  <-- Follow this link to get the new binary

Read the README on the screen there for how to replace the /usr/bin/cgminer binary in your AntS1 with the new one.

This binary includes all cgminer changes up to 4.2.0 and forward after that up to:
https://github.com/ckolivas/cgminer/commit/4e05c30bfa12d658253ea670995156e069fdb5f0

The specific AntS1 changes this time really does include:
Perform temperature management (it doesn't work in the Bitmain code)

I have had one person report that they cannot run the binary.
I've no idea why - since others have had no trouble running yesterdays binary.
If you cannot run this binary please let me know.
I'm chasing up someone with literally hundreds of ants and hoping they'll use it and get expected results.

Nice work, I noticed when I updated my some of my Antminer S1 that a soft reset was needed.
I saw improvements on loading and response time in the web interface.
I also now noticed there is a bug in LSTime that was mentioned earlier, the time isn't displayed properly.

Thanks for the update