That's by design in these chips. An error rate around 10% is to be expected. I can make it read zero artificially in cgminer if you like...
No no! The numbers should always stay true to the actual figures. If we as consumers and hackers-around need to be educated on the parameters of the particular hardware and chips in use, that's a totally separate issue. If that's normal operation for these chips its better to see the real data and have a proper understanding of what it means, which is where experienced comments like yours and support threads like this come in perfectly handy. Just for the avoidance of doubt: My point isn't to cast any blame, it just exploring whether this performance could be improved by the basic environmental factors. Personally, I'm actually pleased with the performance now I've realised my original pool result was at fault. Thanks for your time, comments and coding, by the way. I was joking  |
|
|
|
High error rate for my taste, but respectable throughput IMO considering the circumstances. I'm most keen to see if I can reduce the HW with sufficient cooling, will report back when I've had time to play properly this weekend.
That's by design in these chips. An error rate around 10% is to be expected. I can make it read zero artificially in cgminer if you like... |
|
|
|
is not only Windows Ubuntu 13.10: AMU 0: | ZOMBIE/182.3Mh/s | A: 1767 R: 12 HW: 139 WU: 2.4/m
AMU 1: | ZOMBIE/177.4Mh/s | A: 3740 R: 4 HW: 126 WU: 2.4/m
AMU 2: | ZOMBIE/182.5Mh/s | A: 1857 R: 13 HW: 139 WU: 2.3/m
AMU 3: | ZOMBIE/182.5Mh/s | A: 3919 R: 12 HW: 139 WU: 2.4/m
AMU 4: | ZOMBIE/155.8Mh/s | A: 1460 R: 12 HW: 93 WU: 2.1/m
AMU 5: | ZOMBIE/182.4Mh/s | A: 1722 R: 0 HW: 136 WU: 2.5/m
AMU 6: | ZOMBIE/182.0Mh/s | A: 3710 R: 16 HW: 128 WU: 2.4/m
AMU 7: | ZOMBIE/156.1Mh/s | A: 1425 R: 12 HW: 114 WU: 2.1/m
AMU 8: | ZOMBIE/182.2Mh/s | A: 1829 R: 16 HW: 144 WU: 2.5/m
AMU 9: | ZOMBIE/182.3Mh/s | A: 1772 R: 16 HW: 136 WU: 2.4/m
BAL 0: max 58C 3.27V | ZOMBIE/16.38Gh/s | A:195597 R:5755 HW:1076 WU: 227.4/m
cgminer 3.8 That windows binary is truly a windows only thing that I implemented. Your zombies I'm gonna blame on your hardware * ckolivas runs away screaming |
|
|
|
I'm seeing a problem with 3.8.1 on an RPi running Rasbian. Twice in the last 24 hours cgminer has stopped running. It appears as if the "q" key was pressed even though I'm sure it was not. This hardware has run solid for weeks before I upgraded to 3.8.1.
Here is a link to instructions. Scroll down to the section that says Rpi freezing up. http://projectklondike.org/how-to-runChad Thanks but that is not the problem I'm seeing. My RPi does not freeze or lock up. Instead it appears as if the 'q' key was pressed and cgminer quits for no apparent reason. It happened again last night. I will revert to an older version. BTW - when getting source from github, now do I request an older version (such as 3.7.2)? I can't just go back to the ancient version I was using (3.4.2). Use a tag git checkout v3.7.2 or whatever |
|
|
|
The numbers are (I've included the BE just for comparative purposes against other cheap hardware):
REPORTED BY CGMINER 3.8.1
AMU 0: | 335.3M/335.1Mh/s | A: 4204 R: 0 HW: 41 WU: 4.7/m
BF1 0: | 2.183G/2.175Gh/s | A:27518 R:203 HW:1847 WU:30.6/m
REPORTED BY POOL (Ozco.in)
AMU 449.09 MHash/s
BF1 1,294.84 MHash/s
It's my understanding that the hashrate meter is constantly being revised at ozcoin and it's been rather inaccurate of late. Check the actual number of shares match to confirm there's nothing going astray, or try it on another pool (for at least an hour). |
|
|
|
|
Windows users with issues on 3.8.1 can just use 3.7.2. For most drivers it is trivially different except for the one change that might be the cause of your problems.
|
|
|
|
Such a pitty to see scrypt mining gone.
Majority of Alt Coins is scrypt based - would there be any plans to support it again in the future?
GPU bitcoin mining doesn't make sense for a while now and it's obviously the way to go...
No 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. That should have already make it clear what my position is regarding altcoins. Deprecating GPU mining wasn't to get rid of the GPU bitcoin mining code. |
|
|
|
Just spotted a bug in 3.8.1 on Windows.
When entering server details on initial startup, if a mistake is made and characters deleted, those wrong chars and backspace control codes are saved in the cgminer.conf. On next startup the .conf is declared corrupt.
I'm pretty sure I noted that somewhere. cgminer won't allow any key stroke mistakes. I always end up going to the config file and clean the backspace charactors out and restart cgminer. Ok wasn't aware of that issue. Will look into it at some stage, but I'm trying VERY hard to not release anything new anytime soon. It's been a hell of a ride getting this far with massive overhauls in the last few months, but it's all about looking to the future. Just think, pretty much 99.9% of the bitcoin network hashrate contributed to by cgminer is coming from hardware that did not even exist one year ago. All of the FPGAs should be switched off by now due to inefficiency and by early next year, 1st generation ASICs will be unprofitable to run too. By the middle of next year, 28nm technology efficiency will be the minimum requirement to be worth mining bitcoin so I have to concentrate my development efforts accordingly. |
|
|
|
My Avalon recently stopped hashing, and this is what cgminer outputs with debug enabled (hopefully relevant excerpt):
[2013-10-11 10:32:48] AVA0: GetAvalonReset (amt=64 err=-8 ern=11)
Can anyone suggest a remedy? Thanks in advance.
-8 is an overflow error which is unusual. Which firmware are you running? Try upgrading to latest supported |
|
|
|
Cgminer does not support adding a text identifier and will generate whatever block is generated based on the work from bitcoind/qt which will be all random.
But, I could have sworn there was a bitcoin client/bitcoind command line option that would do that too, so that the mining software didn't have to do it. Could be, could be. I'm no expert on the bitcoin client software. |
|
|
|
If not, could CGminer be hacked/patched to do this? It would require me to write support for the most low level GBT support which I've been avoiding doing since it's a lot of work, and the demand for better solo mining support has never been big or on my priority list for obvious reasons... |
|
|
|
|
Cgminer does not support adding a text identifier and will generate whatever block is generated based on the work from bitcoind/qt which will be all random.
|
|
|
|
As Kano linked in the wikipedia article, that is the correct official suffix for billion, you're just not used to seeing values that large suffixed with a letter.  EDIT: Prefix/Suffix, whatever... |
|
|
|
600GH makes 0.59 BTC per day right now. By Feb these things will be so worthless.
Wow, are you kidding? (Seriously, has it dropped that much already?) Wow, what planet have you been hiding on? |
|
|
|
|
Well, not really. I know someone using 38 erupters on cgminer on an RPi that uses 3% CPU. Admittedly that's a linux whereas you're on a windows. Some windows USB drivers consume a lot when they're used for the hotplug aspect in cgminer (specifically I think Nvidia's chipsets were the worst). If all your erupters come up straight away you can disable hotplug entirely with --hotplug 0, or probably better to just set it to less frequently in case a device drops out and needs to be hotplugged, to say every minute with --hotplug 60
|
|
|
|
|
Show Posts
