Doff
|
|
November 11, 2013, 12:46:32 AM |
|
following Dave's post: One thing worth looking at is the .stat.log - its located here: /run/shm/.stat.log - at the bottom is a card summary. If you are seeing high miso-err or spi-err from a card, its introducing noise. That card will drag down any cards following it in its bank. Try placing that card in the last position of any bank and it shouldn't affect its neighbors. If it still won't play nice, RMA it - log into your megabigpower.com account and go through the Returns process.
Dave
`speed:13312 noncerate[GH/s]:177.511 (0.693/chip) hashrate[GH/s]:188.753 good:12399 errors:1067 spi-err:38 miso-err:318 jobs:295 cor es:24% good:256 bad:0 off:0 (best[GH/s]:251.141) Sun Nov 10 23:08:14 2013' Is just one of the cards producing all those spi/miso errors? Don't know - I have all cards plugged in when I got this reading. `speed:13312 noncerate[GH/s]:383.569 (1.498/chip) hashrate[GH/s]:409.743 good:26792 errors:2066 spi-err:36 miso-err:171 jobs:362 cores:13% good:256 bad:0 off:0 (best[GH/s]:0.000) Mon Nov 11 00:08:00 2013' My last reading just now A couple things I found with cooling is you don't want to cool it too much, there is this weird middle ground. Also you need to check the Voltage on each Unit, I found some were at .87, some at .80, others at .88, it was all over the place. I have almost all of them now at 8.6 with one card that has some dead Chips. Its been stable for two days but it did take a lot testing. I now only have 3 fans on top of the unit, and 1 Box fan on low blowing across it from the opposite side of the regulators. You check the voltage with the Unit on, using the Ground on the two Silver PCI power connectors at the end, and the other on the pulse regulator on the silver part. I also had to ask since I don't usually mess with electronics in this way. The other fine tuning you need to do is with the best.cnf. I just copied the .stat.log to a new file called best.cnf after it ran for around 12 hours and then turned off the Auto on the dead chips, or near dead chips which gave me another 5-7G. I found that info here https://bitcointalk.org/index.php?topic=287590.msg3079406#msg3079406 and from people in this post.
|
|
|
|
frankenmint
Legendary
Offline
Activity: 1456
Merit: 1018
HoneybadgerOfMoney.com Weed4bitcoin.com
|
|
November 11, 2013, 12:58:10 AM |
|
following Dave's post: One thing worth looking at is the .stat.log - its located here: /run/shm/.stat.log - at the bottom is a card summary. If you are seeing high miso-err or spi-err from a card, its introducing noise. That card will drag down any cards following it in its bank. Try placing that card in the last position of any bank and it shouldn't affect its neighbors. If it still won't play nice, RMA it - log into your megabigpower.com account and go through the Returns process.
Dave
`speed:13312 noncerate[GH/s]:177.511 (0.693/chip) hashrate[GH/s]:188.753 good:12399 errors:1067 spi-err:38 miso-err:318 jobs:295 cor es:24% good:256 bad:0 off:0 (best[GH/s]:251.141) Sun Nov 10 23:08:14 2013' Is just one of the cards producing all those spi/miso errors? Don't know - I have all cards plugged in when I got this reading. `speed:13312 noncerate[GH/s]:383.569 (1.498/chip) hashrate[GH/s]:409.743 good:26792 errors:2066 spi-err:36 miso-err:171 jobs:362 cores:13% good:256 bad:0 off:0 (best[GH/s]:0.000) Mon Nov 11 00:08:00 2013' My last reading just now A couple things I found with cooling is you don't want to cool it too much, there is this weird middle ground. Also you need to check the Voltage on each Unit, I found some were at .87, some at .80, others at .88, it was all over the place. I have almost all of them now at 8.6 with one card that has some dead Chips. Its been stable for two days but it did take a lot testing. I now only have 3 fans on top of the unit, and 1 Box fan on low blowing across it from the opposite side of the regulators. You check the voltage with the Unit on, using the Ground on the two Silver PCI power connectors at the end, and the other on the pulse regulator on the silver part. I also had to ask since I don't usually mess with electronics in this way. The other fine tuning you need to do is with the best.cnf. I just copied the .stat.log to a new file called best.cnf after it ran for around 12 hours and then turned off the Auto on the dead chips, or near dead chips which gave me another 5-7G. I found that info here https://bitcointalk.org/index.php?topic=287590.msg3079406#msg3079406 and from people in this post. Others stated NOT to do it that way as it overdeclares your voltage by anywhere between .06 and .02 V I took out 10 cards, just trying the top six performing cards for the next 30 minutes to confirm for sure that these are working well they are avg about 30 Gh per card (which in my mind is okay if they at least stay on)
|
|
|
|
Doff
|
|
November 11, 2013, 01:13:50 AM |
|
All I know is once I got the heat right, and fixed the overclocked voltage on the bad cards they have been running fantastic.
speed:13536 noncerate[GH/s]:574.280 (2.243/chip) hashrate[GH/s]:586.880 good:40113 errors:426 spi-err:10 miso-err:263 duplicates:3 jobs:262 cores:99% good:256 bad:0 off:0 (best[GH/s]:593.464) Mon Nov 11 01:10:03 2013 board-2 speed nrate hrate good errors spi-err miso-er duplic good bad off per chip good cores 0: 848 38.397 38.812 2682 14 3 0 1 16 0 0 (2.400/chip) 100% 1: 848 37.438 37.374 2615 8 0 0 0 16 0 0 (2.340/chip) 100% 2: 848 35.648 37.533 2490 55 1 0 0 16 0 0 (2.228/chip) 97% 3: 848 36.665 37.025 2561 7 0 0 0 16 0 0 (2.292/chip) 100% 4: 848 36.751 37.480 2567 12 3 0 1 16 0 0 (2.297/chip) 99% 5: 848 36.278 37.913 2534 62 0 0 1 16 0 0 (2.267/chip) 98% 6: 848 36.980 37.596 2583 63 0 0 0 16 0 0 (2.311/chip) 97% 7: 832 35.147 35.577 2455 14 0 0 0 16 0 0 (2.197/chip) 100% 8: 848 35.247 36.666 2462 17 2 0 0 16 0 0 (2.203/chip) 100% 9: 832 33.816 34.330 2362 11 0 0 0 16 0 0 (2.113/chip) 100% A: 848 36.307 36.370 2536 10 0 0 0 16 0 0 (2.269/chip) 100% B: 848 36.235 37.649 2531 67 0 0 0 16 0 0 (2.265/chip) 98% C: 848 34.761 36.867 2428 50 0 0 0 16 0 0 (2.173/chip) 98% D: 848 36.063 36.212 2519 8 0 1 0 16 0 0 (2.254/chip) 100% E: 848 34.088 34.383 2381 5 0 262 0 16 0 0 (2.130/chip) 93% F: 848 34.460 35.091 2407 23 1 0 0 16 0 0 (2.154/chip) 99%
That's been running since Early Friday without needing to touch it, consistently over 570GH
|
|
|
|
frankenmint
Legendary
Offline
Activity: 1456
Merit: 1018
HoneybadgerOfMoney.com Weed4bitcoin.com
|
|
November 11, 2013, 01:20:16 AM |
|
how did you get that output from the pi?
|
|
|
|
Doff
|
|
November 11, 2013, 01:26:28 AM |
|
how did you get that output from the pi?
I just cat the file like this, lots of ways you can do it in linux. cat .stat.log | tail -n 18 That gives you the last 18 lines of the log. Also you may need to elongate your terminal window otherwise it truncates it in a weird way.
|
|
|
|
frankenmint
Legendary
Offline
Activity: 1456
Merit: 1018
HoneybadgerOfMoney.com Weed4bitcoin.com
|
|
November 11, 2013, 01:31:23 AM |
|
how did you get that output from the pi?
I just cat the file like this, lots of ways you can do it in linux. cat .stat.log | tail -n 18 That gives you the last 18 lines of the log. Also you may need to elongate your terminal window otherwise it truncates it in a weird way. That has got to be the one BIG positive about this whole experience, I never touched any linux before this
|
|
|
|
Doff
|
|
November 11, 2013, 01:35:32 AM |
|
how did you get that output from the pi?
I just cat the file like this, lots of ways you can do it in linux. cat .stat.log | tail -n 18 That gives you the last 18 lines of the log. Also you may need to elongate your terminal window otherwise it truncates it in a weird way. That has got to be the one BIG positive about this whole experience, I never touched any linux before this I think you will be happy once you get all your rigs running at 570+, they have definitely been more finicky then I thought they would be. I honestly think if I knew what I was doing I could get this thing over 600. I am kinda hoping more people experiment with the OCT Hardware and share it with the community. I know there are some fantastic hardware guys out there.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 11, 2013, 04:47:27 AM |
|
just to throw more crap variables into the mix; i had a bad Raspi.
bad enough only to take hashing sub 100's for several days making it all the more confusing. thank goodness it fully failed allowing me to figure it wasn't so much the boards. inserted a new one and am at least now up in the 400's now.
Chainminer doesn't match my pool readings either. ugh.
|
|
|
|
frankenmint
Legendary
Offline
Activity: 1456
Merit: 1018
HoneybadgerOfMoney.com Weed4bitcoin.com
|
|
November 11, 2013, 06:34:37 AM |
|
just to throw more crap variables into the mix; i had a bad Raspi.
bad enough only to take hashing sub 100's for several days making it all the more confusing. thank goodness it fully failed allowing me to figure it wasn't so much the boards. inserted a new one and am at least now up in the 400's now.
Chainminer doesn't match my pool readings either. ugh.
Deleted my last post because I'm still needing to tune down two cards that go out to zero. Did your Raspi give any symptoms?
|
|
|
|
ktbken
|
|
November 11, 2013, 12:05:30 PM |
|
Hi Anyone got bfg working with new v3 boards as it cannot seem to see them with normal settings that work for v1-2 ?
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 11, 2013, 04:43:57 PM |
|
just to throw more crap variables into the mix; i had a bad Raspi.
bad enough only to take hashing sub 100's for several days making it all the more confusing. thank goodness it fully failed allowing me to figure it wasn't so much the boards. inserted a new one and am at least now up in the 400's now.
Chainminer doesn't match my pool readings either. ugh.
Deleted my last post because I'm still needing to tune down two cards that go out to zero. Did your Raspi give any symptoms? it was confusing b/c it didn't fail outright. the rig would start out hashing around 300ish, then drift down to sub 100's. then it wouldn't boot up at all with just a red light. originally i thought it was the sd card as above posts will indicate but fortunately i have new raspi's laying around. the fact that the card booted up on the new raspi told me it wasn't the card. plus, it told me that the ip address was overlapping with one of the other rigs thus explaining why both went to 0 when trying to boot this one up. inexplicably it started working again but still below 100's. b/c of this erratic behavior and the fact that just earlier had given me a red light, i decided to swap out the raspi. sure enough, now i'm hashing mid 400's during the day. it even hit 640 last night on ozcoin! these BF's, in general, are definitely doing much better at nighttime when it gets cold here. it's a bite, at least for me, b/c there are so many possibilities where things can go wrong with these fragile units. is it the chips, h boards, m boards, regulator, chainminer, or raspi? my avalons, in contrast, are much more stable and consistent. on a side note, has anyone noticed ozcoin is showing higher hashrates than what is displaying locally in chainminer? are other pools doing the same?
|
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
November 11, 2013, 04:58:02 PM |
|
So, a couple of my cards started turning off permanently until reboot again and I cranked their voltage down to about 0.8 V.
Rig is hashing at about 352 GH/s now instead of 360, but it seems stable.
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 11, 2013, 05:11:59 PM |
|
So, a couple of my cards started turning off permanently until reboot again and I cranked their voltage down to about 0.8 V.
Rig is hashing at about 352 GH/s now instead of 360, but it seems stable.
so how do you "anticipate" the amount of counterclockwise turning of the trimpot nut needed to decrease voltage?
|
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
November 11, 2013, 05:17:39 PM |
|
So, a couple of my cards started turning off permanently until reboot again and I cranked their voltage down to about 0.8 V.
Rig is hashing at about 352 GH/s now instead of 360, but it seems stable.
so how do you "anticipate" the amount of counterclockwise turning of the trimpot nut needed to decrease voltage? It seems like about a quarter turn or so is 0.050 V, but it's not consistent among cards I find
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 11, 2013, 05:21:25 PM |
|
So, a couple of my cards started turning off permanently until reboot again and I cranked their voltage down to about 0.8 V.
Rig is hashing at about 352 GH/s now instead of 360, but it seems stable.
so how do you "anticipate" the amount of counterclockwise turning of the trimpot nut needed to decrease voltage? It seems like about a quarter turn or so is 0.050 V, but it's not consistent among cards I find any response on the rma to return heatsinked defective h boards?
|
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
November 11, 2013, 05:25:24 PM |
|
So, a couple of my cards started turning off permanently until reboot again and I cranked their voltage down to about 0.8 V.
Rig is hashing at about 352 GH/s now instead of 360, but it seems stable.
so how do you "anticipate" the amount of counterclockwise turning of the trimpot nut needed to decrease voltage? It seems like about a quarter turn or so is 0.050 V, but it's not consistent among cards I find any response on the rma to return heatsinked defective h boards? Nah, haven't heard anything one way or the other, but since I adjusted the trimpots everything has been running more or less okay. Probably Dave is sitting around tweaking 8 bajillion of them in the TH/s mine at the moment
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
salfter
|
|
November 11, 2013, 05:26:41 PM |
|
I Too compiled BFG miner and it only ran with 100% hw errors as well (after 15 minutes of running the timings never adjusted upward as they are expected.) Have you tried patching the bfgminer source to start at a slower speed, as I've done? I have mine locked at 52, and it's been running for close to two days now. The hardware error rate over that period has been about 0.25%...not as good as the BFL miners (one of those logged one error in the same period, while the other has zero), but still fairly low. At 52, I'm getting 68-69 GH/s from two H-boards.
|
|
|
|
salfter
|
|
November 11, 2013, 05:30:53 PM |
|
Anyone got bfg working with new v3 boards as it cannot seem to see them with normal settings that work for v1-2 ?
Been working for me for the past couple of days, built from GitHub HEAD. I posted build instructions earlier in this topic.
|
|
|
|
Xian01
Legendary
Offline
Activity: 1652
Merit: 1067
Christian Antkow
|
|
November 11, 2013, 09:45:38 PM Last edit: November 11, 2013, 10:10:14 PM by Xian01 |
|
Got my rigs in, and can't get chainminer connected to ghash.io at all Trying to build BFGMiner... Poop. EDIT: Fuck my ass. BFGMiner only picks up 4 of 16 boards on the first rig I'm trying to bring up... it's going to be a long night...
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
November 11, 2013, 10:09:36 PM |
|
I've written a cgminer driver (it's in the current cgminer 3.8.0/3.8.1) for the BlackArrow Bitfury V1 boards. I've no idea if that is the same as a standard Bitfury board - I never had one and the twits would never sell me one either. ... maybe I should have put in the copyright header that Punin and Buzzdave aren't allowed to use the driver Anyway, as I posted about it the other day: For anyone who has a V1 BlackArrow Bitfury board - the latest cgminer 3.8.1 (3.8.0 also) has the RPi source for a driver now - consider it an early release since there are certain improvements I'll make to it that I've already sorted out what to do - in future versions - but it already runs with great performance.
The configure option is --enable-bab
It runs at 39.9GH/s valid shares with a bit under 10% HW errors above the 39.9GH/s on a standard board i.e. if you were to also count bad nonces returned (which I prefer not to but I will mention in case anyone wishes to compare that number) it's returning 44GH/s of good+bad nonces.
I've run it with a single board on Raspbian to write and test it - it's based on the V1 initialisation of a single board. I based the I/O code on the chainminer GPIO/SPI code as should be obvious for anyone who looks at my driver-bab.c and chainminer (as I also mention that at the top of driver-bab.c)
It's a bit CPU hungry so soon I'll be spending more effort on reducing that - 20% CPU with a single board - I've only tested with a single board.
It also doesn't tune the chip at all - so there is also assured performance improvement there - it runs at default settings at the moment. That's the next effort I'll expend on the driver.
If anyone has a standard V1 BitFury board I'd also be curious to know if it works with them.
|
|
|
|
|