Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 112. (Read 5805527 times)

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

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.

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!


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

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.

: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

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

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

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.

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?

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.

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

Be strong kano......

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.

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

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.

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 

They're upset about this:

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

Edit: there's a later version out already:
https://bitcointalksearch.org/topic/m.5837272

Finally got an AntS1 binary out - it's 4.2.0 with a patch to make the Luci display work as well as the standard API so anyone wanting to use the API to their AntS1 can use the same code for their AntS1 as for any other cgminer device.

The patch (for anyone interested in knowing what I had to change) is here:
https://github.com/kanoi/cgminer/commit/28f27672d4deaef742c66a12522b745105b770f5

The binary and README are in my usual cgminer-binaries git here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

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

Of course this binary includes all cgminer changes up to 4.2.0 and the one extra commit after 4.2.0 was released:
https://github.com/ckolivas/cgminer/commit/c73e9e7a4f457e94d0f61e0cfc9e8f4531a99f4b

The specific AntS1 changes are of course the changes that have been advertised in cgminer since I merged in the full AntS1 support.
They are:
Enable temperature management code (it doesn't work in the Bitmain code)
Use stratum time rolling to reduce CPU - it still runs at 100% CPU like the Bitmain version does, though.

I at least set up mine but I was under the impression that I didn't need an btc address. Maybe that's why I didn't see anything but new block found messages. If the new one has is coded to give to you when we forget to set an address could we have something like a

"thanks for the gold... now get out of the way your blocking my view"

message, so we know we're mostly/accidentally giving our mining power to you. You should add a cgminer donate command like cgwatcher has if you want a cut of my miniscule pie.

On another note just looked back and noticed that a problem I was having with a u2 device being disabled was a known issue and hopefully being worked on  ,but did you get any demo units to play with to see what would keep the u2 device coming on with certain hubs(no solid green when not mining). I have an aitech usb3.0 hub and the one u2 device I put on it would not cycle[power] on[no green,solid red] but a rosewill 2.0 hub would. Wierd huh?

Also good time to test a blink on command function as the u2's do have bright enough green lights for me to tape over soon, but just enough to tell me when its not mining on a "happy" hub.

Uploaded a new windows debug build based on 4.2.0:
http://ck.kolivas.org/apps/cgminer/debug/