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

[PatMan]

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

Be strong kano......

[1501224665]

1501224665

[1501224665]

1501224665

[1501224665]

1501224665

[1501224665]

1501224665

[1501224665]

1501224665

[1501224665]

1501224665

[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!




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!




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

[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

[techman05]

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

Has anyone tried to bump these u2 miners up.  2.0GH is the start speed so I'd hope we'd get close to 2.5 or 2.6GH

Size being a secondary issue it took a long while for cgminer to see it . I have in total 8 of a combination of u1's and 2's but I only showed 7 till I restarted. I'm still having troubles where the u2 device's lights wont go on or the way I expect them. The one I thought I would need to return is working properly and the one I didn'ts lights don't come on when I shut down cgminer.

These u2's are picky buggers  but it may just be they are different enough to cause me migranes

[Dallas5]

Does the latest version of CGminer still support scrypt?

[os2sam]

Does the latest version of CGminer still support scrypt?

No

I've finally bitten the bullet and killed off GPU mining from the code and it will not be in the release I'm about to post. I have given ample warning that this was coming for some time on this forum thread and IRC about this and its time has come. It's also worth noting that even GPU mining has been used lately for botnets so cgminer once again is being flagged inappropriately as malware or a virus by various "authorities". I have left a 3.7 branch on git that is based on the last code that support GPU, OpenCL and scrypt code for those who wish to use it, but it is basically unchanged in terms of its mining code for GPUs compared with 3.7.2 which will be the last official release with GPU support. You are most welcome to fork, maintain, extend etc. the existing code provided you abide by the GPLv3 copyright restrictions that cgminer is released under. I am making a conscious decision and taking a stance to only support bitcoin by doing this and will consider all discussions regarding alternative cryptocurrencies as offtopic from here on. It is absolutely clear that we are in a stage where only ASICs matter in mining bitcoin, and cgminer is moving with the rapidly changing landscape that is bitcoin mining.

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

[os2sam]

Previous versions of CGMiner consumed 4 to 6MB RAM.  4.2 is now at 63MB, after 1 hour run time, and climbing steadily.  I had thought it was related to hotplug scanning the USB bus but after all AMU's were recognized I disabled Hotplug and it has continued to climb. 

Not a problem on my system at the moment, but it seems it could eventually cause a problem if it continues.
Thanks,
Sam