Author

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

legendary
Activity: 1540
Merit: 1001
hero member
Activity: 504
Merit: 500
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.)
legendary
Activity: 3583
Merit: 1094
Think for yourself
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
full member
Activity: 224
Merit: 100
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%)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Maybe you can try disabling hotplug too? --hotplug 0


Still getting these Sad

 [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...
sr. member
Activity: 447
Merit: 250
Maybe you can try disabling hotplug too? --hotplug 0


Still getting these Sad

 [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
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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
sr. member
Activity: 447
Merit: 250
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.
hero member
Activity: 1246
Merit: 501

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.  Grin  Sorry I had to do it.  Kiss
hero member
Activity: 1246
Merit: 501

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

I'll try that. 
hero member
Activity: 1246
Merit: 501
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.  Roll Eyes

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.

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.  Roll Eyes

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.

P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0
hero member
Activity: 1246
Merit: 501
member
Activity: 75
Merit: 10
ckolivas, thank you.  I used the zadig utility and changed the drivers and now the new version is running fine.  I thought it was something simple I was overlooking and it was.  I was missing the obvious and was stuck so I really appreciate the answer you gave.  I expect to be receiving my new ASIC single from BFL this week so I wanted to have the latest version.  Now I do, once again thank you
hero member
Activity: 526
Merit: 500
Its all about the Gold
How do i set up to lower my discarded work due to a new block?

Also is there a way to increase my shares above target and decreasing

my shares below target?

here is a partial log report just completed for about 6 and a half

hours:

[10/06/2013 12:42:28 PM] Share below target
 [10/06/2013 12:42:33 PM] Share below target
 [10/06/2013 12:43:17 PM] Share below target
 [10/06/2013 12:43:24 PM] Share below target
 [10/06/2013 12:43:25 PM] New block: 9c769647a18857de... diff 41.8M
 [10/06/2013 12:43:25 PM] Stratum from pool 0 detected new block
 [10/06/2013 12:43:26 PM] Share below target
 [10/06/2013 12:43:31 PM] Share below target
 [10/06/2013 12:43:41 PM] Share below target
 [10/06/2013 12:43:51 PM] Share below target
 [10/06/2013 12:44:12 PM] Share below target
 [10/06/2013 12:44:25 PM] New block: 168ef66e83963534... diff 41.8M
 [10/06/2013 12:44:25 PM] Stratum from pool 0 detected new block
 [10/06/2013 12:44:27 PM] (120s):4.352K (avg):4.350Kh/s | A:25  R:0 

HW:0  U:0.1/m  WU:4.1/m

 [10/06/2013 01:07:32 PM] Started at [10/06/2013 06:35:54 AM]
 [10/06/2013 01:07:32 PM] Pool: stratum+tcp://ltc.allpoolz.com:8080
 [10/06/2013 01:07:32 PM] Runtime: 6 hrs : 31 mins : 37 secs
 [10/06/2013 01:07:32 PM] Average hashrate: 4.4 Kilohash/s
 [10/06/2013 01:07:32 PM] Solved blocks: 0
 [10/06/2013 01:07:32 PM] Best share difficulty: 6.32K
 [10/06/2013 01:07:32 PM] Share submissions: 25
 [10/06/2013 01:07:32 PM] Accepted shares: 25
 [10/06/2013 01:07:32 PM] Rejected shares: 0
 [10/06/2013 01:07:32 PM] Accepted difficulty shares: 1600
 [10/06/2013 01:07:32 PM] Rejected difficulty shares: 0
 [10/06/2013 01:07:32 PM] Reject ratio: 0.0%
 [10/06/2013 01:07:32 PM] Hardware errors: 0
 [10/06/2013 01:07:32 PM] Utility (accepted shares / min): 0.06/min
 [10/06/2013 01:07:32 PM] Work Utility (diff1 shares solved / min):

4.11/min
                                     920 discarded due to new work

requests
 [10/06/2013 01:07:32 PM] Stale submissions discarded due to new

blocks:

0
 [10/06/2013 01:07:32 PM] Unable to get work from server occasions: 0
 [10/06/2013 01:07:32 PM] Work items generated locally: 1555
 [10/06/2013 01:07:32 PM] Submitting work remotely delay occasions: 0
 [10/06/2013 01:07:32 PM] New blocks detected on network: 142

Current Settings:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1

"C:\Users\xxxxx\Desktop\guiminer-

scrypt_win32_binaries_v0.04\cgminer\cgminer-3.1.1-windows

\cgminer.exe" --scrypt -u xxxxx -p xxxxxx -o stratum

+tcp://ltc.allpoolz.com:8080 2>logfile.txt 3>sharesfound.txt --gpu-

platform 0 -d 0 -w 128 -v 1 -I 9 -g 1 -l 1 --shaders 1500 --thread-

concurrency 4064 --lookup-gap 2


as you can see 1600 accepted shares but only 25 of 64 difficulty

along with 920 that were being worked on when a new block was found

and was discarded.Whats even more disturbing is that only 142 new

blocks detected on network but yet 920 possible shares were

discarded.

Any suggestions on how i can improve upon this "Without" new

hardware?
sr. member
Activity: 258
Merit: 250
I think you might already know about this issue but anyway..

I am using the Raspberry Pi and i got cgminer 3.2.1 working perfectly with one Block Erupter on my hub. Giving amazing results even, less than 1% HW issues.

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.

Im using the same hub and 4 block erupters but with cgminer 3.1.1 on windows 7 32 bit and they are going to town, hashing with no issues. So my hub and block erupters are playing nicely together.

Has anyone successfully gotten cgminer working with multiple block erupters on their raspberry pi yet?
hero member
Activity: 630
Merit: 500
I am solo mining LTC on my rigs, and have them pointing to a wallet on my LAN. When I added a failover pool (Coinotron), it picks up updates from that pool, and all new blocks come across as: "Stratum from Pool 1 Detected New Block" Instead of the expected solo: "New Block Detected"

I also get "Stratum Connection to Pool 1 Interrupted" and "Pool 1 Difficulty Changed to xxx" messages frequently.

It doesn't appear to impact me as I still find my solo blocks, but I'm wondering if I need to change back to just solo with no failover, so it doesn't keep wandering over to my failover pool to see what is going on there. Is this normal behavior? Does it take away any performance by checking both my local wallet and the pool? Thanks in advance for any advice!


This is intentional and advantageous for solo miners.

Thank you very much for the confirmation. I believe from what I read Stratum is much more dependable and makes sure that you are on the correct block and in sync with the chain. I wanted to make sure that it wasn't degrading anything by watching the pool info at the same time it solo mines. I assume if I removed the Stratum from the failover it would test if there was any degradation, I just didn't experiment. I greatly appreciate you answering my question.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Zanatos, I did download from the BFL site.  I didn't understand how to install it but I checked versions and it is the same version I have installed.  Cgminer-2.10.5 is working fine so I don't understand why the new one is not working for me.

Read the readme THAT COMES WITH THE VERSION YOU HAVE.

It clearly says when you're starting that it needs a WinUSB driver, but you have the FTDI driver installed.
member
Activity: 75
Merit: 10
Zanatos, I did download from the BFL site.  I didn't understand how to install it but I checked versions and it is the same version I have installed.  Cgminer-2.10.5 is working fine so I don't understand why the new one is not working for me.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I am solo mining LTC on my rigs, and have them pointing to a wallet on my LAN. When I added a failover pool (Coinotron), it picks up updates from that pool, and all new blocks come across as: "Stratum from Pool 1 Detected New Block" Instead of the expected solo: "New Block Detected"

I also get "Stratum Connection to Pool 1 Interrupted" and "Pool 1 Difficulty Changed to xxx" messages frequently.

It doesn't appear to impact me as I still find my solo blocks, but I'm wondering if I need to change back to just solo with no failover, so it doesn't keep wandering over to my failover pool to see what is going on there. Is this normal behavior? Does it take away any performance by checking both my local wallet and the pool? Thanks in advance for any advice!


This is intentional and advantageous for solo miners.
Jump to: