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

[HellDiverUK]

Had the same problem, even with fresh install of Windows.  Fresh install, installed 12.8 drivers, crash.  Another fresh install, 13.4 drivers, crash.  Another fresh install, 12.8 drivers, SDK, crash.  

Seems GPU mining is ignored now, developer is like a bitch in heat over USB mining bollocks.

Gave up with not getting any answers on here, tried latest BFGMiner with 13.4 and it's working no problems.    

Thanks.

Plenty of people apart from myself have pointed out the issue, and you can see in the thread it's totally ignored.  Then someone asks about some jippy USB thing and there's an instant response.

How about actually looking at the issue with GPU mining?  The issue where cgminer just crashes instantly on run.  Or crashes once it's compiled the .bin files.  Or the issue where it just gives up mining and sits there farting about at 20kH/s for no reason.

I've asked plenty of times.  Tell us exactly what we need to install.  What SDK version?  What Catalyst version?  Any other dependencies?  What is cgminer expecting on Windows?

As I said, I've got 3 identical in every way machines.  I install Windows off the same USB stick, install the same updates off my WSUS server, install the same drivers off a network share, extract the same .zip of cgminer, copy in the same .config file, and 1 out of the 3 machines will actually mine.  Then it's another crapshoot if I decide to change hardware.  A machine running perfectly will suddenly stop working if I add another card, and even stripping off cgminer in total and reinstalling it will leave the machine unable to mine.  Then it's a 50/50 chance it'll mine after a reinstall.

There's too much of a crapshoot in getting cgminer working now.  Old 2.11.x just worked.  Now 3.x is impossible.

[HellDiverUK]

P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0

I'll try that. 

[HellDiverUK]

P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0

I'll try that. 

Heh, what do you know?  That worked.  hotplug was set to '5' in the .config file (not set by me). 

Perhaps that should be set to 0 by default in future versions?

Thanks for that.  Seems my rant got through.    Sorry I had to do it. 

[freshzive]

I have been trying to run the same setup but with 4 block erupters and i keep getting issues. The block erupters keep being announced as SICK because they wont start, and if i happen to get all four to start somehow, they are running at a fraction of the hashrate they should be.

This happens to me using 3.2.1 on just a normal Ubuntu box. The erupters all connect fine and start hashing, but then they go "SICK" because they haven't produced any work in 60s. A few seconds later, they reconnect and submit shares, this happens over and over, but overall the hash rate is much much lower for each erupter than it should be.

They work fine on 3.1.1 however.

[-ck]

I have been trying to run the same setup but with 4 block erupters and i keep getting issues. The block erupters keep being announced as SICK because they wont start, and if i happen to get all four to start somehow, they are running at a fraction of the hashrate they should be.

This happens to me using 3.2.1 on just a normal Ubuntu box. The erupters all connect fine and start hashing, but then they go "SICK" because they haven't produced any work in 60s. A few seconds later, they reconnect and submit shares, this happens over and over, but overall the hash rate is much much lower for each erupter than it should be.

They work fine on 3.1.1 however.

Maybe you can try disabling hotplug too? --hotplug 0

[freshzive]

Maybe you can try disabling hotplug too? --hotplug 0

Still getting these

 [2013-06-11 07:58:35] AMU3: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU3: Attempting to restart
 [2013-06-11 07:58:35] AMU4: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU4: Attempting to restart
 [2013-06-11 07:58:35] AMU6: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU6: Attempting to restart
 [2013-06-11 07:58:37] AMU2: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:37] AMU2: Attempting to restart
 [2013-06-11 07:58:39] AMU0: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:39] AMU0: Attempting to restart
 [2013-06-11 07:58:41] AMU1: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:41] AMU1: Attempting to restar

[-ck]

Maybe you can try disabling hotplug too? --hotplug 0

Still getting these

 [2013-06-11 07:58:35] AMU3: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU3: Attempting to restart
 [2013-06-11 07:58:35] AMU4: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU4: Attempting to restart
 [2013-06-11 07:58:35] AMU6: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU6: Attempting to restart
 [2013-06-11 07:58:37] AMU2: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:37] AMU2: Attempting to restart
 [2013-06-11 07:58:39] AMU0: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:39] AMU0: Attempting to restart
 [2013-06-11 07:58:41] AMU1: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:41] AMU1: Attempting to restar

Thanks for trying it at least. We have a call into libusb on that platform that never returns (which shouldn't happen). We're still investigating...

[TheSwede75]

I feel like this is pretty nooby, but I fell into a Bitforce SHA256 and want to try it out. What commands do I need to run CGminer with the FPGA (BFL)? It's on COM7 currently and I get 'you need to install USB driver for BFL 7' as error (easyminer finds it and diagnosis works 100%)

[os2sam]

I got my Block Erupter's today.  So I sat down with the ASIC Readme and braced myself for all of the trouble everyone else seemed to be having with them.

Well per the readme I installed WinUSB via the Zadig utility and then popped in an Erupter and kicked off CGMiner-nogpu and it just started mining.  I popped a second one of the fly and it populated the list and started mining that as well.

I'm mining with 4 of these plugged directly into my Win7 32 Bit mining rig w/CGMiner 3.2.1 and they are all off to the races.  When I receive my USB Hubs and fans I'll get the other two working as well but for now 4 is all I could get to fit into my rig.

It couldn't have been easier.  Thanks guys for making this so easy.  But I do miss the complicated setups and the trial and error, but it's nice to just have it work too.

Thanks,
Sam

[ISAWHIM]

Seems 3.2.0 and 3.2.1 have a greater number of rejections of "valid" blocks.

On faster systems, this is multiplied exponentially.

EG, (No other target-block in range) Reject rate about 25-50% submitted 456K, 125K, 214K, 100K, on a 100K rate. (Takes 120K-101K, but seems to reject exact targets, and over-targets, randomly.) Reject rate on a 7K hash-rate, is nearly 75%-80%... Thus, the decaying rates of all scrypt-coins at the moment. (EG, estimated earnings 100 coins returns a real-world earning of only 20 coins. Once again, with no target blocks being the "cause of the rejection".)

This is NOT present with 3.1.0 but that program is no longer compatible with new wallets/servers. Something dramatic changed, and it rejects 100% of those blocks, if it even connects at all. EG, using 3.1.0 and a compatible wallet, this does not happen, but the older wallets are no longer accepted with the network.

This is NOT limited to scrypt mining. This is happening to sha256 also, and I assume bitcoin... thus, the value remaining steady and the "rate" not rising proportionally with the work-load, because the work-load is only producing 80-75% valids that the network is accepting. (Either they are not actually valid, but the miner thinks they are... or they are, and they are not being delivered and confirmed correctly on the wallet/server side.)

Run a test with a difficulty of 7K... Solo, and with a mini-network. (Using compiled windows programs, as I can not confirm these results with linux, where they might not exist. Present on Win7-64bit and Vista-32bit. Same results.)

CGminer 3.1.0 and lower works on wallets versions 6.3 and lower. CGminer 3.2.x only works on wallets 6.4 and higher. (It has been a scramble to upgrade all the networks, and now they are all failing due to this issue. Falling difficulties yielding lower returns than higher difficulties, which results in even lower difficulties and even higher losses. Since even less coins are mined with each lower difficulty, not more, as expected.)

Though it is the same results... "Vista 32-bit" has 50% valid rejects, while "Win7 64-bit" has closer to 80% valid rejects. (Partially a 64-bit incompatability issue? Using calls with invalid LONGS... 32-bit and 64-bit do not operate the same. Seems like one call causing trouble, or TCP delivery failure, making it invalid, when it is actually valid.)

[mdude77]

Seems 3.2.0 and 3.2.1 have a greater number of rejections of "valid" blocks.

On faster systems, this is multiplied exponentially.

EG, (No other target-block in range) Reject rate about 25-50% submitted 456K, 125K, 214K, 100K, on a 100K rate. (Takes 120K-101K, but seems to reject exact targets, and over-targets, randomly.) Reject rate on a 7K hash-rate, is nearly 75%-80%... Thus, the decaying rates of all scrypt-coins at the moment. (EG, estimated earnings 100 coins returns a real-world earning of only 20 coins. Once again, with no target blocks being the "cause of the rejection".)

This is NOT present with 3.1.0 but that program is no longer compatible with new wallets/servers. Something dramatic changed, and it rejects 100% of those blocks, if it even connects at all. EG, using 3.1.0 and a compatible wallet, this does not happen, but the older wallets are no longer accepted with the network.

This is NOT limited to scrypt mining. This is happening to sha256 also, and I assume bitcoin... thus, the value remaining steady and the "rate" not rising proportionally with the work-load, because the work-load is only producing 80-75% valids that the network is accepting. (Either they are not actually valid, but the miner thinks they are... or they are, and they are not being delivered and confirmed correctly on the wallet/server side.)

Run a test with a difficulty of 7K... Solo, and with a mini-network. (Using compiled windows programs, as I can not confirm these results with linux, where they might not exist. Present on Win7-64bit and Vista-32bit. Same results.)

CGminer 3.1.0 and lower works on wallets versions 6.3 and lower. CGminer 3.2.x only works on wallets 6.4 and higher. (It has been a scramble to upgrade all the networks, and now they are all failing due to this issue. Falling difficulties yielding lower returns than higher difficulties, which results in even lower difficulties and even higher losses. Since even less coins are mined with each lower difficulty, not more, as expected.)

Hmm.  Not sure I understand all this.  But I can say I found using 3.1.1 against Bitminter gives me more rejects directly than if I funnel them through the stratum proxy.  I prefer using the proxy because it kicks in the variable difficulty and only one machine is connecting to the pool instead of all 4, reducing my (and pool ops) bandwidth usage.

Getting 4 difficulty thru the proxy, I get hardly any rejects.  Whereas with 1 difficulty with each miner going there individually, I do see more.  I can't quantify it, and it might just be because there are more diff 1 shares submitted than diff 4 shares, therefore I'll see more rejects. 

Just my $.02 worth.

M

[ISAWHIM]

So that may confirm it is a TCP thing... (Delivery)... Since stratum is a separate TCP controller. (Eg data not being "packed right, loosing data, or clipping due to "MTU transmission limits reached". Or a missing terminator or terminator that is being "seen" as part of the submitted data, thus, corrupting the valid, making it look invalid.)

However, even pools with stratum are facing this issue. (They are assuming it is the pool-program, but I have confirmed it is a wallet/miner issue, through every single coin, and the difficulty charts confirm it. The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

[os2sam]

The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

The difficulty adjusts every 2,016 blocks.  According to Bitcoin Watch we still have 891 to go.

[-ck]

The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

The difficulty adjusts every 2,016 blocks.  According to Bitcoin Watch we still have 891 to go.

As os2sam said:
15605632.68129 | Next Diff in 889 blocks | Estimated Change: 20.3644% in 4d 21h 56m 38s

All looks fine to me.

[Mobius]

However, even pools with stratum are facing this issue. (They are assuming it is the pool-program, but I have confirmed it is a wallet/miner issue, through every single coin, and the difficulty charts confirm it. The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

You might want to lay off the caffeine or whatever else your sipping on.

http://allchains.info/ shows 18M in ~5 days.

[ISAWHIM]

The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

The difficulty adjusts every 2,016 blocks.  According to Bitcoin Watch we still have 891 to go.

And it hasn't adjusted since cgminer version 3.2.0 was created, which everyone is now using... Has been more than 5 days... But who cares about BTC, that is for the ASIC manufactures now. You have to look at a graph of difficulty, not just the next target. Compared to the "mined coins" and "network hashing power."

I just downgraded to 3.2.0 on win7-64bit, and it is showing 50% rejects of valids, so it is on par with 3.2.0 and 3.2.1 running on vista-32bit. Thus, it is "partially" a 32/64 bit issue, and something that absolutely changed from 3.1.0 to 3.2.0 and got worse for 64-bit systems on 3.2.1...

Perhaps you "mistakenly" included one of the linux files/code in the compile for windows. (Which would be a slight issue, if it was something like using a linux INT vs a windows INT, or LONG, or something like byte-order... that might be specific to linux. or a terminator chr(13)chr(10) which is a windows only thing, in code {CRLF} not just {CR} or {LF} like linux allows, or a TAB where there should be a SPACE in a quoted comparison, which would not show if the TAB in code was at the SPACE mark. Something small, I am sure... But something from those versions that changed for validity submission/checking, related to sending over HTTP/TCP.)

NOTE: Actual win7-64bit results running cgminer 3.2.0 (the downgrade), best run on "Fastcoins" = 60% valids accepted. (Better, but not the 85% I was getting with cgminer 3.1.0. Way better than the 78% rejects of valids using 3.2.1 on win7-64bit. Vista 32-bit is still at 50% rejects of valids on the downgrade.) Difficulty is 7.56K, which is 0.115333 in scrypt-mining. That is a 12 seconds block target. Retargets about every hour. Good to test on.

If 3.1.0 still worked on any of the wallets, for solo-mining, I would downgrade again... but 3.1.0 is essentially dead in the water for me.

[Mobius]

r u on p2pool?

[ISAWHIM]

r u on p2pool?

I am solo-mining with my army of GPUs. I am not in any pools at the moment... I avoid pools, due to the many "issues" that more-often-than-not, lead to losses. (Some losses are acceptable, but when they constantly "cut your connection", to make you "loose shares", and "estimate poorly", and "drop actual earned shares"... yet they mine themselves too... thus gain both ways. I loose faith. Sadly, it is the smaller pools that get the short end of the stick, trying to help-out those who just can't solo-mine anything.)

All pools as of late, have had the same results. (Not bitcoin pools, because those blocks are so far away, and obviously, low diffs don't even matter to bitcoins. However, shares have seen similar results, if you set shares to 4K-20K... but no-one uses shares that high.)

Easy to see it visually than to try to explain.
http://www.coinwarz.com/cryptocurrency

You can see the results in the graphs here, related to diff issues... diffs should be going up, not down... they do go up, when people stop mining. They stop, because the diff drops, and less coins are produced, due to the above stated issue of "more rejects of valids"... Rejecting 140K submits with diff of 30K, withe no other block in range. Thus, not rejected sue to being "close" or "too late to submit"... Just flat out rejected.

I even have one with a big fat "?" in my list of transactions... lol... even the wallet is not sure what to think of it! (Eg, not rejected, not an orphan, just a "?" not sure what it is. Valid when found, valid when submitted, but "?" in my wallet, and the network, I assume.)

[freshzive]

Weird, I got cgminer3.2.1 to compile the first time in OS X 10.8. Plugged in my USB2 hub with 7 Block erupters and they are mining a way with 0 issues, even without adding --hotplug 0. Rejects are gone that I was seeing with 3.1.1 on Ubuntu as well.

So, it seems whatever was causing my devices to disconnect and become "SICK" on Ubuntu isn't an issue on my mac. Strange.

Glad it's working now though

[Xmansk]

Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.

Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.

Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?