Those of us who are running both Bitburner XX boards and Bitburner Fury boards might be interested in a new option in cgminer 3.6.6 that allows you to mine with both types of board in a single cgminer instance, and set different avalon-options for the XX and Fury boards. See https://bitcointalk.org/index.php?topic=294735.msg3415231#msg3415231 for details. |
|
|
|
Those of us who are running both Bitburner XX boards and Bitburner Fury boards might be interested in a new option in cgminer 3.6.6 that allows you to mine with both types of board in a single cgminer instance, and set different avalon-options for the XX and Fury boards. Prerequisites: Assuming you're running with BBF firmware in your Fury boards, all you need to do is set avalon-options for your XX boards and bitburner-fury-options for your Fury boards. That's it! I have a two board stack of each kind of board, and I mine with something like the following: --avalon-options 115200:4:10:d:431 --bitburner-voltage 1300 --bitburner-fury-options 115200:32:10:d:265 --bitburner-fury-voltage 1030
Hopefully this is useful to someone else roy |
|
|
|
New v3.6.5 doesn't work for me, after start it hangs "forever" here: [2013-10-26 09:36:34] Started cgminer 3.6.5 When starting with "-D" it will get me the same result - cgminer hangs just printing the above line. When shutting down with "Ctrl-C" it prints this: [2013-10-26 09:37:54] BF1 looking for BF1 03eb:204b but found 1d6b:0001 instead
[2013-10-26 09:37:54] USB scan devices: checking for AVA devices
[2013-10-26 09:37:55] AVA looking for BTB 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for BBF 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for AVA 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for BTB 0403:6001 but found 1d6b:0002 instead
[2013-10-26 09:37:55] AVA looking for BBF 0403:6001 but found 1d6b:0002 instead
[2013-10-26 09:37:55] AVA looking for AVA 0403:6001 but found 1d6b:0002 instead
[2013-10-26 09:37:55] AVA looking for BTB 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for BBF 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for AVA 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for BTB 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for BBF 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for AVA 0403:6001 but found 1d6b:0001 instead
[2013-10-26 09:37:55] AVA looking for BTB 0403:6001 but found 152d:2336 instead
[2013-10-26 09:37:55] AVA looking for BBF 0403:6001 but found 152d:2336 instead
[2013-10-26 09:37:55] AVA looking for AVA 0403:6001 but found 152d:2336 instead
[2013-10-26 09:37:55] AVA looking for BTB 0403:6001 but found 1d6b:0002 instead
[2013-10-26 09:37:55] AVA looking for BBF 0403:6001 but found 1d6b:0002 instead
[2013-10-26 09:37:55] AVA looking for AVA 0403:6001 but found 1d6b:0002 instead
[2013-10-26 09:37:55] AVA looking for and found BTB 0403:6001
[2013-10-26 09:37:55] USB lock avalon 4-32
[2013-10-26 09:37:55] RES: avalon (4:32) lock=1
[2013-10-26 09:37:55] USB res lock avalon 4-32
[2013-10-26 09:37:55] RES: avalon (4:32) lock ok=1
[2013-10-26 09:37:55] USB init - BTB device 4:32 usbver=0200 prod='BitBurner' manuf='Burnin Electronics' serial='855'
[2013-10-26 09:37:55] BTB0: reset got err 0
[2013-10-26 09:37:55] BTB0: latency got err 0
[2013-10-26 09:37:55] BTB0: data got err 0
[2013-10-26 09:37:55] BTB0: setbaud got err 0
[2013-10-26 09:37:55] BTB0: setmodemctrl got err 0
[2013-10-26 09:37:55] BTB0: setflowctrl got err 0
[2013-10-26 09:37:55] BTB0: setmodemctrl 2 got err 0
[2013-10-26 09:37:55] BTB0: setflowctrl 2 got err 0
[2013-10-26 09:38:34] Shutdown signal received. With v3.4.3 or v3.6.4 I don't have this issue. Pontius - what Avalon/Bitburner devices are you mining with? What command line arguments are you using? |
|
|
|
Adjusting the voltage to 950 has yielded roughly 52Ghash for the pair (26Ghash each). The settings I'm using now are ->
--avalon-options 115200:32:10:d:256 --avalon-fan 100 --bitburner-fury-voltage 950
Insofar as are both boards hashing I believe they are. The board that is USB attached has all LEDs feverishly blinking and the second board that is CAN-BUS attached has the green led blinking regularly, then the yellow led blink, blink, blink and then a bit after that the red led blinks feverishly and then back to the green led blinking by itself (lather, rinse, repeat). I think I got boards with chips from the "special needs" bin.
H@shKraker
You should see a similar patern of blinking lights on both boards. Sounds like there's either a problem with the second board or a problem with communication between the boards. Sounds like your first board is exceptionally good (if you say it will go up to 64GH/s) and your second board is not hashing. roy |
|
|
|
Yeppers. Now running with -> --avalon-options 115200:32:10:d:256 --avalon-fan 100 --bitburner-fury-voltage 900 That has thus far yielded 47.19Ghash (that's roughly 23.6Ghash per board).  H@shKraker Did you power cycle the boards? Are you getting activity on the red LED on both boards? If you don't see activity on the red LED then it's not hashing. roy |
|
|
|
Only thing they appear to have over Dwolla is that they take plastic (with roughly the same fee as Paypal), which makes it irrelevant since Paypal is generally used in conjunction with Dwolla, instead of Dwolla being the only choice. For mobile payments, at least in the US, this is taken care of with direct billing on cell charges (though most [all?] app stores have their own payment processor, too] - so I can't think of a market they're filling there. Unlike Bitcoin, Venmo has many direct competitors they don't offer something significant over. Dwolla's obscure -- why will Venmo be any different?
What is the advantage of Dwolla over Paypal, then? (The disadvantage of Dwolla, of course, is that 96% of the world can't use it - but just curious as to what the advantage is for those of you who can.) |
|
|
|
How to predict crash in bitcoin price or any bubble in general? It's not all random and some guys seem to guess right when that happen. Any tips or insights?
It's a game of poker. It's psychology - you have to guess when everyone else will start selling. But there's no way to know what everyone else is thinking. And since by that point everyone knows it's a bubble, sentiment can change very rapidly - once people think the bubble is bursting, they try to get out with their profits, making the crash a self-fulfilling prophesy. Judging when a bubble will burst is notoriously difficult, and requires a lot of luck - for each person who guessed right there will be a dozen who guessed wrong. roy |
|
|
|
Another thing is that the second board also got as warm as the first. If it weren't hashing wouldn't it be noticeably cooler?
H@shKraker
Spending some time tuning my frequency and voltage this evening, I found it's easy to get a board into a bad state by excessive overclocking and/or excessive overvolting (and you're doing both to the extreme). Once it gets in this state, I see exactly what you do.... the board will not hash (yellow light flashes but no activity on the red light) until it is power-cycled. I'd suggest that to start with, you don't overclock or overvolt at all. Use a frequency of 256 and a core voltage of 900mV and see how you get on. Even that should give you a higher hash rate then you're getting at the moment. Then, once you've got it stable, gradually increase the frequency. You might not be able to go much above 265. Overvolt the minimum necessary to get hardware errors down to an acceptably low level (I have to overvolt even at 256). Also, I find you need to leave it running for an hour or so to get a realistic picture of what's going on, as the hw error rate starts off high and then drops. |
|
|
|
What voltage do you use for 275? I mine at 265 with 980 and i get 48GH/s per board with very low hw errors.
Oh, maybe I need to experiment a bit more then. I'm using 1050mV - I'll try your parameters. It seems mine need more voltage than yours to get the HW error rate down. I need more than 900mV even at 256MHz. But you're right, 265 works better than 275 for me, too. Although I still need around 1050mV to make it work well. Edit: I can't seem to find the right voltage for 270. I get the same performance as 265 with many voltage settings.
I'm coming to the conclusion that unless you're very lucky, 265 is probably about the limit. Above that there's no performance increase for me, and it just consumes more power and gives more hw errros. |
|
|
|
Anyone tried undervolting the chips?
Edit: I can't seem to find the right voltage for 270. I get the same performance as 265 with many voltage settings.
Haven't tried with the latest firmware, but neither undervolting nor underclocking seemed possible when I tried it. Which is a bit disappointing - I hope the boards will gain this feature as it will extend their usable life significantly. |
|
|
|
Would it be possible to make it listen to "--bitburner-fury-options" instead of the --avalon-options parameter? That would make it possible to run both Bitburner XX and Bitburner Fury devices in 1 CGminer window.
I have a cgminer fork here that supports --bitburner-fury-options https://github.com/roybadami/cgminerFor backwards compatibility the Bitburner Fury boards will continue to respect --avalon-options if the new option isn't specified. I'll submit a pull request in a while, but would be good if someone other than me were to test this. I'm currently mining with a stack of two Bitburner XX boards and a stack of two Bitburner Fury boards using the following options: cgminer --avalon-options 115200:4:10:d:431 --bitburner-voltage 1300
--bitburner-fury-options 115200:32:10:d:275 --bitburner-fury-voltage 1050
--avalon-cutoff 62
: For this to be useful you need to be running one of the new BBF firmware versions on your Fury boards. This also means you need to specify the true core voltage for the Bitburner Fury boards - see my post here: https://bitcointalk.org/index.php?topic=294735.msg3364756#msg3364756I've submited the changes back to cgminer, so with any luck this option might get into official builds soon: https://github.com/ckolivas/cgminer/pull/509 |
|
|
|
What voltage do you use for 275? I mine at 265 with 980 and i get 48GH/s per board with very low hw errors.
Oh, maybe I need to experiment a bit more then. I'm using 1050mV - I'll try your parameters. roy |
|
|
|
Another thing is that the second board also got as warm as the first. If it weren't hashing wouldn't it be noticeably cooler?
H@shKraker
Another thought: no one else has managed to get a single board to hash anywhere near 64GH/s - mine hash at about 46GH/s but some people get slightly more, some slightly less. In the unlikely event that you were lucky enough to get one board that hashes at 64GH/s, it's still highly unlikely that your second board can hash at anywhere near the speed. I've had boards stop hashing until I power cycled them if I tried to push them way faster than they were capable. Try reducing your clock speed and your second board might mine. ETA: I see you posted your cgminer options. A frequency setting of 290 is pretty high. Start at 256 and work up from there - I mine at 275 but everyone's boards are different. |
|
|
|
I could see what looked like the second board hashing due to the regularly blinking yellow / orange LED
If the board is hashing you should see activity on the red light too. Oh, you did install terminator jumpers on both your boards, as per the instructions? Both ends of the CANBUS need termination (in a two board setup that means both boards). Neither my Bitburner XX nor Bitburner Fury boards came with the required jumpers - my two-board Fury setup only had jumpers installed on one of the boards, and my two-board Bitburner XX setup didn't come with jumpers at all. So you may need to go and find some jumpers, if your boards didn't ship with them. roy |
|
|
|
I could see what looked like the second board hashing due to the regularly blinking yellow / orange LED
If the board is hashing you should see activity on the red light too. |
|
|
|
Would it be possible to make it listen to "--bitburner-fury-options" instead of the --avalon-options parameter? That would make it possible to run both Bitburner XX and Bitburner Fury devices in 1 CGminer window.
I have a cgminer fork here that supports --bitburner-fury-options https://github.com/roybadami/cgminerFor backwards compatibility the Bitburner Fury boards will continue to respect --avalon-options if the new option isn't specified. I'll submit a pull request in a while, but would be good if someone other than me were to test this. I'm currently mining with a stack of two Bitburner XX boards and a stack of two Bitburner Fury boards using the following options: cgminer --avalon-options 115200:4:10:d:431 --bitburner-voltage 1300
--bitburner-fury-options 115200:32:10:d:275 --bitburner-fury-voltage 1050
--avalon-cutoff 62
: For this to be useful you need to be running one of the new BBF firmware versions on your Fury boards. This also means you need to specify the true core voltage for the Bitburner Fury boards - see my post here: https://bitcointalk.org/index.php?topic=294735.msg3364756#msg3364756 |
|
|
|
When broadcasting a transaction that I've signed on my offline box, I normally select the option to delete the transaction when done. So I was rather alarmed when after Armory told me that it had failed to broadcast the transaction to the network (first time this has ever happened to me) I discovered that Armory had gone ahead and deleted the transaction anyway! Fortunately for me: - The transaction did in fact make it to the blockchain; and
- The raw transaction was dumped to stdout/stderr anyway
I guess you can't actually lose money this way, but still, it is a somewhat nasty (if minor) bug that certainly gave me a bit of a fright - having things go wrong on any transaction more than a few bitcents always creates a bit of a sense of panic and dread :-/ Sorry, I thought I'd kept a copy of what it wrote to stdout/stderr, but I can't locate it now. But hopefully the deletion issue should be easy enough to fix without more info, even if the underlying error is less so. This was in 0.87 roy |
|
|
|
Avalon: Fan1: 0/m, Fan2: 0/m, Fan3: 0/m Temp1: 55C, Temp2: 55C, Temp3: 55C, TempMAX: 59C
What's the option in cgminer to see detailed stats like that? roy |
|
|
|
|
Show Posts
