Search content
Sort by
Showing 20 of 51 results by spegelius
Put a meter on that rig. You'll find that power consumption is dropping off a cliff. Cgminer is tuning out hw errors and chainminner is happily gobbling up power without regard to hw errors. The difference in efficiency is not small.
You can make cgminer behave the same way by just changing the tune up/down values. That's an optional value you can pass directly to cgminer without changing the code.
You can make cgminer behave the same way by just changing the tune up/down values. That's an optional value you can pass directly to cgminer without changing the code.
Hmm, seriously? I'll have to test the power draw. With chainminer it sucks about ~300W on the wall @380GH/s, i haven't tried it with cgminer.
Tuning... somehow that doesn't sound as fun it sounded few months ago
. Oh well, it'll be propably worth it.Yeah cgminer does work with these cards, ive been testing it now and then, but have always returned to chainminer. The reason is that even though the speed looks very good after a while it tunes itself to max speed (385GH/s vs. 420GH/s max speeds, chainminer vs cgminer), after a day or so it goes below chainminer speeds. I guess restarting cgminer daily would fix that, haven't really bothered as chainminer just rolls on on autotune. And cgminer does have some options to tune bitfury cards manually, but currently i just want my rigs to run without constant tuning 
.
.Well got it running @ 350 GH/s stable, with chainminer autotuning. I beefed up the 12V and ground rails beneath the M-board and also now feeding power to the connectors on the other side of the m-board, but don't know how much that actually helped because i needed to do more card switching to get all cards show up.
There's still one card showing only 20GH/s, few chips are almost 0GH/s. That has has been running over 30GH/s before, so there's clearly something still not quite right. I haven't upped the voltage yet, maybe i'll try to see if overvolting the card or cards in the same bank would help.
There's still one card showing only 20GH/s, few chips are almost 0GH/s. That has has been running over 30GH/s before, so there's clearly something still not quite right. I haven't upped the voltage yet, maybe i'll try to see if overvolting the card or cards in the same bank would help.
Yeah thanks for the fast delivery. Unfortunately, the 4 new cards brought more troubles than hashes: i was happily hashing along with 8 cards, getting about 260GH/s but now with 12 cards, i'm riddled with miso and spi errors, and i still get only 260GH/s. I can get the setup to run @ 350 for a while, but then something happens and errors galore.
I've tried switching the cards around and that did help initially (initially i thought two of the new cards were duds), but that didn't last long. The funny thing is that now the cards that were running without problems have started to act up... i even had two slots die on me, i couldn't get any card to show up in those. But after some restarts and card switcheroo, they are alive again. Heh, i knew that these aren't the easiest to get running, but this something else.
Oh well, back to tweaking...
I've tried switching the cards around and that did help initially (initially i thought two of the new cards were duds), but that didn't last long. The funny thing is that now the cards that were running without problems have started to act up... i even had two slots die on me, i couldn't get any card to show up in those. But after some restarts and card switcheroo, they are alive again. Heh, i knew that these aren't the easiest to get running, but this something else.
Oh well, back to tweaking...
The --bab-options will allow it to go higher also.
Mainly the first parameter, the Max speed - it defaults to 55 but will allow up to 57
(but that depends on if your board can handle it that high also)
I set the defaults to match a 'slower' BitFury board so that people who tried it didn't blow anything up without messing with options
I've not actually been able to run it on my 6 board for a while now - so I don't know how well it goes with a lot more boards
(the 6 board setup has been out of my hands for a couple of weeks now)
It may still require some tuning (of the 'Delay' code to get the average down when there are a lot of boards) but until I have a larger board setup to test with, I can't really sort that one out.
Shouldn't be too much longer.
It checks each chip results roughly every 5minutes and then tunes them up or down based on HW% for that 5 min of data.
default is down if >10% HW and up if <1%
I do still have other ideas for tuning (and dealing with dead chips coz they use double or more CPU than a live chip)
Mainly the first parameter, the Max speed - it defaults to 55 but will allow up to 57
(but that depends on if your board can handle it that high also)
I set the defaults to match a 'slower' BitFury board so that people who tried it didn't blow anything up without messing with options
I've not actually been able to run it on my 6 board for a while now - so I don't know how well it goes with a lot more boards
(the 6 board setup has been out of my hands for a couple of weeks now)
It may still require some tuning (of the 'Delay' code to get the average down when there are a lot of boards) but until I have a larger board setup to test with, I can't really sort that one out.
Shouldn't be too much longer.
It checks each chip results roughly every 5minutes and then tunes them up or down based on HW% for that 5 min of data.
default is down if >10% HW and up if <1%
I do still have other ideas for tuning (and dealing with dead chips coz they use double or more CPU than a live chip)
Had to switch to chainminer, the speed was tanking to 220Gh/s with cgminer, occasionally going higher and then back. I'll do more testing when i have more time to concentrate on tuning.
...
Just to confirm, this doesn't support Bitfury v1.2 hcards/mcard combo? Compiled with --enable-bitfury and it doesn't find anything. And no mention in ASIC-README about hcards...
Just to confirm, this doesn't support Bitfury v1.2 hcards/mcard combo? Compiled with --enable-bitfury and it doesn't find anything. And no mention in ASIC-README about hcards...
--enable-bab
Bitfury never supported my writing the software and wouldn't even sell me hardware - so it wasn't until someone sent me a BlackArrowBitfury board that I could write and test a driver for it.
The detection code and work send command is almost the same logic as chainminer - just less bugs
If they've updated the code and not released (i.e. don't want anyone to support their hardware) then yeah my code won't know about the updates
https://github.com/bfsb/chainminer is their code as far as I know ...
Thanks, got it working, doing quite nice, only 10-15GH/s slower than what Bifury's management page says when mining with chainminer. With chainminer i have handtuned the chip speeds. 248GH/s on average (10 hours of runtime) versus 260 - 267 in chainminer. I wonder if manual tuning of those autotune parameters would bring it up.
I'll let this run for a while.
Or that the original design didn't include any temperature sensors anywhere ....
I think it was 2011 when I first brought that one up with then BFL, still companies make the same stupid mistake today ...
p.s. I finally added tuning to cgminer, options to modify the tuning, and the API stats is full of information about each board ... latest changes are in current git.
I fixed more bugs I copied from chainminer also and found an interesting result the boards return that can be ignored and reduce work checking dramatically.
API summary+stats output of my one BA board:
The Paid GH/s there (how much the pool accepts) is 39.5GH/s
I think it was 2011 when I first brought that one up with then BFL, still companies make the same stupid mistake today ...
p.s. I finally added tuning to cgminer, options to modify the tuning, and the API stats is full of information about each board ... latest changes are in current git.
I fixed more bugs I copied from chainminer also and found an interesting result the boards return that can be ignored and reduce work checking dramatically.
API summary+stats output of my one BA board:
Code:
[0] => SUMMARY
[Elapsed] => 176001
[MHS av] => 41505.75
[MHS 5s] => 43373.70
[Found Blocks] => 0
[Getworks] => 20828
[Accepted] => 58864
[Rejected] => 3328
[Hardware Errors] => 46211
[Utility] => 20.07
[Discarded] => 21684
[Stale] => 25
[Get Failures] => 15
[Local Work] => 2768847
[Remote Failures] => 3
[Network Blocks] => 350
[Total MH] => 7305039289.1326
[Work Utility] => 579.83
[Difficulty Accepted] => 1619791.28726888
[Difficulty Rejected] => 57802.70362325
[Difficulty Stale] => 352.00000000
[Best Share] => 808573
[Device Hardware%] => 2.6451
[Device Rejected%] => 3.3985
[Pool Rejected%] => 3.4448
[Pool Stale%] => 0.0210
[Last getwork] => 1391604057
[STATS] => 0
[ID] => BaB0
[Elapsed] => 176001
[Calls] => 0
[Wait] => 0.000000
[Max] => 0.000000
[Min] => 99999999.000000
[Version] => 2
[Chips] => 16
[Boards] => 1
[Banks] => 1
[Chips Per Bank] => 0 16 0 0 0
[Missing Chips Per Bank] => 0 0 0 0 0
[Device Elapsed] => 176003
[History Enabled] => true
[Chip History Limit] => 300
[Nonces 0-15] => 117283 112518 111587 107190 109769 113981 106979 106443 107113 112412 106065 106157 114316 106283 104793 104409
[Good 0-15] => 111519 106752 109167 105769 108942 109436 103353 105949 106447 104870 105433 105540 109630 104876 101620 101544
[Bad 0-15] => 5749 5751 2405 1406 812 4530 3611 479 651 7527 617 602 4671 1392 3158 2850
[Conf 0-15] => 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b
[Fast 0-15] => 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
[Spie 0-15] => 14 8 12 8 9 10 12 7 13 14 11 10 83 73 70 58
[Miso 0-15] => 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[HW% 0-15] => 4.902 5.112 2.156 1.312 0.740 3.975 3.376 0.450 0.608 6.697 0.582 0.567 4.087 1.310 3.014 2.730
[GHs 0-15] => 2.721 2.605 2.664 2.581 2.658 2.671 2.522 2.585 2.598 2.559 2.573 2.575 2.675 2.559 2.480 2.478
[Sum GHs 0-15] => 41.506
[Cont-Bad 0-15] => 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[Max-Bad 0-15] => 4 5 3 5 3 4 4 4 4 4 4 3 8 6 5 5
[History Good 0-15] => 179 175 227 186 174 195 185 194 170 192 176 184 193 174 167 167
[History Bad 0-15] => 13 18 3 4 0 10 9 0 3 15 1 0 8 0 3 5
[History HW% 0-15] => 6.771 9.326 1.304 2.105 0.000 4.878 4.639 0.000 1.734 7.246 0.565 0.000 3.980 0.000 1.765 2.907
[History GHs 0-15] => 2.600 2.506 3.244 2.693 2.501 2.785 2.641 2.770 2.434 2.751 2.521 2.627 2.775 2.492 2.383 2.383
[Sum History GHs 0-15] => 42.105
[Total History GHs] => 42.105
[Total History HW%] => 3.036
[History Speed 0.0 Dead] => 0
[History Speed 0.8 V.Slow] => 0
[History Speed 1.6 Slow] => 0
[History Speed 2.2 OK] => 0
[History Speed 2.8 Good] => 15
[History Speed >2.8 Fast] => 1
[History Dead] => None
[History V.Slow] => None
[History Dead Boards] => None
[History Dead Chains] => None
[Nonce Offset 0xff800000] => 890671
[Nonce Offset 0x00000000] => 566858
[Nonce Offset 0xffc00000] => 243318
[Discarded E0s] => 2728775
[Tested] => 1747298
[OK] => 1700847
[Total Tests] => 8977596
[Max Tests] => 16
[Avg Tests] => 5.278
[Untested] => 0
[Work Links] => 3676660
[Work Processed Links] => 3613284
[Max Links] => 8
[Max Processed Links] => 7
[Total Work Links] => 6358964
[Avg Links] => 2.162
[Avg Proc Links] => 2.124
[Avg Work Links] => 3.739
[Fail] => 46211
[Fail Total Tests] => 405639
[Fail Avg Tests] => 8.778
[Fail Work Links] => 173878
[Fail Total Work Links] => 173878
[Initial Ignored] => 240
[Ign Total Tests] => 471
[Ign Work Links] => 0
[Ign Total Work Links] => 0
[WFree Total] => 1024
[WFree Count] => 943
[Available Work] => 16
[SPI Work] => 0
[Chip Work] => 65
[SFree Total] => 8
[SFree Count] => 8
[SPI Waiting] => 0
[SPI Sent] => 0
[RFree Total] => 256
[RFree Count] => 256
[Result Count] => 0
[NFree Total] => 102400
[NFree Used] => 3030
[Delay Count] => 170550
[Delay Min] => 0.899001
[Delay Max] => 5.202787
[Delay Bands] => <0.5=0 <0.7=0 <0.9=5828 <1.1=164717 <1.3=2 <1.5=0 <1.7=0 <1.9=0 <2.1=0 <2.3=0 <2.5=0 >=2.7=3
[Send Count] => 170551
[Send Total] => 14938.829633
[Send Avg] => 0.088
[Send Min] => 0.085179
[Send Max] => 0.113610
[Reply Wait] => 160
[Reply Waits] => 5303
[MaxSpeed] => 55
[DefaultSpeed] => 54
[MinSpeed] => 52
[TuneUp] => 1.000000
[TuneDown] => 10.000000
[SPISpeed] => 96000
[SPIDelayuS] => 0
[TransferDelayuS] => 0
[USB Pipe] => 0
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 0 0
[Elapsed] => 176001
[MHS av] => 41505.75
[MHS 5s] => 43373.70
[Found Blocks] => 0
[Getworks] => 20828
[Accepted] => 58864
[Rejected] => 3328
[Hardware Errors] => 46211
[Utility] => 20.07
[Discarded] => 21684
[Stale] => 25
[Get Failures] => 15
[Local Work] => 2768847
[Remote Failures] => 3
[Network Blocks] => 350
[Total MH] => 7305039289.1326
[Work Utility] => 579.83
[Difficulty Accepted] => 1619791.28726888
[Difficulty Rejected] => 57802.70362325
[Difficulty Stale] => 352.00000000
[Best Share] => 808573
[Device Hardware%] => 2.6451
[Device Rejected%] => 3.3985
[Pool Rejected%] => 3.4448
[Pool Stale%] => 0.0210
[Last getwork] => 1391604057
[STATS] => 0
[ID] => BaB0
[Elapsed] => 176001
[Calls] => 0
[Wait] => 0.000000
[Max] => 0.000000
[Min] => 99999999.000000
[Version] => 2
[Chips] => 16
[Boards] => 1
[Banks] => 1
[Chips Per Bank] => 0 16 0 0 0
[Missing Chips Per Bank] => 0 0 0 0 0
[Device Elapsed] => 176003
[History Enabled] => true
[Chip History Limit] => 300
[Nonces 0-15] => 117283 112518 111587 107190 109769 113981 106979 106443 107113 112412 106065 106157 114316 106283 104793 104409
[Good 0-15] => 111519 106752 109167 105769 108942 109436 103353 105949 106447 104870 105433 105540 109630 104876 101620 101544
[Bad 0-15] => 5749 5751 2405 1406 812 4530 3611 479 651 7527 617 602 4671 1392 3158 2850
[Conf 0-15] => 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b
[Fast 0-15] => 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
[Spie 0-15] => 14 8 12 8 9 10 12 7 13 14 11 10 83 73 70 58
[Miso 0-15] => 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[HW% 0-15] => 4.902 5.112 2.156 1.312 0.740 3.975 3.376 0.450 0.608 6.697 0.582 0.567 4.087 1.310 3.014 2.730
[GHs 0-15] => 2.721 2.605 2.664 2.581 2.658 2.671 2.522 2.585 2.598 2.559 2.573 2.575 2.675 2.559 2.480 2.478
[Sum GHs 0-15] => 41.506
[Cont-Bad 0-15] => 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[Max-Bad 0-15] => 4 5 3 5 3 4 4 4 4 4 4 3 8 6 5 5
[History Good 0-15] => 179 175 227 186 174 195 185 194 170 192 176 184 193 174 167 167
[History Bad 0-15] => 13 18 3 4 0 10 9 0 3 15 1 0 8 0 3 5
[History HW% 0-15] => 6.771 9.326 1.304 2.105 0.000 4.878 4.639 0.000 1.734 7.246 0.565 0.000 3.980 0.000 1.765 2.907
[History GHs 0-15] => 2.600 2.506 3.244 2.693 2.501 2.785 2.641 2.770 2.434 2.751 2.521 2.627 2.775 2.492 2.383 2.383
[Sum History GHs 0-15] => 42.105
[Total History GHs] => 42.105
[Total History HW%] => 3.036
[History Speed 0.0 Dead] => 0
[History Speed 0.8 V.Slow] => 0
[History Speed 1.6 Slow] => 0
[History Speed 2.2 OK] => 0
[History Speed 2.8 Good] => 15
[History Speed >2.8 Fast] => 1
[History Dead] => None
[History V.Slow] => None
[History Dead Boards] => None
[History Dead Chains] => None
[Nonce Offset 0xff800000] => 890671
[Nonce Offset 0x00000000] => 566858
[Nonce Offset 0xffc00000] => 243318
[Discarded E0s] => 2728775
[Tested] => 1747298
[OK] => 1700847
[Total Tests] => 8977596
[Max Tests] => 16
[Avg Tests] => 5.278
[Untested] => 0
[Work Links] => 3676660
[Work Processed Links] => 3613284
[Max Links] => 8
[Max Processed Links] => 7
[Total Work Links] => 6358964
[Avg Links] => 2.162
[Avg Proc Links] => 2.124
[Avg Work Links] => 3.739
[Fail] => 46211
[Fail Total Tests] => 405639
[Fail Avg Tests] => 8.778
[Fail Work Links] => 173878
[Fail Total Work Links] => 173878
[Initial Ignored] => 240
[Ign Total Tests] => 471
[Ign Work Links] => 0
[Ign Total Work Links] => 0
[WFree Total] => 1024
[WFree Count] => 943
[Available Work] => 16
[SPI Work] => 0
[Chip Work] => 65
[SFree Total] => 8
[SFree Count] => 8
[SPI Waiting] => 0
[SPI Sent] => 0
[RFree Total] => 256
[RFree Count] => 256
[Result Count] => 0
[NFree Total] => 102400
[NFree Used] => 3030
[Delay Count] => 170550
[Delay Min] => 0.899001
[Delay Max] => 5.202787
[Delay Bands] => <0.5=0 <0.7=0 <0.9=5828 <1.1=164717 <1.3=2 <1.5=0 <1.7=0 <1.9=0 <2.1=0 <2.3=0 <2.5=0 >=2.7=3
[Send Count] => 170551
[Send Total] => 14938.829633
[Send Avg] => 0.088
[Send Min] => 0.085179
[Send Max] => 0.113610
[Reply Wait] => 160
[Reply Waits] => 5303
[MaxSpeed] => 55
[DefaultSpeed] => 54
[MinSpeed] => 52
[TuneUp] => 1.000000
[TuneDown] => 10.000000
[SPISpeed] => 96000
[SPIDelayuS] => 0
[TransferDelayuS] => 0
[USB Pipe] => 0
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 0 0
The Paid GH/s there (how much the pool accepts) is 39.5GH/s
Just to confirm, this doesn't support Bitfury v1.2 hcards/mcard combo? Compiled with --enable-bitfury and it doesn't find anything. And no mention in ASIC-README about hcards...
I implemented the pool switching using API and it seems to work very well, been running @159GH/s for a few hours now.
I also tried to use BFGMiner as getwork proxy for chainminer, but for some reason BFGMiner sees most of the shares as HW errors, only few get accepted. Dunno what's with that...
I tried to tune the scan delay multiplier and shift value, but they seems to be optimal already. When i set the shift value to 0x200000 (from default 0x1200000), speed sank about 5% or so... Currently running with all chips on speed 55, which seems to be 8GH/s better than the settings i use with chainminer.
I also tried to use BFGMiner as getwork proxy for chainminer, but for some reason BFGMiner sees most of the shares as HW errors, only few get accepted. Dunno what's with that...
I tried to tune the scan delay multiplier and shift value, but they seems to be optimal already. When i set the shift value to 0x200000 (from default 0x1200000), speed sank about 5% or so... Currently running with all chips on speed 55, which seems to be 8GH/s better than the settings i use with chainminer.
I have heatsinks at the backs of the hcards and 3 12cm fans blowing, they shouldn't be too hot.
I use API to shut cgminer down, but i've seen cgminer hang randomly so it is possbile that the last stage kill -9 might shut it down wrong way...
Good all with API, i'll have to implement that later this week or weekend. For now i'll stick with stratum proxy and pools that work well with it (namely pools that allow manual difficulty setting for miners).
I use API to shut cgminer down, but i've seen cgminer hang randomly so it is possbile that the last stage kill -9 might shut it down wrong way...
Good all with API, i'll have to implement that later this week or weekend. For now i'll stick with stratum proxy and pools that work well with it (namely pools that allow manual difficulty setting for miners).
Thanks for the tip
If you get to much hw errors on some chips - you may need to fine tune the scan delay multiplier in driver-bitfury.c (line 210 - between 900 and 1200) and the shift value in libbitfury.c (line 631 - between 0x100000 and 0x200000) ... I think I got them right, but they may be for my specific hardware configuration
EDIT: for per chip info check:
If you get to much hw errors on some chips - you may need to fine tune the scan delay multiplier in driver-bitfury.c (line 210 - between 900 and 1200) and the shift value in libbitfury.c (line 631 - between 0x100000 and 0x200000) ... I think I got them right, but they may be for my specific hardware configuration
EDIT: for per chip info check:
Code:
php api-example.php stats | grep -v 'stats returned' | egrep -e chip -e work -e hw -e gh -e mhz -e clock
if for some of the chips it shows different MHz on each run you will need to tweak those values aboveI'll do some testing later. However, there was some problems with the cgminer. First, i'm running a multimining setup, which means i poll for most profitable coin from coinchoose or coinwarz and then switch miners to mine that coin. Not sure if this gives any advantage nowadays, but been tweaking it for some time. With stratum proxy this works fine, as chainminer is running uninterrupted, only the proxy is restarted. Or course there's some rejected shares when switching coins, but from chainminer's side it's mostly business as usual.
Now enter cgminer; restarting it means first shutting down the chips and then finding them again and reinitializing. This seems to crap out at some point and chips aren't found anymore. It got to a point where there was only one chip found for first board. So i shut down cgminer and fired up chainminer/stratum-proxy with previous best.cnf. Not going well, first and second boards were way below normal speeds, some chips showed only error results and speed was 0.0GH/s. Only after deleting best.cnf and /run/shm/.chip.cnf, i.e. allowing chainminer to autotune speeds, i got all boards running fine. Phew, thought i had blown something for a minute...
Anyways, some ideas what might have happened:
* constant reinitialization crapped spi or chips or something...
* this resulted some chips left in a bad state; telling them to run at the 55 speed wasn't resetting them properly
* only after setting all chips to 54 (apparently chainminer does this in autotune mode) the chips were revived and now back to hashing at previous speeds
* or could it simply be that running constantly with too high speed finally craps the chips for some reason?
So with cgminer something like first setting the speed to 54 (or maybe 50?) and only after that tuning them to full speed might keep them working properly?
Great, thanks. Going to leave this running for the night and see how it goes.
Also sent a small tip for your troubles.
Edit: now that i set the chip speeds as per best.cnf, i only get to 151GH/s. Oh well, just gonna run with 55 on all chips for now.
Also sent a small tip for your troubles.
Edit: now that i set the chip speeds as per best.cnf, i only get to 151GH/s. Oh well, just gonna run with 55 on all chips for now.
Ah ok, i'll check the api. Btw, running at about 158.4GH/s average, using --bitfury-clockbits 55. This is right around the ballpark with chainminer and definite improvement to stratum-proxy/chainminer combo due to problems with some pools and difficulty. Great
Looking at the --bitfury-clockbits code, the slot (or bank) is needed also, as in api call, so the arg format should be like bank:chip:speed.
Looking at the --bitfury-clockbits code, the slot (or bank) is needed also, as in api call, so the arg format should be like bank:chip:speed.
There are few things you need to change for BFSB hardware:
in bitfury-config.h
Then in tm_i2c.c you need to comment out (ore remove) the line
in bitfury-config.h
Code:
#define BITFURY_MAXBANKS 8
#define BITFURY_BANKCHIPS 14
should be #define BITFURY_BANKCHIPS 14
Code:
#define BITFURY_MAXBANKS 4
#define BITFURY_BANKCHIPS 64
as there are 4 banks of 4 boards, each with 16 chips#define BITFURY_BANKCHIPS 64
Then in tm_i2c.c you need to comment out (ore remove) the line
Code:
#define BF_OE_ACTIVE_LOW
and to change the bank definitions (bf_bank_gpio) to the ones for BFSB i.e.Code:
static const int bf_bank_gpio[BITFURY_MAXBANKS] = {18,23,24,25};
Allright, now it's working, thanks. Speed average 151 GH/s with the default chip speed of
Also i got the segfault by trying to set --bitfury-clockbits 0:55,1:55,2:55... etc. Seems the arg parsing fails? I do have ulimit set to unlimited, but all i get is this:
Code:
[2013-12-29 20:16:06] BITFURY slot: 3, chip #69 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #70 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #71 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #72 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #73 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #74 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #75 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #76 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #77 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #78 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #79 detected
[2013-12-29 20:16:06] BITFURY: 80 chips detected!
[2013-12-29 20:16:06] Probing for an alive pool
[2013-12-29 20:16:07] Pool 0 difficulty changed to 512
[2013-12-29 20:16:08] Pool 0 difficulty changed to 64
/home/pi/bin/_cgminer: line 30: 18301 Segmentation fault ${CGMINERBIN} $PARAMS $1 $2 $3 $4 $5 $6 $7 $8 $9
[2013-12-29 20:16:06] BITFURY slot: 3, chip #70 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #71 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #72 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #73 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #74 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #75 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #76 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #77 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #78 detected
[2013-12-29 20:16:06] BITFURY slot: 3, chip #79 detected
[2013-12-29 20:16:06] BITFURY: 80 chips detected!
[2013-12-29 20:16:06] Probing for an alive pool
[2013-12-29 20:16:07] Pool 0 difficulty changed to 512
[2013-12-29 20:16:08] Pool 0 difficulty changed to 64
/home/pi/bin/_cgminer: line 30: 18301 Segmentation fault ${CGMINERBIN} $PARAMS $1 $2 $3 $4 $5 $6 $7 $8 $9
I'm running cgminer through shell scripts, should i run it directly to get the coredump?
Hmm, no segfaults anymore, but still not all chips there. Also it seems that i need to start and stop chainminer before running cgminer to get it finding even those few chips. And those few chips produce only invalid nonces it seems.
Pastebin of the output: http://pastebin.com/Cp7jSjeJ
The code i built is from github and i haven't modified it. BITFURY_MUX_OE is not defined. No parameters in commandline, except url and --no-submit-stale
edit: oh and running BFGMner for and hour or so resulted total speeds 170/160/149 or so. The last number was quite well in line with ghash.io's speed.
With anjavi's cgminer it is possible to set speeds per chip. But even with the same clockbits as in best.cnf, the speed is something like 20 - 30 ghs lower than chainminer.
Pastebin of the output: http://pastebin.com/Cp7jSjeJ
The code i built is from github and i haven't modified it. BITFURY_MUX_OE is not defined. No parameters in commandline, except url and --no-submit-stale
edit: oh and running BFGMner for and hour or so resulted total speeds 170/160/149 or so. The last number was quite well in line with ghash.io's speed.
With anjavi's cgminer it is possible to set speeds per chip. But even with the same clockbits as in best.cnf, the speed is something like 20 - 30 ghs lower than chainminer.
Has anyone done any tweaking to BFGMiner or those cgminer forks regarding bitfury? I've tried both Anajavis's fork of cgminer, which gives about 10-20% lower speed vs. chainminer and KNK's fork, which doesn't work for me (randomly finds maybe 1 or 2 chips or segfaults).
With chainminer/stratum proxy i get ~160GH/s (5 hcards, hand tweaked best.cnf)
I also tried latest BFGMiner from github, which initially gives same speed as Anajavi's cgminer, but after tweaking some parameters i can get to about 5-1% distance from chainminer's speeds (at least if the pool speed indication is to be trusted). BFGMiner states 166/150/138 with latest tweaks.
The tweaks i made are:
- limit the maximum chip speed to 56 as only few of my chips can handle even that speed
- changed the starting speed from 50 to 54 and now tried 47 (to help the few weak chips limp along...). 54 seemed to produce best results
I had a look at the BFGMiner's bitfury code and at a quick glance it feels that the autotuning is making the speed go up and down too much maybe? Same is with chainminer, i suppose... is there a way to feed your own static chip speeds, as in best.cnf to BFGMiner?
With chainminer/stratum proxy i get ~160GH/s (5 hcards, hand tweaked best.cnf)
I also tried latest BFGMiner from github, which initially gives same speed as Anajavi's cgminer, but after tweaking some parameters i can get to about 5-1% distance from chainminer's speeds (at least if the pool speed indication is to be trusted). BFGMiner states 166/150/138 with latest tweaks.
The tweaks i made are:
- limit the maximum chip speed to 56 as only few of my chips can handle even that speed
- changed the starting speed from 50 to 54 and now tried 47 (to help the few weak chips limp along...). 54 seemed to produce best results
I had a look at the BFGMiner's bitfury code and at a quick glance it feels that the autotuning is making the speed go up and down too much maybe? Same is with chainminer, i suppose... is there a way to feed your own static chip speeds, as in best.cnf to BFGMiner?
I mine PPC occasionally, i have automated the switching of coins based on profitability info from web. Pool i use is https://bitcointalk.org/index.php?topic=173272.0 which works fine.
Can you tell me how you setup this automated switching?
CryptoSwitcher will do that for you...had it running when I just had BFL miners, but it should work with these just as well. The only snag is that other sha256d coins usually won't make that much more than Bitcoin (right now, PPCoin will net you 18% more than Bitcoin, but that's before you exchange it).
Yeah, i found that software after i had written my own. It usually goes like this, if i get an idea about something that would be nice, someone has already thought about it and propably implemented it
. Well it wasn't complete waste of time, learned Python3 doing it and it works. If only i had more time to implement some nice guis for monitoring miner speeds, current pools and editing configs...Just checked, i have -rt when mining to D7 pool. For me it works nicely, D7 shows the hash rate at 150-160 Gh/s (5 hboards, Bitfury management shows about 160-167).
I have stratum proxy set up to restart in 15 minute intervals, not sure if that has anything to do with this... no automatic restart for chainminer, even though i think it would be good to set that up too.
speed:4276 noncerate[GH/s]:162.393 (2.030/chip) hashrate[GH/s]:184.398 good:11343 errors:1148 spi-errors:0 miso-errors:0 jobs:291 (record[GH/s]:167.933)
0: 811 32.312 34.626 2257 109 0 0
4: 821 30.838 36.064 2154 321 0 0
5: 888 33.186 39.911 2318 414 0 0
8: 883 34.861 39.604 2435 208 0 0
C: 873 31.196 34.193 2179 96 0 0
Hmm, seems it might be good idea to do some finetuning again, more errors than last check a week back.
I have stratum proxy set up to restart in 15 minute intervals, not sure if that has anything to do with this... no automatic restart for chainminer, even though i think it would be good to set that up too.
speed:4276 noncerate[GH/s]:162.393 (2.030/chip) hashrate[GH/s]:184.398 good:11343 errors:1148 spi-errors:0 miso-errors:0 jobs:291 (record[GH/s]:167.933)
0: 811 32.312 34.626 2257 109 0 0
4: 821 30.838 36.064 2154 321 0 0
5: 888 33.186 39.911 2318 414 0 0
8: 883 34.861 39.604 2435 208 0 0
C: 873 31.196 34.193 2179 96 0 0
Hmm, seems it might be good idea to do some finetuning again, more errors than last check a week back.
anyone mine ppc? I am trying to mined ppc get alot of errors
speed:5272 noncerate[GH/s]:109.293 (1.138/chip) hashrate[GH/s]:29.563 good:7634 errors:3164 spi-errors:0 miso-errors:34 jobs:57 (record[GH/s]:0.000)
0: 878 17.194 4.947 1201 648 0 7
1: 878 18.898 4.957 1320 521 0 11
2: 877 19.370 5.052 1353 502 0 5
3: 878 17.495 4.883 1222 530 0 5
4: 880 19.127 5.031 1336 476 0 3
5: 881 17.209 4.693 1202 487 0 3
work fined for btc.
speed:5272 noncerate[GH/s]:109.293 (1.138/chip) hashrate[GH/s]:29.563 good:7634 errors:3164 spi-errors:0 miso-errors:34 jobs:57 (record[GH/s]:0.000)
0: 878 17.194 4.947 1201 648 0 7
1: 878 18.898 4.957 1320 521 0 11
2: 877 19.370 5.052 1353 502 0 5
3: 878 17.495 4.883 1222 530 0 5
4: 880 19.127 5.031 1336 476 0 3
5: 881 17.209 4.693 1202 487 0 3
work fined for btc.
I mine PPC occasionally, i have automated the switching of coins based on profitability info from web. Pool i use is https://bitcointalk.org/index.php?topic=173272.0 which works fine.
With bitfury it seems that what pool you are using means alot; with some pools, you need to remove the -rt from stratum proxy's command line. Also when selecting the pool, it's a good idea to select pools where you can manually set the desired difficulty. With pools that select difficulty automatically i've seen that sometimes the difficulty drops too low and then .putstat shows a lot of requests queued, and performance tanks...
Re: [ANN] Technobit 40 GH/s HEX16B(Bitfury ) 462.00 EUR now shipping
With 880mV i get a little over 42GH/s. Doesn't seem to get too hot on any part, which is nice. I suppose the --hexminer-option is like 16:540? I'll tune it more tomorrow, for now i'l just let it mine.
Yes that is correct. Try it with 900 mV if you want of course for 45 gh900mV and freq 540 got me nearly 47GH/s
.I wish my original Bitfury H-boards would go this far, but the regulator is not up to the task. One does over 40G with 0.84V but speed tanks soon when regulator overloads...