Pages:
Author

Topic: 1GH/s, 20w, $500 — Butterflylabs, is it a scam? - page 9. (Read 123109 times)

sr. member
Activity: 349
Merit: 250
I'd like to simply make notice to any of our customers that if you're uncomfortable with your pre-order purchase, you're welcome to cancel your pre-order slot and get a full refund with no questions asked.
If anyone cancels their pre-order slot, will it become available again for purchase at the lower price?
Wow, I wouldn't even consider this so close to an answer.  I mean in ~15 hours or so you'll at least have a good idea if this is fantasy or reality.  Why pull the trigger now?
full member
Activity: 154
Merit: 102
Bitcoin!
I'd like to simply make notice to any of our customers that if you're uncomfortable with your pre-order purchase, you're welcome to cancel your pre-order slot and get a full refund with no questions asked.
If anyone cancels their pre-order slot, will it become available again for purchase at the lower price?
hero member
Activity: 546
Merit: 500
That's a lot of hyperbole.  I guess time will tell.

Meanwhile, if you're wanting your pre-order back, I would take them up on the offer for a refund.
rph
full member
Activity: 176
Merit: 100
It does what it was designed to do and at the performance levels intended.

... then ...

We're not at our final figures

So what does that mean exactly Huh

-rph
staff
Activity: 4284
Merit: 8808
Question 1: If these are indeed FPGAs (I.E., reprogrammable),

I really don't think so, but if so and you figure out what FPGA then you could make some estimates. Going from the SHA256 numbers directly is a bit harder.

Quote
Question 2: Also assuming these are reprogrammable, what would the expected performance loss be from flashing them for a single round of SHA256 (instead of double) and then using external software and/or hardware take care of doubling the hashes and fiddling with the nonces? Is this at all feasible, or is having everything all done at once in a single chip the only way to do it?

External? Not feasible.  A block header is 80 bytes. The result is 32 bytes.  Do the data rate calculations for a billion of them a second.  The data rate for a miner is only small because the ability to increment the nonce 'locally' (on chip) reduces the required data rate by a factor of 4 billion. (The same thing applies to GPUs).
BFL
full member
Activity: 217
Merit: 100
Hi guys,

I thought I would poke my head in and give an update and response to some of the comments made here in the last few days.

Firstly, I'm sorry everyone's expectations for a demo last weekend were not met.  This is an exciting process for us and it's clear some of you share the same level of enthusiasm...  (although I wonder if some of it might be better channeled).  In any case, sorry to let you down.

We're well past the bringing to life phase of the board.  It does what it was designed to do and at the performance levels intended.  There are some tuning issues that took us longer than expected which we've dialed the board down in order to more easily address.  We didn't want to demo a tuned down system that's not representative of our performance envelope, so we simply pushed the demo forward in order to give the team the time they need.  We're now near the end of that process.

As Inaba mentioned, we'll be bringing a live running unit to his data center tomorrow for a quick look and performance demonstration.  Since we're not at our final figures, he's agreed to simply confirm or deny if the unit is generally within the performance class expected.  I think rather than fuzzy numbers, everyone just wants to know if this unicorn is real.  Fair enough...  we expect to clarify that once and for all tomorrow afternoon.  We'll follow up with a more formal demo once we're finished.

There has also been fevered speculation by a couple forum members about elaborate payment methods etc.  Instead of commenting on them directly, I'd like to simply make notice to any of our customers that if you're uncomfortable with your pre-order purchase, you're welcome to cancel your pre-order slot and get a full refund with no questions asked.  

Once again, thank you for your interest in our BitForce product.

Kind regards,
BFL
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
To use two chips working together requires significant bandwidth and introduces latency issues. The board would have to be designed to handle that and it is improbable that a multi-chip solution (working on a single hash) would be faster or cheaper.

Hashing is an almost perfectly parallel task that is somewhat rare in computer science.  Usually you have more dependencies between tasks which require intra-chip communication to solve the problem.  Generally speaking the more intra-chip or intra-node communication necessary the more overhead in parallel processing (i.e. 4 chips aren't 4x as fast they are 3.2x as fast, 16 chips aren't 16x as fast they are only 12x as fast, etc). 

As above that would require 1 billion x 512 bytes x 8 bits = 4 tbps (terrabits per second) of intrachip bandwidth.  You could potentially do that but it would be a lot of work, complexity, and potential performance bottlenecks for less hashing power.   Generally you want to minimize intra-element communication UNLESS a single element (SIMD group, chip, server, cluster, etc) can't solve the problem in a reasonable amount of time.

OK, this is what I thought might be the case. The only reason I considered splitting the work in such a manner was because of the physical proximity of the chips to each other. I assumed that having them so close could indicate high bandwidth - however the numbers needed don't add up. Thanks for clarifying that.

Someone noted that there was a support chip on the board that is usually used to store firmware - not to mention the JTAG headers as well. That's why I think these have more applications than we might think they do.
hero member
Activity: 560
Merit: 500
I'm going to defend what I said now, while feeling kind of stupid.

The 5830: Where can you find it new? How much does that cost? For what 250 mhash or so?

The 5970: Okay, yes Newegg sold the last bit they had for $300, that was an awesome deal. Where else can I buy a 5970 for $300?Keyword being new! I need to snatch up a bajillion.

As for some of the other, lower end 6xxx series. I feel quite stupid and spoke before thinking. It proves the point of 'sneezing the wrong way will cause a flame war,' at least on this forum.
In that case, I'm going to say that I also took into account the power usage, and obviously the heat/cooling involved.



Bought a 6950 (albeit used) for $200 and pushing 400 MHash/s. Live in an apartment that is too cold and dont pay electricity so I get free heating and a gaming card when I need one. FPGA only wins in W/Mhash and even then only if you pay for electricity.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Question 1: If these are indeed FPGAs (I.E., reprogrammable), then is it possible to extrapolate/guess performance figures for other hashing algorithms (MD5, RIPEMD, Whirlpool, etc...) based on stated performance figures for SHA256? It seems to me that these could indeed be useful in other applications, when reprogrammed to something other than SHA256 - for instance a nice little portable MD5 cracker-in-a-box.

If they are FPGA then they could be reprogrammed.  Someone would need to design a bitstream to perform whatever task you want.  SHA-256 hashing is about 5x as computationally intensive as MD5 and Bitcoin involves a double hash so ballpark you could get ~10 billion MD5 hashes per second if the board really can do 1 billion double SHA-256 hashes.  The exact level of performance would depend on how good the bitstream programmer is and how effectively they can utilize all the LUTs to squeeze every hash of performance out of the chip.

Quote

Question 2: Also assuming these are reprogrammable, what would the expected performance loss be from flashing them for a single round of SHA256 (instead of double) and then using external software and/or hardware take care of doubling the hashes and fiddling with the nonces? Is this at all feasible, or is having everything all done at once in a single chip the only way to do it?

It is certainly possible but IMHO not economical.  We think of hashing as hard because it takes a long time to find a block but in reality a single hash is very easy.  For example if each chip can perform 1B hashes per second then on average one hash takes only a single nano second (actually that isn't true it takes a couple however each chip is working on multiple hashes at once).  To use two chips working together requires significant bandwidth and introduces latency issues.  The board would have to be designed to handle that and it is improbable that a multi-chip solution (working on a single hash) would be faster or cheaper.

Hashing is an almost perfectly parallel task that is somewhat rare in computer science.  Usually you have more dependencies between tasks which require intra-chip communication to solve the problem.  Generally speaking the more intra-chip or intra-node communication necessary the more overhead in parallel processing (i.e. 4 chips aren't 4x as fast they are 3.2x as fast, 16 chips aren't 16x as fast they are only 12x as fast, etc). 

Since each hash is independent and can be solved quickly if you want more hashing power just use more chips, or boards, or rigs.

Quote
Example: chip #1 does the first SHA256 round, and then chip #2 does the second SHA256 round, and some external software/hardware increments the nonce and sends it back to chip #1. Perhaps I don't grok how this all works, but there are several experts here and I would like to know whether I have the idea down pat.

As above that would require 1 billion x 512 bytes x 8 bits = 4 tbps (terrabits per second) of intrachip bandwidth.  You could potential do that but it would be a lot of work, complexity, and potential performance bottlenecks for less hashing power.   Generally you want to minimize intra-element communication UNLESS a single element (SIMD group, chip, server, cluster, etc) can't solve the problem in a reasonable amount of time.

TL/DR version:
You use intra-chip processing when you have to because the problem is too complex or has too many dependencies on other results to process in a single chip.  Bitcoin doesn't have that problem.  It is just about as perfectly parallel as problems come in computer science.
full member
Activity: 168
Merit: 100
Question 1: If these are indeed FPGAs (I.E., reprogrammable), then is it possible to extrapolate/guess performance figures for other hashing algorithms (MD5, RIPEMD, Whirlpool, etc...) based on stated performance figures for SHA256? It seems to me that these could indeed be useful in other applications, when reprogrammed to something other than SHA256 - for instance a nice little portable MD5 cracker-in-a-box.

Question 2: Also assuming these are reprogrammable, what would the expected performance loss be from flashing them for a single round of SHA256 (instead of double) and then using external software and/or hardware take care of doubling the hashes and fiddling with the nonces? Is this at all feasible, or is having everything all done at once in a single chip the only way to do it?

Example: chip #1 does the first SHA256 round, and then chip #2 does the second SHA256 round, and some external software/hardware increments the nonce and sends it back to chip #1. Perhaps I don't grok how this all works, but there are several experts here and I would like to know whether I have the idea down pat.

Its just too convenient have the name Bitforce for a medical imaging device.

I like that name. Very professional.

Wait, what is bitcoin? maybe we should try to make it mine bitcoins instead.
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
Question 1: If these are indeed FPGAs (I.E., reprogrammable), then is it possible to extrapolate/guess performance figures for other hashing algorithms (MD5, RIPEMD, Whirlpool, etc...) based on stated performance figures for SHA256? It seems to me that these could indeed be useful in other applications, when reprogrammed to something other than SHA256 - for instance a nice little portable MD5 cracker-in-a-box.

Question 2: Also assuming these are reprogrammable, what would the expected performance loss be from flashing them for a single round of SHA256 (instead of double) and then using external software and/or hardware take care of doubling the hashes and fiddling with the nonces? Is this at all feasible, or is having everything all done at once in a single chip the only way to do it?

Example: chip #1 does the first SHA256 round, and then chip #2 does the second SHA256 round, and some external software/hardware increments the nonce and sends it back to chip #1. Perhaps I don't grok how this all works, but there are several experts here and I would like to know whether I have the idea down pat.
full member
Activity: 168
Merit: 100
I don't disagree with any of that.  Not really sure what you are refuting.

You seemed to insinuate their pricing made no sense and that it was evidence of scam. But apparently I misunderstood and you seem to agree with me that particularly in the scenario they use s-asics, that their pricing strategy is likely completely sensible?

If so, good.
I also think you -along with everyone else- agree that the performance and power consumption claims are completely believable if this is an s-asic. I think everyone agrees the pictures and PCB look pretty damn real. BFL people dont seem to meet Inaba wearing a face mask and sunglasses. They dont seem to make any fuzz about canceled orders.

Someone remind me, what evidence was there again of this being a scam?

* Company accepting pre-orders before product is ready (which isn't necessary as they would have already had to procure the sASICS)
* Company claims product will ship in 4-6 weeks but the prototype isn't even working yet (6 weeks from initial claim was on 11/18 so they already missed that).
* Company also puts all the "promised" on all new pre-orders at 6 weeks out which keep every future order beyond Paypal chargeback period.
* Company calls themselves "Butterfly Labs Inc."  but there is no "Butterfly Labs Inc." in the US.  There are 12 BF Labs Inc (and one B.F.L. Inc) in the US but nothing on the website links them to that particular entity and no information available for BF Labs Inc link them to Butterfly Labs.
* Company claims to have decade of experience but has no prior products and didn't exist 6 months ago.
* Company planned a public demo 2 weeks ago but was unable to have product working.
* Company has never explained how 32 boards = 50x performance.
* Company claims that product is useful for medical imaging (which would be incompatible w/ sASIC design).
* Company performance claims are not possible (although not probable) w/ sASIC but board voltage and flash loader would indicate high end FPGA.
* Company now plans a public demo in which no hard numbers can be provided.
* Company "knows" board will produce 1.05 GH (not the 3 significant digits) but actually hasn't mined anything yet.  They also know the rig box will produce exactly 50.45 GH despite smaller product not working at the claimed speeds.
* Company (in one of the very few announcements) claimed it wouldn't put rig box up for pre-order until singles had been demoed yet it failed to live up to that claim.


One more to add, this is their statement with implication that bitcoin was not the main purpose of the device:

Quote
Firstly, I would like to point out that we have yet to go public with our BitForce release.  At some point recently, several notables from the bitcoin community found out about our development and approached us about applications for the bitcoin market.  Since then we have been working on bitcoin mining compatibility for our drivers.  The pre-order offer which you are discussing is meant to provide these people early access to our hardware.  Our public announcement will come in roughly two weeks.  Why not now?  Because we're not ready.

Regarding the press release draft someone found, we didn't know about that until it was mentioned here, thanks for that.  It seems one of our staff used an online PR generator several weeks ago in preparation for our announcements.  Apparently it auto published a draft along with a link for penis enlargement.  Excellent.  Luckily, they pulled it down on request.  I sincerely thank you all for this heads up.  It could have been more embarrassing than it was.


Which you can see is completely a lie. I'm sure they're experience in  "computational research", "Medical imaging "...etc .

donator
Activity: 1218
Merit: 1079
Gerald Davis
I don't understand why anybody here is surprised by the prohibition of publishing any results of a benchmark. Nowadays it is pretty much standard operating procedure that publishing any benchmark results without vendor's agreement is a breach of license.

http://www.xilinx.com/ise/license/core_license_agreement.htm

http://www.xilinx.com/ise/license/license_agreement.htm

http://www.oracle.com/technetwork/licenses/database-11g-express-license-459621.html

http://www.oracle.com/technetwork/licenses/solaris-studio-license-169628.html

I would be more surprised if anyone could show me a current licensing terms for an American product withouth the anti-bench-marking clause.

What does licensing have to do with anything.

Company X has a product they claim can do Y.  There is some skepticism that it can do Y.  If it really can do Y then proof would improve sales and Company X directly benefits.  If the product can do Y then it is in Company X best interest to publish results.

Butterfly Labs (BF Labs?) isn't licensing anything.  They are selling a product and benchmarks for electronic products are rather routine.  It helps consumers make an informed decision as to the actual performance per $.
donator
Activity: 1731
Merit: 1008
I don't understand why anybody here is surprised by the prohibition of publishing any results of a benchmark. Nowadays it is pretty much standard operating procedure that publishing any benchmark results without vendor's agreement is a breach of license.
....
I would be more surprised if anyone could show me a current licensing terms for an American product withouth the anti-bench-marking clause.
WTF , How can you defend them for hiding performance detail.

This is the only thing that matters.
sr. member
Activity: 349
Merit: 250
I don't understand why anybody here is surprised by the prohibition of publishing any results of a benchmark. Nowadays it is pretty much standard operating procedure that publishing any benchmark results without vendor's agreement is a breach of license.

http://www.xilinx.com/ise/license/core_license_agreement.htm

http://www.xilinx.com/ise/license/license_agreement.htm

http://www.oracle.com/technetwork/licenses/database-11g-express-license-459621.html

http://www.oracle.com/technetwork/licenses/solaris-studio-license-169628.html

I would be more surprised if anyone could show me a current licensing terms for an American product withouth the anti-bench-marking clause.
I don't think anybody is looking at this with benchmarks in mind. However, some degree of measurement of real performance in its intended purpose must be available.

For example, while a car might have a top speed of 120 mph, what I care about is can I drive the car on the highway?

Can I drive the BitForce widget on the highway?
legendary
Activity: 2128
Merit: 1073
I don't understand why anybody here is surprised by the prohibition of publishing any results of a benchmark. Nowadays it is pretty much standard operating procedure that publishing any benchmark results without vendor's agreement is a breach of license.

http://www.xilinx.com/ise/license/core_license_agreement.htm

http://www.xilinx.com/ise/license/license_agreement.htm

http://www.oracle.com/technetwork/licenses/database-11g-express-license-459621.html

http://www.oracle.com/technetwork/licenses/solaris-studio-license-169628.html

I would be more surprised if anyone could show me a current licensing terms for an American product withouth the anti-bench-marking clause.
sr. member
Activity: 350
Merit: 250
So I just finished reading this thread.

I demand a refund of my time wasted. ANYONE?

what a waste of time..  Undecided
donator
Activity: 1731
Merit: 1008
At $700 for 800Mhash is still far better $/H ratio than any video card I know of (new of course). Not to mention the power benefits. I'm beginning to think this is too good to be true again.
5970, 800mhs , 300$

You have to mention power benefits for it to be news worthy.
hero member
Activity: 504
Merit: 500
I'm going to defend what I said now, while feeling kind of stupid.

The 5830: Where can you find it new? How much does that cost? For what 250 mhash or so?

The 5970: Okay, yes Newegg sold the last bit they had for $300, that was an awesome deal. Where else can I buy a 5970 for $300?Keyword being new! I need to snatch up a bajillion.

As for some of the other, lower end 6xxx series. I feel quite stupid and spoke before thinking. It proves the point of 'sneezing the wrong way will cause a flame war,' at least on this forum.
In that case, I'm going to say that I also took into account the power usage, and obviously the heat/cooling involved.



  hehe, no need to feel dumb, m8. I knew what you meant by it. Thanks for explaining though.  It's one of the caveats of forum communication that we are not able to instantly correct ourselves in conversation. It can be quite frustrating in a fast paced convo when we don't give ourselves the time to recite our thoughts.

  cheers
hero member
Activity: 504
Merit: 504
Decent Programmer to boot!
I'm going to defend what I said now, while feeling kind of stupid.

The 5830: Where can you find it new? How much does that cost? For what 250 mhash or so?

The 5970: Okay, yes Newegg sold the last bit they had for $300, that was an awesome deal. Where else can I buy a 5970 for $300?Keyword being new! I need to snatch up a bajillion.

As for some of the other, lower end 6xxx series. I feel quite stupid and spoke before thinking. It proves the point of 'sneezing the wrong way will cause a flame war,' at least on this forum.
In that case, I'm going to say that I also took into account the power usage, and obviously the heat/cooling involved.

Pages:
Jump to: