Author

Topic: HashFast announces specs for new ASIC: 400GH/s - page 395. (Read 880461 times)

legendary
Activity: 1176
Merit: 1001
https://twitter.com/alanmeckler/status/394828862133006338
#HashFAST Technologies is exhibiting at http://www.insidebitcoins.com  in LasVegas in December.  #bitcoin #virtualcurrencies $MBIS
(22 of October)

If they are "exhibiting" (sorry, i lack a better term), when is that since that they are not on the list? With BFL at 1pm? This is starting to be stressful...
ImI
legendary
Activity: 1946
Merit: 1019
I think they will ship in time, although I worry that the BJs will be buggy and plagued by problems with all this coming together so late.

Tell KNC batch#1/#2 customers about it.
sr. member
Activity: 392
Merit: 250
There is one other possibility... which I have only just now considered.

My intuition says that they know that the boards more-or-less work and that now, buoyed by knowledge that they won't totally crash and burn in the short term, they are coming late to a 'walk softly and carry a big stick' strategy... impress us by 'underpromising' in the last teeth-gnashing couple of weeks. They are not fully aware that it's past the time to do that because their nose has been so close to it and, well, because their customer relations strategies, well, they have tended to suck.

I think they will ship in time, although I worry that the BJs will be buggy and plagued by problems with all this coming together so late.

ImI
legendary
Activity: 1946
Merit: 1019

I didnt know they are in Vegas.

That is indeed good news.



hero member
Activity: 518
Merit: 500
Hodl!
It is 2 hahes per clock.  Each core is actually a "dual core" capable of 2 nonces per clock.  So cut your speed requirement in half.

96 engines * 2 * 4 = 768 nonces per clock.   400 GH/s = 400,000 MH/s / 768 = 520 Mhz.  Now that assumes 100% yield which is never going to be the case but say 550% with 90% core yield would achieve ~ 400 GH/s.  

Now the radio silence is bad news, what bad news not sure but The chips as designed were designed to operate around 500 Mhz not 1.1 Ghz and processed 2 nonces per core.

I must have missed that.... if they only need to run 500Mhz though, what's all the fuss with the substrate?


Edit: Oh by the way, this IS two SHA2 operations per clock right? Not two SHA operations per clock, which is the norm for SHA2, just wanna be clear.
legendary
Activity: 1176
Merit: 1001
Regardless, if that is not the case, then I imagine there will be a mob of people waiting to pummel them with questions.  So I think either way today we will get some updates.
Nice tough, thanks for sharing.

BFL's Josh talk is at 1:30PM and there doesn't appear to be anyone from HF on that list, tough:
http://www.mediabistro.com/insidebitcoins/agenda.asp

However, they are a sponsor: http://www.mediabistro.com/insidebitcoins/sponsors.asp (along with BFL and Cloud Hashing)
sr. member
Activity: 490
Merit: 255
There is one other possibility... which I have only just now considered.

Since the CEO is a marketing guy, and HashFast is going to be at "Inside Bitcoin" in Vegas today, maybe they want to make a big splash by announcing their stats/specs, demo box there.

Would be inline with normal marketing strategies if they weren't already so late... (blah blah.. they are not late until Jan.1st, but we all were expecting at least a start by Dec.1).

Regardless, if that is not the case, then I imagine there will be a mob of people waiting to pummel them with questions.  So I think either way today we will get some updates.
donator
Activity: 1218
Merit: 1079
Gerald Davis
do they have serious issues?

What I am imagining is happening right now, is that they are finding that the dies do 800Mhz at 0.5W/Gh, 900Mhz at 0.7W /gh, 1000Mhz at 0.9W/Gh and 1100Mhz at 1.2W/Gh ... and are thinking something similar to "Holy fuck, now what? The boards are only designed for 350W max." (1 hash per clock, 95 engines per die, 4 dies per package, SHOULD equal 400GH... ergo needing to run at about 1100Mhz )

I think whats fair is for them to ship every baby jet with 2 modules and a 3 module sierra. Or, 2 sierras with 5 modules in total (preferred).

So that might very well be an option, shipping extra modules per unit. Or beef up the onboard power conversion, and ship single unit BJs that suck 600W at the wall... (add "2 weeks" for scramble board redesign, add "2 weeks" for PSU resourcing...)


This is all purely speculative of course.

It is 2 hahes per core per clock.  Each core is actually a "dual core" capable of 2 nonces per clock.  Why 96 cores capable of two nonces per clock instead of 192 independent cores?  No idea but per the spec each chip is capable of 768 nonces per clock so the clocksped requirements are half (minus yield losses) of what you posted.

96 engines * 2 * 4 = 768 nonces per clock.   400 GH/s = 400,000 MH/s / 768 = 520 Mhz.  Now that assumes 100% yield which is never going to be the case but say 550 Mhz with 90% core yield would still achieve ~ 400 GH/s.  650 Mhz with 95% output would be 474 GH/s.

Now the radio silence is bad news, what bad news not sure but the chips as designed/specced should be ~500 Mhz and 768 nonces per clock (minus yield losses).
legendary
Activity: 1176
Merit: 1001
So far radio silence kind of feels like the capsule actually blew up rather than leaking oxygen.
Apollo 1. This is us before burning alive in that capsule: http://upload.wikimedia.org/wikipedia/commons/4/49/Apollo_1_crew_during_water_egress_training%2C_June_1966.jpg

Don't worry guys, they are just shipping everything to Canada where on the 13th they will start shipping, as promised.

USD refunds for everyone! Enjoy!
sr. member
Activity: 490
Merit: 255
No news definitely isn't good news.

I think we are all looking for the twitter feed to send up the "Houston, we have a problem" message.
So far radio silence kind of feels like the capsule actually blew up rather than leaking oxygen.

It would be natural to assume that the bad news is that the chip performance results is incompatible with the PCB as designed.  How long does it take to redesign the PCB?
hero member
Activity: 546
Merit: 500
do they have serious issues?

What I am imagining is happening right now, is that they are finding that the dies do 800Mhz at 0.5W/Gh, 900Mhz at 0.7W /gh, 1000Mhz at 0.9W/Gh and 1100Mhz at 1.2W/Gh ... and are thinking something similar to "Holy fuck, now what? The boards are only designed for 350W max." (1 hash per clock, 95 engines per die, 4 dies per package, SHOULD equal 400GH... ergo needing to run at about 1100Mhz )

I think whats fair is for them to ship every baby jet with 2 modules and a 3 module sierra. Or, 2 sierras with 5 modules in total (preferred).

So that might very well be an option, shipping extra modules per unit. Or beef up the onboard power conversion, and ship single unit BJs that suck 600W at the wall... (add "2 weeks" for scramble board redesign, add "2 weeks" for PSU resourcing...)


This is all purely speculative of course.

This is exactly my fear too, although I've been too scared to say it.

I've been obsessively watching twitter, waiting for some news.
hero member
Activity: 518
Merit: 500
Hodl!
do they have serious issues?

What I am imagining is happening right now, is that they are finding that the dies do 800Mhz at 0.5W/Gh, 900Mhz at 0.7W /gh, 1000Mhz at 0.9W/Gh and 1100Mhz at 1.2W/Gh ... and are thinking something similar to "Holy fuck, now what? The boards are only designed for 350W max." (1 hash per clock, 95 engines per die, 4 dies per package, SHOULD equal 400GH... ergo needing to run at about 1100Mhz )

I think whats fair is for them to ship every baby jet with 2 modules and a 3 module sierra. Or, 2 sierras with 5 modules in total (preferred).

So that might very well be an option, shipping extra modules per unit. Or beef up the onboard power conversion, and ship single unit BJs that suck 600W at the wall... (add "2 weeks" for scramble board redesign, add "2 weeks" for PSU resourcing...)


This is all purely speculative of course.
donator
Activity: 994
Merit: 1000
The first wave of refund requests was already denied by Hashfast. Probably because of the inherent injustice when refunding a barter type transaction for a highly volatile item like bitcoin. I assume it was decided that playing on time and delivering the product is better than to get into a refund mess at this stage.

Right now the best chance to resolve the issue is to deliver a product and compensate for the shortfalls by over delivering on the remaining promises. As a company they are very high up in the food chain - so there's enough love to spread around.

That said - the refund question will probably end up in court.

Where any of them actually denied?  I was under the impression the requests were largely ignored.  The inherent injustice here is advertising shipment dates that couldn't be met for a product who's value is almost entirely predicated on it's delivery date.  Hashfast themselves implicitly acknowledged this by pricing their batch two product 50% less than their batch one.
Yes - everybody here is aware of this - but it will take a good lawyer to educate the judge on these issues. You don't want to go cheap on that one.

However, the injustice I was referring to is not the failure to deliver - it's the calamity which results from fixing the failure with a refund policy which is not tuned to the shortcoming of failing to deliver. E.g. they accepted both USD and bitcoin payments for a device which generates bitcoins which set them up for such a dilemma. Thus I can see why they would not want to refund if they are confident that they have a competitive product.

Any prudent compensation scheme would estimate the amount of bitcoins which where lost due to failure to deliver. In fact that's basically what the MPP provides - it's not exactly a bitcoin payout - but once the hardware is in the hands of customers they can sell them at market prices for bitcoins or mine themselves. Since the MPP delivered hardware itself is sensitive to time of delivery, a failure of delivering the MPP in time would make them liable for another round of compensation. That compensation scheme can drag on for a long time, but given the profit margins of the mining companies, I expect that it's in their power to eventually get rid of this liability.

The upshot is this: As long as they keep compensating early customers for any shortcomings nobody has an economic incentive to drag this out in front of a court, even if their approach may be appalling.
legendary
Activity: 1176
Merit: 1001
There are some reports of denied refunds after weeks of waiting for answers.
sr. member
Activity: 479
Merit: 250
The first wave of refund requests was already denied by Hashfast. Probably because of the inherent injustice when refunding a barter type transaction for a highly volatile item like bitcoin. I assume it was decided that playing on time and delivering the product is better than to get into a refund mess at this stage.

Right now the best chance to resolve the issue is to deliver a product and compensate for the shortfalls by over delivering on the remaining promises. As a company they are very high up in the food chain - so there's enough love to spread around.

That said - the refund question will probably end up in court.

Where any of them actually denied?  I was under the impression the requests were largely ignored.  The inherent injustice here is advertising shipment dates that couldn't be met for a product who's value is almost entirely predicated on it's delivery date.  Hashfast themselves implicitly acknowledged this by pricing their batch two product 50% less than their batch one.
legendary
Activity: 1120
Merit: 1002
Hashfast: in October for gain  customers, you promised a delivery  for 15/30 october . Today, we know a little more about you, and you know more on your produtcs .. '(wtf)........ then today: what is the real hashrate of the chips? and when are you finaly deliver babyjets batch one? And please : try  Honestly this time . Thanx.
donator
Activity: 994
Merit: 1000
Why are you talking about refunds?

I'm talking about this because enormous amount of posts on this thread are spreading wishful thinking and misinformation in vain hope that many times repeated nonsense will somehow become a fact....
There's a real need for everyone to inform himself on facts and of possible outcomes, and prepare for the decision weather to request a refund or not.
The first wave of refund requests was already denied by Hashfast. Probably because of the inherent injustice when refunding a barter type transaction for a highly volatile item like bitcoin. I assume it was decided that playing on time and delivering the product is better than to get into a refund mess at this stage.

Right now the best chance to resolve the issue is to deliver a product and compensate for the shortfalls by over delivering on the remaining promises. As a company they are very high up in the food chain - so there's enough love to spread around.

That said - the refund question will probably end up in court.
full member
Activity: 168
Merit: 100
http://bitcoin.sipa.be/speed-lin.png
The tree days estimate has something to say.
Are you suggesting they're testing the chips right now?
no, it comes from KnC Nov batch.
source?
source???
KNC just ship about 2 petahash of jupiters and saturns and people have been posting for the last 10 days as they have received them.  

hey, this 570 devices with 400 GH/s are just 228 TH/s. this is nothing compared to KnC.
my guess is they have serious issues because the CEO is a marketing guy. all good news would go instantly public.

Surprisingly, most of the information we have has come from the tech guy (Barber) via Twitter.
legendary
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
I can't believe the nonsense about the refunds in BTC I've read in this thread. It's been clarified by official statement several times by HF, I don't have a nerves to search two HF threads, but it's there somewhere:
All refunds will be in the currency payed by customer. If you paid in US$, they would refund the exact same amount in US$. If you paid in BTC, refund will be in BTC, but all the payments are calculated to be in the US$ on the day of the payment. That's important: day of the payment. Go check the BTC/US$ historic value on the day you paid, divide BTC paid with it, and expect BTC value of that US$ amount on the day of the refund. Hashfast never considered refunding BTC payments in US$, but they've made it clear that accounting value is in the US$ currency. I'm burned also by this policy, but consider these facts before you officially request a refund not to be burned with the consequences when you receive the fraction of the BTC paid as full refund. You can always prepare yourself for a legal action against HF if you don't like this, but this have been confirmed and other claims are just wishful thinking.

Why are you talking about refunds? HF still has 22 full days until every single batch one customer gets what he paid for.
That's plenty of time.

I'm talking about this because enormous amount of posts on this thread are spreading wishful thinking and misinformation in vain hope that many times repeated nonsense will somehow become a fact. Like the people having a need for somebody to hold their hand and tell them everything is gonna be OK. Well it will not. Whoever got in this HF mess (including myself) will gonna get financially hurt whichever of the many outcomes come to the light of day, and there's nothing anyone can do about it.

There's a real need for everyone to inform himself on facts and of possible outcomes, and prepare for the decision weather to request a refund or not. The HF is obviously in disarray, KnC made working miner on the very day they've laid their hands on chips. HF obviously can't get their act together, and 22 days look to me as just not enough time to do everything right from this moment on.
Jump to: