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

[knowndragon]

Okay I have 4.6 installed and configuring it. I want to have it ready to setup. I actually had it running but without the usb it doesn't hash. My questions are...

When I started it up I kept getting an error saying : No BTC address, unable to solo mine. I made edited the Bitcoin.conf and the cgminer.conf file. I added these commands.

 First the Bitcoin.conf I added this. btc=****************** put my wallet address where the stars are.

Then with the cgminer.conf I added this. "btc-address" : "***************************", again put my wallet address where the stars are.

When it starts up I get the following on the cgminer window.

Loaded configuration file cgminer.conf
No devices detected!
waiting for usb hotplug devices
probing for an alive pool.
Solo mining to valid address: *****************
block change for 127.0.0.1:8332 detection via getbkcount polling
network diff set to 39.6
API runnin in ip access mode on port 4028 <1424>


If I am not mistaking all that is left to do is get my miners in and do the zidag update and plug them in and run the cgminer. Does this look right.

Also I don't want to destroy any coins so is can anyone point me in the right direction to keep from losing any. This is for everyone's benefit. The probability of me finding a block with 25 is slim to none. But wouldn't want to lose them if I did.
 

[1638256730]

1638256730

[1638256730]

1638256730

[1638256730]

1638256730

[bbOOmm]

Maybe this problem has been mentioned before, if it has, please point me to the solution-- I have no idea what to call this problem.

----------------

CGMINER is running and its hashing right along, BUT, I have ~ONLY~ text when something is accepted, there is a new block, etc and the 5s, avg, A, R, HW and WU line.

CGMINER is NOT showing the normal top of the window output... the miners, their individual outputs, pool info etc... the info that NORMALLY stay at the top of the terminal window while the accepted, new block and other info scroll below it.

I also do not have access to any of the menus, like (s)etup (d)isplay etc .. I press S or whatever and it just types an S in the terminal, no menu.

I've installed and re-installed CGMINER a few times, I've used the latest version of CGMINER even with this problem to mine SHA-256 as well as now, using 3.7.2 - GC3355 for scrypt mining using Gridseeds, still the same problem....

What am I doing wrong in installation? How to fix it so I can see what is going on with each miner etc?

I'm using Ubuntu 12.04LTS 64-bit desktop
on a Dell PE850 server with 4gb ram
CGMINER v.3.7.3-GC3355

Thanks

[kano]

your computer doesn't have curses devel - configure said that at the end when you ran it.

[bbOOmm]

anything special I need to do to compile cgminer to work with btcgarden asics?

Spiceminer15 --- If you are referring to the 8ghs blades... those are GETWORK only, they don't do STRATUM.

However ....

you can use Slush's Stratum mining proxy, it works great for the old GETWORK stuff.  

https://github.com/slush0/stratum-mining-proxy

As for mining software, none needed. Its has it own internal firmware that you configure via its IP address and I think you also have to include the port ... like 10.10.10.2:10000 (10000 was the default port) .... There is an important catch though.

The blades need to have access to the internet, NOT JUST YOUR NETWORK, it needs the internet for some unknown reason for you to enter the blade config page. Sooo, if your blades have a different IP address range than your network with internet, Say your network with internet is on 192.168.1.x, and the blades are set up for a 10.10.10.x network, you'll need to set up a separate router with 10.10.10.1 as its address, ( this is just for changing the IP address to what you want it to be) then connect the miner to the router, and then the router to your network with the internet access. THEN -- you can access the configure page and set the miner IP addresses for each of the miners -SEPARATELY- so you can access them from your normal internet accessible network.

DO NOT GET PUNCHY ... don't rush the settings. just because it says configuring on the screen, does not mean it has been already flashed... they are abit slow. I bricked 2 of the blades by being a little quick to close the page or reset the power etc.

[bbOOmm]

your computer doesn't have curses devel - configure said that at the end when you ran it.

Kano --- RIGHT ON THE MONEY !!!

I must have missed it when copy n pasting the commands.

NOW... its working 

Thank you

[asadnow2k]

will this work with ATI 7970 single card?

[os2sam]

will this work with ATI 7970 single card?

Q: What happened to CPU and GPU mining?
A: Their efficiency makes them irrelevant in the bitcoin mining world today
and the author has no interest in supporting alternative coins that are better
mined by these devices.

[Ntrain2k]

will this work with ATI 7970 single card?

Q: What happened to CPU and GPU mining?
A: Their efficiency makes them irrelevant in the bitcoin mining world today
and the author has no interest in supporting alternative coins that are better
mined by these devices.

Try BFGminer or SGminer for GPU mining.

[AngusCanine]

What is the newest software that I can download and flash to my S1

[Taugeran]

@conman, @Kano: question/input request from you regarding a section of code.


In regards to:

Code:

/* Base the fail time on no valid nonces for 25 full nonce ranges at
* the current expected hashrate. */
fail_time = 25.0 * (double)hashfast->drv->max_diff * 0xffffffffull /
(double)(info->base_clock * 1000000) / hfa_basejobs(info);
if (unlikely(share_work_tdiff(hashfast) > fail_time)) {
applog(LOG_WARNING, "%s %s: No valid hashes for over %.0f seconds, shutting down thread",
      hashfast->drv->name, hashfast->unique_id, fail_time);
hfa_running_shutdown(hashfast, info);
return -1;
}

does tripping this indicate the device is spewing garbage(that cgminer is filtering), no spewing anything at all, or something else?

I ask as I am troubleshooting a couple of Habaneros, whom are ridiculously cool at the chip level(850MHz is 86-87C), and yet when set this high will continually trip this and clock down until ~750-767MHz.


EDIT: just made an obervation that prior to the message appearing in CGMiner, the fan on my RM1000 PSU, which is powering one of them, stops spinning indicating that the load completely drops. will investigate if additional VRM cooling is needed. also need to break down and grab a good FLIR cam (or at least an IR thermometer).

[MrTeal]

@conman, @Kano: question/input request from you regarding a section of code.


In regards to:

Code:

/* Base the fail time on no valid nonces for 25 full nonce ranges at
* the current expected hashrate. */
fail_time = 25.0 * (double)hashfast->drv->max_diff * 0xffffffffull /
(double)(info->base_clock * 1000000) / hfa_basejobs(info);
if (unlikely(share_work_tdiff(hashfast) > fail_time)) {
applog(LOG_WARNING, "%s %s: No valid hashes for over %.0f seconds, shutting down thread",
      hashfast->drv->name, hashfast->unique_id, fail_time);
hfa_running_shutdown(hashfast, info);
return -1;
}

does tripping this indicate the device is spewing garbage(that cgminer is filtering), no spewing anything at all, or something else?

I ask as I am troubleshooting a couple of Habaneros, whom are ridiculously cool at the chip level(850MHz is 86-87C), and yet when set this high will continually trip this and clock down until ~750-767MHz.


EDIT: just made an obervation that prior to the message appearing in CGMiner, the fan on my RM1000 PSU, which is powering one of them, stops spinning indicating that the load completely drops. will investigate if additional VRM cooling is needed. also need to break down and grab a good FLIR cam (or at least an IR thermometer).

cgminer spits out the VRM temperature for each die if you enable debugging or use the API, so you can see what they are. The VRM will shut down if it reaches 90C.

[Taugeran]

@conman, @Kano: question/input request from you regarding a section of code.


In regards to:

Code:

/* Base the fail time on no valid nonces for 25 full nonce ranges at
* the current expected hashrate. */
fail_time = 25.0 * (double)hashfast->drv->max_diff * 0xffffffffull /
(double)(info->base_clock * 1000000) / hfa_basejobs(info);
if (unlikely(share_work_tdiff(hashfast) > fail_time)) {
applog(LOG_WARNING, "%s %s: No valid hashes for over %.0f seconds, shutting down thread",
      hashfast->drv->name, hashfast->unique_id, fail_time);
hfa_running_shutdown(hashfast, info);
return -1;
}

does tripping this indicate the device is spewing garbage(that cgminer is filtering), no spewing anything at all, or something else?

I ask as I am troubleshooting a couple of Habaneros, whom are ridiculously cool at the chip level(850MHz is 86-87C), and yet when set this high will continually trip this and clock down until ~750-767MHz.


EDIT: just made an obervation that prior to the message appearing in CGMiner, the fan on my RM1000 PSU, which is powering one of them, stops spinning indicating that the load completely drops. will investigate if additional VRM cooling is needed. also need to break down and grab a good FLIR cam (or at least an IR thermometer).

cgminer spits out the VRM temperature for each die if you enable debugging or use the API, so you can see what they are. The VRM will shut down if it reaches 90C.

can you show an example line so i know what to be looking for? API and debuglog

[-ck]

@conman, @Kano: question/input request from you regarding a section of code.


In regards to:

Code:

/* Base the fail time on no valid nonces for 25 full nonce ranges at
* the current expected hashrate. */
fail_time = 25.0 * (double)hashfast->drv->max_diff * 0xffffffffull /
(double)(info->base_clock * 1000000) / hfa_basejobs(info);
if (unlikely(share_work_tdiff(hashfast) > fail_time)) {
applog(LOG_WARNING, "%s %s: No valid hashes for over %.0f seconds, shutting down thread",
      hashfast->drv->name, hashfast->unique_id, fail_time);
hfa_running_shutdown(hashfast, info);
return -1;
}

does tripping this indicate the device is spewing garbage(that cgminer is filtering), no spewing anything at all, or something else?

I ask as I am troubleshooting a couple of Habaneros, whom are ridiculously cool at the chip level(850MHz is 86-87C), and yet when set this high will continually trip this and clock down until ~750-767MHz.


EDIT: just made an obervation that prior to the message appearing in CGMiner, the fan on my RM1000 PSU, which is powering one of them, stops spinning indicating that the load completely drops. will investigate if additional VRM cooling is needed. also need to break down and grab a good FLIR cam (or at least an IR thermometer).

Tripping it indicates it hasn't generated a single correct share. It may be producing nothing or just garbage, the effect is the same. Sounds to me like it's picking up the failure correctly (of course it can't tell you why it failed, just that it did).

[Taugeran]

@conman, @Kano: question/input request from you regarding a section of code.


In regards to:

Code:

/* Base the fail time on no valid nonces for 25 full nonce ranges at
* the current expected hashrate. */
fail_time = 25.0 * (double)hashfast->drv->max_diff * 0xffffffffull /
(double)(info->base_clock * 1000000) / hfa_basejobs(info);
if (unlikely(share_work_tdiff(hashfast) > fail_time)) {
applog(LOG_WARNING, "%s %s: No valid hashes for over %.0f seconds, shutting down thread",
      hashfast->drv->name, hashfast->unique_id, fail_time);
hfa_running_shutdown(hashfast, info);
return -1;
}

does tripping this indicate the device is spewing garbage(that cgminer is filtering), no spewing anything at all, or something else?

I ask as I am troubleshooting a couple of Habaneros, whom are ridiculously cool at the chip level(850MHz is 86-87C), and yet when set this high will continually trip this and clock down until ~750-767MHz.


EDIT: just made an obervation that prior to the message appearing in CGMiner, the fan on my RM1000 PSU, which is powering one of them, stops spinning indicating that the load completely drops. will investigate if additional VRM cooling is needed. also need to break down and grab a good FLIR cam (or at least an IR thermometer).

cgminer spits out the VRM temperature for each die if you enable debugging or use the API, so you can see what they are. The VRM will shut down if it reaches 90C.

can you show an example line so i know what to be looking for? API and debuglog

yup ended up being something VRM related (though not sure what exactly) cuz with a repositioning into my windowsill with open windows and an outdoor ambient of 1C both my spicy peppers are purring at 950 on all cores.

[MrTeal]

@conman, @Kano: question/input request from you regarding a section of code.


In regards to:

Code:

/* Base the fail time on no valid nonces for 25 full nonce ranges at
* the current expected hashrate. */
fail_time = 25.0 * (double)hashfast->drv->max_diff * 0xffffffffull /
(double)(info->base_clock * 1000000) / hfa_basejobs(info);
if (unlikely(share_work_tdiff(hashfast) > fail_time)) {
applog(LOG_WARNING, "%s %s: No valid hashes for over %.0f seconds, shutting down thread",
      hashfast->drv->name, hashfast->unique_id, fail_time);
hfa_running_shutdown(hashfast, info);
return -1;
}

does tripping this indicate the device is spewing garbage(that cgminer is filtering), no spewing anything at all, or something else?

I ask as I am troubleshooting a couple of Habaneros, whom are ridiculously cool at the chip level(850MHz is 86-87C), and yet when set this high will continually trip this and clock down until ~750-767MHz.


EDIT: just made an obervation that prior to the message appearing in CGMiner, the fan on my RM1000 PSU, which is powering one of them, stops spinning indicating that the load completely drops. will investigate if additional VRM cooling is needed. also need to break down and grab a good FLIR cam (or at least an IR thermometer).

cgminer spits out the VRM temperature for each die if you enable debugging or use the API, so you can see what they are. The VRM will shut down if it reaches 90C.

can you show an example line so i know what to be looking for? API and debuglog

yup ended up being something VRM related (though not sure what exactly) cuz with a repositioning into my windowsill with open windows and an outdoor ambient of 1C both my spicy peppers are purring at 950 on all cores.

In the OP_DIE_STATUS it's the Board Temperature. You might have to update your firmware to support it.

It's a little flaky at extreme temperatures though. For some reason the original HashFast devices supplied an ADC reading for temperature and relied on cgminer to linearize it, so we take the actual temperature and perform the reverse function on it prior to sending it out, and then it gets converted back to a temp. This limits the range of temperatures supported though.

[Taugeran]

In the OP_DIE_STATUS it's the Board Temperature. You might have to update your firmware to support it.

It's a little flaky at extreme temperatures though. For some reason the original HashFast devices supplied an ADC reading for temperature and relied on cgminer to linearize it, so we take the actual temperature and perform the reverse function on it prior to sending it out, and then it gets converted back to a temp. This limits the range of temperatures supported though.

Gotcha. Will look into it this evening

[-ck]

What is the newest software that I can download and flash to my S1

The S1 firmwares generated by the cgminer team are virtually unmaintained due to the hardware's end-of-life status. The last available one was here:
https://github.com/kanoi/cgminer-binaries/blob/master/AntS1/cgminer-ants1-4.3.2a-85fcf0c

[salfter]

New release: Version 4.7.1, 4th November 2014

- Changed the configure build system to make it impossible to build more than one device in if the chosen driver was meant to be used standalone, along with more explicit tagging of standalone drivers in the configure help. This should make it easier to choose a more suitable configuration for distribution packaging.

Is there an option to override this new behavior?  I have had a couple of BFL Jalapeños running off the Raspberry Pi in my Bitfury rig for at least a year now. In recent months, I've been using the Black Arrow Bitfury driver in cgminer; its auto-tune support has been pretty nice, and it works like a champ with BFSB hardware.  Now I'll have to build cgminer twice (once with --enable-bab and again with --enable-bflsc) and run two instances of cgminer, where before a single instance would suffice.

[knowndragon]

  Hey guys I have a question? what does mining on an orphaned block mean?

 [2014-11-20 17:44:30] Block height change to 272530 detected on pool 0
 [2014-11-20 17:44:30] Network diff set to 130K
 [2014-11-20 17:49:27] Block height change to 272531 detected on pool 0
 [2014-11-20 17:49:27] Network diff set to 131K
 [2014-11-20 17:50:19] Block height change to 272532 detected on pool 0
 [2014-11-20 17:50:19] Network diff set to 133K
 [2014-11-20 17:50:50] Block height change to 272533 detected on pool 0
 [2014-11-20 17:50:50] Network diff set to 135K
 [2014-11-20 17:51:09] Block height change to 272534 detected on pool 0
 [2014-11-20 17:51:09] Network diff set to 130K
 [2014-11-20 17:51:59] Mining on orphan branch detected, switching!
 [2014-11-20 17:51:59] Network diff set to 138K

Also cgwatcher isn't showing any getworks and efficiency is at 0.00% now is it mining or is it just running.

[-ck]

Hey guys I have a question? what does mining on an orphaned block mean?

 [2014-11-20 17:44:30] Block height change to 272530 detected on pool 0
 [2014-11-20 17:44:30] Network diff set to 130K
 [2014-11-20 17:49:27] Block height change to 272531 detected on pool 0
 [2014-11-20 17:49:27] Network diff set to 131K
 [2014-11-20 17:50:19] Block height change to 272532 detected on pool 0
 [2014-11-20 17:50:19] Network diff set to 133K
 [2014-11-20 17:50:50] Block height change to 272533 detected on pool 0
 [2014-11-20 17:50:50] Network diff set to 135K
 [2014-11-20 17:51:09] Block height change to 272534 detected on pool 0
 [2014-11-20 17:51:09] Network diff set to 130K
 [2014-11-20 17:51:59] Mining on orphan branch detected, switching!
 [2014-11-20 17:51:59] Network diff set to 138K

Also cgwatcher isn't showing any getworks and efficiency is at 0.00% now is it mining or is it just running.

Firstly, you're mining altcoins which I wouldn't normally provide support for, but your questions are generic enough to deserve their own answer.

Cgminer in solo mining mode goes to great lengths to make sure you're mining on the most current block that your bitcoind knows about, and you have witnessed one of those moments in action where someone near your *coind found a block and informed you that it was the latest block, only to later on have their block orphaned and your bitcoind decided to switch to the other branch as the one true branch. At that time cgminer noticed the block hash changed but the block height did not and informed you it noticed the change. i.e. everything's working fine.

Getworks and efficiency were measures removed from cgminer displays a long time as being irrelevant to modern mining and any wrapper you have such as cgwatcher should also be doing that.