darkfriend77
|
|
October 01, 2013, 12:07:11 PM |
|
Kano has a bitburner with avalon chips while I have none so he is helping maintain that code in main cgminer. The bitburner fury has nothing in common with the bitburner avalon so for the time being, you're on your own since we've had nothing to do with that bitfury code.
:-) this sounds not really encouraging ... any words about the software situation ... cryptX ...
|
|
|
|
jlsminingcorp
|
|
October 01, 2013, 02:37:06 PM |
|
Kano has a bitburner with avalon chips while I have none so he is helping maintain that code in main cgminer. The bitburner fury has nothing in common with the bitburner avalon so for the time being, you're on your own since we've had nothing to do with that bitfury code.
:-) this sounds not really encouraging ... any words about the software situation ... cryptX ... Thanks for letting us know ckolivas, it's a real shame that things have worked out like this. Cryptx, yes please could you reassure us that there's a plan in place to deal with the software if ckolivas and Kano are not involved?
|
|
|
|
FlappySocks
|
|
October 01, 2013, 02:45:50 PM |
|
I'm sure I read that the bitburners emulated one of the existing protocols already supported by cgminor. The only reason why cgminor might need modification is to control overclocking. I would assume the Bitfury boards would be the same.
But some clarification from Cryptx would be nice.
|
|
|
|
jlsminingcorp
|
|
October 01, 2013, 02:59:40 PM |
|
I'm sure I read that the bitburners emulated one of the existing protocols already supported by cgminor. The only reason why cgminor might need modification is to control overclocking. I would assume the Bitfury boards would be the same.
But some clarification from Cryptx would be nice.
Bitburners were based on Avalon chips though, which were already supported by cgminer. I think that the problem here is that there has never been official cgminer support for bitfury chips, as the developers don't have access to the hardware.
|
|
|
|
FlappySocks
|
|
October 01, 2013, 03:13:26 PM |
|
Yeah I know, but it was emulated AFAIK. In other words, there is an on board CPU that talks to the chips, and then the CPU talks to cgminer in a protocol such as Avalon, BFL or whatever.
|
|
|
|
shapemaker
Full Member
Offline
Activity: 238
Merit: 100
I run Linux on my abacus.
|
|
October 01, 2013, 03:17:52 PM |
|
2 things now:
1: KnC is shipping, starting tomorrow I guess. Bye bye any kind of profit from these overpriced boards. Kindly, fuck you, cryptx.
2: You better have a mining software ready for release.
|
Shut up and give me money: 115UAYWLPTcRQ2hrT7VNo84SSFE5nT5ozo
|
|
|
jlsminingcorp
|
|
October 01, 2013, 03:34:31 PM |
|
Yeah I know, but it was emulated AFAIK. In other words, there is an on board CPU that talks to the chips, and then the CPU talks to cgminer in a protocol such as Avalon, BFL or whatever.
Ah, looks like I'm demonstrating my ignorance again . Thanks for putting this straight. So that's potentially a positive thing right, as long as the bitfury burner boards emulate something that is supported by cgminer then we're not too far off?
|
|
|
|
mmitech
Legendary
Offline
Activity: 1148
Merit: 1001
things you own end up owning you
|
|
October 01, 2013, 03:40:51 PM |
|
you just got fucked, no one took my warnings, now that KNC and BFSB started shipping, I am feeling more sorry for you guys, difficulty will go at least 250+% in a month or so
|
|
|
|
shapemaker
Full Member
Offline
Activity: 238
Merit: 100
I run Linux on my abacus.
|
|
October 01, 2013, 03:56:09 PM |
|
you just got fucked, no one took my warnings, now that KNC and BFSB started shipping, I am feeling more sorry for you guys, difficulty will go at least 250+% in a month or so Your warning has no merit since these boards were the only way to get a 70% "refund". It was well known already that these are overpriced, but still better than wasting 50% of BitBurner (Avalon) board payments.
|
Shut up and give me money: 115UAYWLPTcRQ2hrT7VNo84SSFE5nT5ozo
|
|
|
Roy Badami
|
|
October 01, 2013, 07:48:51 PM |
|
I think that the problem here is that there has never been official cgminer support for bitfury chips, as the developers don't have access to the hardware.
Not quite true. 3.5.0 supports red fury/blue fury. roy
|
|
|
|
tarmi
Legendary
Offline
Activity: 1232
Merit: 1011
|
|
October 02, 2013, 09:44:43 AM |
|
and?
any progress?
|
|
|
|
FlappySocks
|
|
October 02, 2013, 12:21:37 PM |
|
Time to cancel my order. These are not going to ROI. I'll go back to Burnin for my money.
|
|
|
|
someone42
Member
Offline
Activity: 78
Merit: 11
Chris Chua
|
|
October 02, 2013, 01:03:02 PM |
|
About the software situation, I can clear this up a bit.
Though I am not burnin or cryptx, I am the person primarily responsible for the boards' firmware. The firmware for the BitBurner Fury boards emulates the Avalon protocol, just like the Avalon-based BitBurner XX boards. So there won't be any need for a customised version of cgminer. All the details of BitFury chip communication are abstracted away by the firmware. If you already have BitBurner XX boards, whatever setup you have will be fine for the BitBurner Fury boards.
Some minor changes to cgminer might be required since voltage settings are different (since Avalon = 110 nm, BitFury = 55 nm). Also, since the BitFury boards are much more powerful, some delays need to be adjusted to ensure that the cgminer driver doesn't become a bottleneck.
|
|
|
|
jlsminingcorp
|
|
October 02, 2013, 01:38:49 PM |
|
About the software situation, I can clear this up a bit.
Though I am not burnin or cryptx, I am the person primarily responsible for the boards' firmware. The firmware for the BitBurner Fury boards emulates the Avalon protocol, just like the Avalon-based BitBurner XX boards. So there won't be any need for a customised version of cgminer. All the details of BitFury chip communication are abstracted away by the firmware. If you already have BitBurner XX boards, whatever setup you have will be fine for the BitBurner Fury boards.
Some minor changes to cgminer might be required since voltage settings are different (since Avalon = 110 nm, BitFury = 55 nm). Also, since the BitFury boards are much more powerful, some delays need to be adjusted to ensure that the cgminer driver doesn't become a bottleneck.
Thanks someone42, that's just the update we were looking for. This all sounds very positive. So do you have somebody on the team working on the cgminer tweaks, so that we can get hashing as soon as the boards arrive?
|
|
|
|
shade88
Member
Offline
Activity: 119
Merit: 10
|
|
October 02, 2013, 02:05:40 PM |
|
Time to cancel my order. These are not going to ROI. I'll go back to Burnin for my money.
Why? Do you have inside info on the performance? If they deliver 4GH/chip it's almost as good as KnC Jupiter with better watt usage. Why not wait till First Week of Oct is over?
|
|
|
|
FlappySocks
|
|
October 02, 2013, 02:13:54 PM |
|
Why? Do you have inside info on the performance? If they deliver 4GH/chip it's almost as good as KnC Jupiter with better watt usage. Why not wait till First Week of Oct is over?
Do you think they will ROI? I dont think so. Not now with KNC up and running. Cryptx are silent. We dont have any specs or when it''s going to ship.
|
|
|
|
Tursk
Member
Offline
Activity: 92
Merit: 10
|
|
October 02, 2013, 02:23:18 PM |
|
About the software situation, I can clear this up a bit.
Though I am not burnin or cryptx, I am the person primarily responsible for the boards' firmware. The firmware for the BitBurner Fury boards emulates the Avalon protocol, just like the Avalon-based BitBurner XX boards. So there won't be any need for a customised version of cgminer. All the details of BitFury chip communication are abstracted away by the firmware. If you already have BitBurner XX boards, whatever setup you have will be fine for the BitBurner Fury boards.
Wow, that sounds great. I guess this means you can put both Bitburner XXs and Furys to the same CAN-bus and control all boards from one cgminer :-?
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
October 02, 2013, 02:29:50 PM |
|
Some minor changes to cgminer might be required since voltage settings are different (since Avalon = 110 nm, BitFury = 55 nm). cgminer doesn't control the voltage of any miner to date. All existing miners (and almost certainly this product as well) operate on a fixed voltage. Changing the voltage requires changing a resistor on the board.
|
|
|
|
tarmi
Legendary
Offline
Activity: 1232
Merit: 1011
|
|
October 02, 2013, 02:33:19 PM |
|
I am not so sure about that.
|
|
|
|
someone42
Member
Offline
Activity: 78
Merit: 11
Chris Chua
|
|
October 02, 2013, 03:21:46 PM |
|
Wow, that sounds great. I guess this means you can put both Bitburner XXs and Furys to the same CAN-bus and control all boards from one cgminer :-?
In principle, yes, since the CAN-bus protocol is also the same. But in practice, you will get HW errors because of how cgminer's Avalon driver is implemented*. Also, frequency settings are broadcast across the CAN-bus and it's unlikely that you would want Avalon and BitFury to run at exactly the same frequency. Maybe in the future, when a well-designed cgminer driver and corresponding firmware is written, you will be able to mix Avalon/BitFury/Cointerra/whatever BitBurner boards. cgminer doesn't control the voltage of any miner to date. All existing miners (and almost certainly this product as well) operate on a fixed voltage. Changing the voltage requires changing a resistor on the board.
Voltage control for BitBurner boards from within cgminer was added in August (see https://github.com/ckolivas/cgminer/commit/b0f4d55be77adfacc3fd3e1bf0540a0252610455). Thanks someone42, that's just the update we were looking for. This all sounds very positive. So do you have somebody on the team working on the cgminer tweaks, so that we can get hashing as soon as the boards arrive?
See https://github.com/ckolivas/cgminer/pull/499. *cgminer's Avalon driver rotates through an array of work units. Mixing Avalon and BitFury will cause the array rotation to happen too fast for the Avalon boards, causing cgminer to forget about work units and resulting in "no matching work" errors.
|
|
|
|
|