I got my unit running with bfgminer, the only thing I could get chainminer to do was output
"M-Board version 2 detected
INIT: 256 chips detected"
Now I'm having issues with bfgminer outputting this, and the hashrate dropping.
[2013-11-12 00:05:02] BSB 2bm: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 00:05:02] BSB 2bn: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 00:05:02] BSB 2bo: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 00:05:02] BSB 2bp: bitfury_init_oldbuf: Giving up after 4 tries
...
I'd get those errors if I let bfgminer initialize the cards with the clock set to 53. I turned it down to 52 and it's been running without issue for nearly 3 days:  See this post for details. still not work and got 100% HW errorrs. I got see too many BSB like bsb0 to bsb24 but I got only 6 Hboards that fun part. |
|
|
|
I got my unit running with bfgminer, the only thing I could get chainminer to do was output
"M-Board version 2 detected
INIT: 256 chips detected"
Now I'm having issues with bfgminer outputting this, and the hashrate dropping.
[2013-11-12 00:05:02] BSB 2bm: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 00:05:02] BSB 2bn: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 00:05:02] BSB 2bo: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 00:05:02] BSB 2bp: bitfury_init_oldbuf: Giving up after 4 tries
...
I'd get those errors if I let bfgminer initialize the cards with the clock set to 53. I turned it down to 52 and it's been running without issue for nearly 3 days: See this post for details. maybe I will do it again with 52 if thing will run ok. |
|
|
|
but putting in one night of work and calling it Bad is sortof shortsighted...
To be absolutely clear, I'm not calling anything bad. Just a bit surprised that we seem to collectively be having some trouble getting these v3 rigs humming along, stably. Eagerly awaiting updates and info on how to get our babies nice and happy. try to run only test on bad hboad alone if hboard isnt working that meant bad. |
|
|
|
Something definitely seems amiss with these kits. I received 32 H-Cards, and 2 M-Boards. 1 M-Board is DOA and have filled an RMA request with MBP. I've swapped out several H-Cards in slots that had their hash-rate go from full to zero, and even new sealed H-Cards start slowing down and approach 0 GHs in the same slots. Best I can tell, at least 2 H-Cards are completely DOA, and having sad-times getting a full M-Board hashing steady above 500. Fuck  Will let it run for a few hours and see how things look a bit later... EDIT: Well, that went to zero quickly... Fuck. Eg: Swapped slot 1 and 2 for new H-Cards... speed:13568 noncerate[GH/s]:351.042 (1.371/chip) hashrate[GH/s]:367.538 good:24520 errors:8994 spi-err:60 miso-err:125 duplicates:111 jobs:262 cores:24% good:256 bad:0 off:0 (best[GH/s]:0.000) Tue Nov 12 02:52:05 2013
board-2 speed nrate hrate good errors spi-err miso-er duplic good bad off per chip good cores
0: 848 34.245 35.863 2392 120 0 0 0 16 0 0 (2.140/chip) 31%
1: 848 0.000 0.000 0 0 0 0 0 16 0 0 (0.000/chip) 8% speed down
2: 848 0.000 0.000 0 0 0 0 0 16 0 0 (0.000/chip) 8%
3: 848 35.391 36.687 2472 3 1 0 0 16 0 0 (2.212/chip) 33%
4: 848 0.000 0.000 0 0 0 0 0 16 0 0 (0.000/chip) 13%
5: 848 32.556 34.499 2274 124 0 0 0 16 0 0 (2.035/chip) 31%
6: 848 34.961 37.417 2442 138 1 0 0 16 0 0 (2.185/chip) 32%
7: 848 0.000 0.000 0 0 0 0 0 16 0 0 (0.000/chip) 10%
8: 848 34.145 36.846 2385 124 0 0 0 16 0 0 (2.134/chip) 31%
9: 848 34.474 35.937 2408 67 1 0 0 16 0 0 (2.155/chip) 32%
A: 848 35.290 36.613 2465 47 1 0 0 16 0 0 (2.206/chip) 33%
B: 848 37.767 36.656 2638 9 2 0 0 16 0 0 (2.360/chip) 34%
C: 848 34.832 35.683 2433 14 0 0 0 16 0 0 (2.177/chip) 33%
D: 848 35.691 36.201 2493 3 0 0 0 16 0 0 (2.231/chip) 33%
E: 848 0.000 0.803 0 7788 0 0 6 16 0 0 (0.000/chip) 11%
F: 848 1.689 4.334 118 557 54 125 105 16 0 0 (0.106/chip) 7% look like your last Hboard very bad with i/o error F: 848 1.689 4.334 118 557 54 125 105 16 0 0 (0.106/chip) 7% |
|
|
|
Okay I want to brainstorm my ideas a little bit. Here's what I am going to do. I am thinking of decoupling the voltage regulator from the PCB since it causes so much overheating issues. It will reduce board BOM and hopefully faster turnaround by PCB manufacturer. I am planning to use multiples of this regulator since the output can be paralleled (~$55 e.a.) http://www.intersil.com/en/tools/reference-designs/isl8225meval3z.htmla) Order chips ($25 ea on megabigpower.com) b) Order decoupling capacitors for ASICs c) Get PCB made and assembled by the PCB company (only solder ASIC + decoupling caps. No need to solder voltage regulator section) d) Order Voltage regulators e) Test assembled cards f) Mine g) If successful, sell to interested parties  You'll have no margins for profit if chips are $25 ea. That's $400 for the ASICs alone. And I think it's generally expected when MGP and BFSB started selling H boards again they're going to have to price them at less than $300 per board or they'll generate very little interest. Lets say I do it without any profit margins, just for the community at first. by time you got pcb and chip price for Jan. 2014 like 5.00 per chip. |
|
|
|
It seems I'm getting daily payouts, not 15 minute payouts. I guess I don't understand the full workings of the payout system. Or Slush holds our coins for a certain period... just speculating...?
er my slush account pays out confirmed stuff every 4 coins...as to payout per day I just go by the ave which right now on a Jupiter at 550gh is .49 or some such on slush probably I'm missing the boat on what you mean grats to you and did you get all your miners now or still on BFL waiting list? |
|
|
|
It seems I'm getting daily payouts, not 15 minute payouts. I guess I don't understand the full workings of the payout system. Or Slush holds our coins for a certain period... just speculating...?
paid use to be fast but now no idea why so long now. |
|
|
|
Does anyone know what this means? I'm having to restart bfgminer around every 5-10 minutes.
[2013-11-12 01:14:15] BSB 3cc: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cd: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ce: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cf: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cg: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ch: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ci: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cj: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ck: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cl: bitfury_init_oldbuf: Giving up after 4 tries
you sure not use BGFMINER and not working well with Hboards. |
|
|
|
.stat.log doesn't exist because chainminer isn't working right, not the other way around. Try running chainminer directly like this, to see if it gives any explanation for not working: sudo killall -q miner ; cd /run/shm ; sudo /opt/bitfury/chainminer/miner
Thanks. Turns out I had a few problems; 1) miner was not built. 2) so far 1 bad hboard out of 32. Will get the second rig up-and-running later this evening. 3) Here's the results of getting a rig to work :| Big-ass fan blowing on it... 850W power supply. speed:13568 noncerate[GH/s]:242.265 (0.946/chip) hashrate[GH/s]:263.596 good:16922 errors:7916 spi-err:8 miso-err:27 duplicates:1450 jobs:284 cores:8% good:256 bad:0 off:0 (best[GH/s]:0.000) Mon Nov 11 23:55:21 2013
board-2 speed nrate hrate good errors spi-err miso-er duplic good bad off per chip good cores
0: 848 33.057 35.821 2309 273 1 1 35 16 0 0 (2.066/chip) 17%
1: 848 3.908 4.154 273 137 0 2 23 16 0 0 (0.244/chip) 2%
2: 848 10.279 11.109 718 176 0 1 36 16 0 0 (0.642/chip) 6%
3: 848 4.667 5.570 326 177 0 2 36 16 0 0 (0.292/chip) 3%
4: 848 5.927 6.617 414 179 0 1 61 16 0 0 (0.370/chip) 3%
5: 848 24.882 25.103 1738 354 0 2 37 16 0 0 (1.555/chip) 13%
6: 848 22.763 24.067 1590 319 2 2 61 16 0 0 (1.423/chip) 12%
7: 848 23.107 23.856 1614 365 0 3 82 16 0 0 (1.444/chip) 12%
8: 848 8.891 9.766 621 498 1 1 104 16 0 0 (0.556/chip) 5%
9: 848 13.443 15.072 939 544 0 1 102 16 0 0 (0.840/chip) 7%
A: 848 12.642 14.628 883 668 0 4 137 16 0 0 (0.790/chip) 7%
B: 848 3.923 5.073 274 644 0 2 95 16 0 0 (0.245/chip) 2%
C: 848 8.275 9.861 578 691 2 2 165 16 0 0 (0.517/chip) 5%
D: 848 16.407 18.032 1146 766 0 2 145 16 0 0 (1.025/chip) 9%
E: 848 30.881 33.601 2157 944 0 0 153 16 0 0 (1.930/chip) 16%
F: 848 19.213 21.266 1342 1181 2 1 178 16 0 0 (1.201/chip) 10%Got a long night of troubleshooting ahead Your errors overkill more than 50% and if you are not going to run 850W with 2 full kits. |
|
|
|
I got two full rigs today. One is running at 225 Gh and the other is running at 0 Gh.
Glad to know it's not just me You need to start one at time to check for bad Hboard. |
|
|
|
I got two full rigs today. One is running at 225 Gh and the other is running at 0 Gh.
Glad to know it's not just me here good section to read https://bitcointalk.org/index.php?topic=287590.0 I got 2 Hboards stop working yesterday. ps: did anyone return bad hboards to Dave for replacement and I got 2 Hboards for replacement and need to return bad Hboards to Dave. I am waiting for information to return bad hboard for long time now. |
|
|
|
Tried to compile bfgminer and ran into a wall here:
"Could not find HASH_ITER - please install uthash-dev"
This was near the end when running:
./configure --enable-bfsb
Must've forgotten to include that in the dependencies...my post with the instructions has been updated. Went ahead and tried cgminer and got it to compile, but it could not detect the bitfury (I am on a V1 M-board).
cgminer doesn't support these boards. That said, now that I'm near my mining rig for testing, I'm trying to get bfgminer running stable on it. It runs for a few minutes, getting ~80 GH/s out of my two boards (and another 11 from the BFL hardware also plugged in), but then it starts throwing a bunch of errors in a loop. I think it's trying to drive the chips too hard by default. If I change the oscillator setting for each chip from whatever default bfgminer is picking to 52, the hashrate falls back to ~68 GH/s (close to what chainminer was delivering). So far it's still running as I write this. Looking at the bfgminer source code, we find this in driver-bfsb.c, in bfsb_init(): bitfury_init_chip(proc);
bitfury->osc6_bits = 53;
bitfury_send_reinit(bitfury->spi, bitfury->slot, bitfury->fasync, bitfury->osc6_bits);
bitfury_init_freq_stat(&bitfury->chip_stat, 52, 56);
I think it's starting with 53 and then setting itself to adjust later between 52 and 56. Without heatsinks, though, my rig isn't stable at 53 long enough for this mechanism to kick in, so I'm better off fixing it to run at 52: bitfury_init_chip(proc);
bitfury->osc6_bits = 52;
bitfury_send_reinit(bitfury->spi, bitfury->slot, bitfury->fasync, bitfury->osc6_bits);
bitfury_init_freq_stat(&bitfury->chip_stat, 52, 52);
AFAICT there is no way to set this in bfgminer.conf. You can edit chip speeds at runtime, but the only way to make this setting permanent for now is to edit and recompile the source. Here's a screenshot of bfgminer in action...currently at 10 minutes, and the ASICs are running in the mid-40s according to the temperature probe I have on one of them: I was trying to test run bfgminer for 6 Hboards but not good and I got like 100% HW. |
|
|
|
i was getting overlapping ip addresses. i have my router set on dhcp but i've noticed that altho each raspi is supposed to let itself be assigned a new address each time on connection w/o any overlap from other BF's, some time it does and some times it doesn't.
I have no idea what the motivation was behind using DHCP to find the subnet and then just ignore the result and try grabbing .249 on it. Why not just let DHCP do its job? Any halfway-decent router's web interface will show you what devices are where; finding your rig's IP address is trivial. As shipped, /etc/network/interfaces looks something like this after it's booted up once and found an address: auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.100.249
netmask 255.255.255.0
gateway 192.168.100.1
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
up route add default gw 192.168.100.1 eth0
dns-nameservers 192.168.100.1 8.8.8.8
Something like this will just get out of the way and let DHCP do its job. If you want the rig at a certain IP address, create a DHCP reservation for it. More importantly, this will let DNS do its job so you can refer to the rig by its hostname (which you probably want to set to something sensible with raspi-config, BTW). auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
allow-hotplug wlan0
auto wlan0
#iface wlan0 inet manual
#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
This is for a wired network. For WiFi, follow one of the many guides out there on getting WiFi working on a Raspberry Pi. I think sd image came with most of time 10.x.x.x ip from test run and I think sure change back to to auto DHCP. |
|
|
|
.05 BTC to the guy who helps me reimage 2 corrupt SD cards back to latest Chainminer.
pm me.
i actually have another SD card with a good image on it so it should just be a matter of copying it over.
You better off not use sd for FS but you can usb flash for FS and use work better. |
|
|
|
That did it  ITS WORKING PM me an address and I'll shoot you a tip. Thanks again! Now I'm off to convert this to a BFG bitfury. You were right too - Work settings work but this router has funny defaults in it which it why it wasn't seeming to work. you have to look at /etc/network for file interfaces and you need to change ip in the interfaces file. |
|
|
|
Got mine up and running, but while the web interface indicates 70 GH/s (with two H-boards), BTC Guild is only seeing about 24 GH/s. Last night, I noticed that the locally-indicated hashrate was jumping all around. I have a high-flow 120mm fan blowing across the boards, but don't yet have heatsinks installed. Am I seeing thermal throttling as a result? I have a bunch of heatsinks on order, but it'll be a while before they arrive. Since previous versions were designed to run at a slower rate with just air movement and no heatsinks, is there a temporary adjustment I can make to at least get 40-50 GH/s out of my rig while I'm waiting? You can read more here https://bitcointalk.org/index.php?topic=287590.0 |
|
|
|
I probably have the biggest boner on the forums at this moment in time :| Got shipping notification ! Thanks Dave !!!
Grats and I think you may get it Friday if your miners are shippping out today. |
|
|
|
Yeah so that one board is still bad. Keeps shutting itself off even if I downclock it so the onboard temps are only 30-40C. I guess I'll have to talk to dave about RMAing it. This happens no matter what slot it's in.
Same thing happened to me, chips were cool enough. Turned out that the power regulator was too hot, despite heatsinks (I measured 90°C with IR-Thermometer). I moved the 3 fans from the top to the side of the regulator, which helped a lot. Now my 10 Boards are stable at 345-355 GH/s. Aren't these new H-cards supposed to have trim pots that would allow you to reduce the voltage output of the regulator? The voltage preset at the factory may just be a little too high for your operating environment. This symptom was common with the August H-cards if you "over pencil mod" them. I have yet to receive my Oct kits, but if this were to happen to mine I would try reducing the voltage a little on those cards that were shutting down. Yes, newer Hboard got SMD trim pot on it. |
|
|
|
bad off per chip good cores
0: 848 35.892 37.522 2507 76 4 0 0 16 00 (2.243/chip) 34%
1: 848 36.307 37.491 2536 15 0 0 0 16 00 (2.269/chip) 35%
2: 848 27.431 27.946 1916 134 16 5 2 16 00 (1.714/chip) 30%
4: 848 35.720 36.708 2495 68 2 0 0 16 00 (2.232/chip) 34%
5: 848 37.180 37.152 2597 14 1 0 0 16 00 (2.324/chip) 35%
6: 848 38.898 38.917 2717 8 2 0 0 16 00 (2.431/chip) 36%
8: 848 33.000 34.309 2305 82 4 0 0 16 00 (2.062/chip) 32%
9: 848 33.529 36.698 2342 82 1 0 0 16 00 (2.096/chip) 32%
A: 848 0.000 0.000 0 0 0 0 0 16 00 (0.000/chip) 9% speed down
C: 848 35.648 36.793 2490 16 1 0 0 16 00 (2.228/chip) 34%
So, yeah, I have 1 bad H-board it appears. It throttles down for about 15 minutes and then just goes to 0 GH/s Uh, are these still covered under warranty if I heatsinked the back, Dave? Edit: This is interesting, a second board just did the same thing. :| Your Hboard maybe overheat that why Hboard shutdown and you need better cooling. |
|
|
|
The slots are no longer labeled "A1 A2" etc, rather now they are just 0 1 2 3 .. E F
My bad performing card is in slot 7 and I haven't tried to the other slots out yet
edit: Slot 7 card just died, I will move it to a new slot and see if it hashes any better there
2nd edit: Okay, there ARE banks, they just arent labeled on the PCB. Messing around with trying them in different banks now
Did you use fan on Hboards? |
|
|
|
|
Show Posts
