HashFast launches sales of the Baby Jet

[amer]

Very risky pricing here.

November orders will make around 15BTC, and you will pay 13.8BTC to buy it.

Why take the risk just to make 1 BTC profit?

http://btcinvest.net/en/bitcoin-mining-profit-calculator.php?diff=390928787.63809&dcosts=8000&diff_mincrease=30&blpbtc=25&dhsmhs=400000&diff_mincreasedecrease=3&btcusd=190.75&dpowcon=30&btcusd_mincrease=1&pcost=0.25&calcweeks=32&dleadtime=3&action=calc

A fair price would be 10BTC, shipped by the end of november. I would suggest not ordering this hardware.

When you plug your numbers into this calculator, do you ever stop to think about the practicality of 91B difficulty/650PH in a year? Is difficulty just a number that keeps going up inexplicably to you?

Also why are you paying 8000 USD for a BabyJet?

[Puppet]

When you plug your numbers into this calculator, do you ever stop to think about the practicality of 91B difficulty/650PH in a year? Is difficulty just a number that keeps going up inexplicably to you?

Ill grant you 650PH in a year is at the extreme upper end of what I think is even conceivable. But only a very small % of all bitcoins mined by the device will happen after the 6 month mark, which at 9B isnt exactly far fetched, so the last 6 months or so of that simulation are irrelevant compared to the first 6 months; just as 650PH at the end of 1 year isnt very likely, its equally unlikely to me the next 10 difficulty adjustments will all be smaller than the past 10. The next 10 will coincide with KnC B2+, Hashfast, ActM, Bitmine, Cointerra,  Black arrow  perhaps even BFL Monarch, next gen avalons and next gen asicminers hitting the market,  the previous 10 were caused basically by just 2 vendors.

SO the simulation is very flawed  (why doesnt anyone implement a calculator with a sigmoid function for difficulty?), the conclusion might still be true for the simple reason that I cant think of a mechanism that would cause asic manufacturing and deployment to stop as long as each of these miners is operationally reasonably profitable for those with access to cheap electricity. The real question therefore becomes how fast these vendors can produce and deploy, and KnC shipping up to 600 boxes per day gives us a glimpse of how fast this could go, particularly with 10 competing suppliers (at least one of which is using monster sized manufacturing facilities)..

[vokain]

When you plug your numbers into this calculator, do you ever stop to think about the practicality of 91B difficulty/650PH in a year? Is difficulty just a number that keeps going up inexplicably to you?

Ill grant you 650PH in a year is at the extreme upper end of what I think is even conceivable. But only a very small % of all bitcoins mined by the device will happen after the 6 month mark, which at 9B isnt exactly far fetched, so the last 6 months or so of that simulation are irrelevant compared to the first 6 months; just as 650PH at the end of 1 year isnt very likely, its equally unlikely to me the next 10 difficulty adjustments will all be smaller than the past 10. The next 10 will coincide with KnC B2+, Hashfast, ActM, Bitmine, Cointerra,  Black arrow  perhaps even BFL Monarch, next gen avalons and next gen asicminers hitting the market,  the previous 10 were caused basically by just 2 vendors.

SO the simulation is very flawed  (why doesnt anyone implement a calculator with a sigmoid function for difficulty?), the conclusion might still be true for the simple reason that I cant think of a mechanism that would cause asic manufacturing and deployment to stop as long as each of these miners is operationally reasonably profitable for those with access to cheap electricity. The real question therefore becomes how fast these vendors can produce and deploy, and KnC shipping up to 600 boxes per day gives us a glimpse of how fast this could go, particularly with 10 competing suppliers (at least one of which is using monster sized manufacturing facilities)..

I don't even know what's after peta off the top of my head is how irrelevant high magnitude SI scales have been to me thus far...

edit: it's exa

[dexX7]

The real question therefore becomes how fast these vendors can produce and deploy, and KnC shipping up to 600 boxes per day gives us a glimpse of how fast this could go, particularly with 10 competing suppliers (at least one of which is using monster sized manufacturing facilities)..

Is the number of 600 boxes per day still up-to-date, only what happend on the first day(s) or the potential output of KnC?

[Puppet]

While they havent said it, KnC should be ready with batch by now, so I assume assembly is idle until batch 2. Also the 600 was over a weekend it seems, the biggest per day production number they achieved was 455
https://www.kncminer.com/news?page=2

[DeathAndTaxes]

While they havent said it, KnC should be ready with batch by now, so I assume assembly is idle until batch 2. Also the 600 was over a weekend it seems, the biggest per day production number they achieved was 455
https://www.kncminer.com/news?page=2

Yeah the sustained output seems to be significantly lower than 400 per day.   A longer term loo, reading between the lines of their shipping updates it looks like KNC Batch 1 is known to be ~3085 units (~ 1PH/s).  More details:  https://bitcointalk.org/index.php?topic=283820.msg3405759#msg3405759  

On 10/23 KNC indicated they were less than 1 good day (~400 units) from complete but as of today not all orders have shipped but lets assume every single Sept/Oct customers receive their units by the end of this week.  That is 5 weeks of shipping and 3000 maybe 3500 unit shipped in Batch 1 or 600 to 700 per week.

So while they had some peak days obviously something kept them from full capacity.   Still I would guess they learned a lot and Batch 2 (3,4,5,6,7,8) should ship in higher throughput but I doubt that is the limiting factor, customer demand will be.  As diff goes higher, the demand to fill all this massive capacity is not materializing.  Say KNC (and HF and Cointerra) can all ship 1,000 units combined per day.  Lets fast forward to January.   Lets also assume between all 3 vendors and product lines the average hashpower per unit is 1 TH/s.   That's 1 PH/s per day, 30 PH/s per month.  Even at $5 per GH/s we are talking sustained sales of $5M per day, $150M per month.   Anyone think miners are going to be buying $150M worth of new hardware, every month, month after month with no end in sight.  All major vendors have available unsold capacity in the later month batches, the days of Avalon Batch 1 selling out in 5 hours are over.  

[amer]

When you plug your numbers into this calculator, do you ever stop to think about the practicality of 91B difficulty/650PH in a year? Is difficulty just a number that keeps going up inexplicably to you?

Ill grant you 650PH in a year is at the extreme upper end of what I think is even conceivable. But only a very small % of all bitcoins mined by the device will happen after the 6 month mark, which at 9B isnt exactly far fetched, so the last 6 months or so of that simulation are irrelevant compared to the first 6 months; just as 650PH at the end of 1 year isnt very likely, its equally unlikely to me the next 10 difficulty adjustments will all be smaller than the past 10. The next 10 will coincide with KnC B2+, Hashfast, ActM, Bitmine, Cointerra,  Black arrow  perhaps even BFL Monarch, next gen avalons and next gen asicminers hitting the market,  the previous 10 were caused basically by just 2 vendors.

I agree that there is a lot of new hardware, but there is a practical cap on how much any one user is capable of running/any datacenter is capable of hosting. There exists some number x which is the number of people who still want to mine (vs speculate, which is becoming kind of awesome lately) and some number y which is the amount of power you're willing to contribute to the effort. Today, the network rate is x * y / average power efficiency. "New chips" change only the average power efficiency, which means that the network rate can only really change by a factor of the efficiency increase of 28nm chips to 65nm chips. Going from 3 PH to 650 PH means a 200 fold increase in GH/s/W, which is insane.

SO the simulation is very flawed  (why doesnt anyone implement a calculator with a sigmoid function for difficulty?), the conclusion might still be true for the simple reason that I cant think of a mechanism that would cause asic manufacturing and deployment to stop as long as each of these miners is operationally reasonably profitable for those with access to cheap electricity. The real question therefore becomes how fast these vendors can produce and deploy, and KnC shipping up to 600 boxes per day gives us a glimpse of how fast this could go, particularly with 10 competing suppliers (at least one of which is using monster sized manufacturing facilities)..

I know it is the obligation of everyone in the forum to chase everyone off (moar BTC for me!) , so I know an optimistic outlook is a faux pas, but there is a cap on how many people want to buy ASICs and we're going to hit an inflection where hardware supply will simply exceed demand.

[aTg]

The days of Avalon Batch 1 selling out in 5 hours are over.  

seems really happened years ago, right? the old days ...

[Puppet]

I know it is the obligation of everyone in the forum to chase everyone off (moar BTC for me!) , so I know an optimistic outlook is a faux pas,

As if that would work. Many of us have been predicting this bloodshed among virtually all asic customers for years now, it didnt change a thing, and wont change a thing. 

but there is a cap on how many people want to buy ASICs and we're going to hit an inflection where hardware supply will simply exceed demand.

Doesnt everybody want to make money without working? As long as asics are at least marginally profitable, people will buy. And when people no longer buy, prices will just drop until they buy again. The capacity is there, its going to be used one way or another. Even if miraculously miners no longer buy, these asics will just end up in large private mines.

BTW, Im sure there are loads of (ex)miners like me, sitting out the current onslaught, but who want to get in to the game again once things have settled down a bit, say next summer or so. I dont mind thin margins and long ROI times, I just dont want it to be a 100% gamble if my chosen manufacturer will be shipping one week sooner or later and how much the others will ship in the 6 weeks thereafter. Satoshi dice gives you far better odds. But that doesnt mean I wont buy an asic ever, if the opportunity presents itself, Ill buy. But thats not gonna happen anytime soon.

[dexX7]

More detailed specifications are published for the Golden Nonce chips.

The general parameters of a HashFast GN ASIC are:

• Each ASIC substrate contains 4 separate die.
• Each die contains 96 cores.
• Each core contains two complete double hash engines, which share work across one job
• Hash cores may nominally be clocked at 550 Mhz¹
• Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
• Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
  normal operating conditions.
• Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
  the ridiculously high limit of 7.922x10²⁸

Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.

Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.

Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.

Modules which are over-clocked will contain logs of such operation, which may void warranty.

It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.

^{1 Preliminary data – subject to change}

From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf

[iCEBREAKER]

More detailed specifications are published for the Golden Nonce chips.

The general parameters of a HashFast GN ASIC are:

• Each ASIC substrate contains 4 separate die.
• Each die contains 96 cores.
• Each core contains two complete double hash engines, which share work across one job
• Hash cores may nominally be clocked at 550 Mhz¹
• Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
• Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
  normal operating conditions.
• Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
  the ridiculously high limit of 7.922x10²⁸

Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.

Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.

Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.

Modules which are over-clocked will contain logs of such operation, which may void warranty.

It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.

^{1 Preliminary data – subject to change}

From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf

184 cores per chip!?

[cypherdoc]

More detailed specifications are published for the Golden Nonce chips.

The general parameters of a HashFast GN ASIC are:

• Each ASIC substrate contains 4 separate die.
• Each die contains 96 cores.
• Each core contains two complete double hash engines, which share work across one job
• Hash cores may nominally be clocked at 550 Mhz¹
• Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
• Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
  normal operating conditions.
• Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
  the ridiculously high limit of 7.922x10²⁸

Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.

Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.

Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.

Modules which are over-clocked will contain logs of such operation, which may void warranty.

It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.

^{1 Preliminary data – subject to change}

From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf

184 cores per chip!?

384

[itod]

184 cores per chip!?

image

384

It is a lot, but not unheard of. Small Bitfury 2.7 GHs ASIC has 50+ (or was it 70?) cores, KNC ASIC has 192.

[cypherdoc]

actually the doc says double hash or 768

[Ytterbium]

Bitfury chips actually have 756 cores.

Sounds like they're using "unrolled" (i.e. crappy) cores.

actually the doc says double hash or 768

Not exactly, they say they say each core has two units which "share work" across one "job".  Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.

[aerobatic]

Bitfury chips actually have 756 cores.

Sounds like they're using "unrolled" (i.e. crappy) cores.

actually the doc says double hash or 768

Actually, no.  They say they say each core has two units which "work together" on one "job".  Whatever that means.

unrolled cores are not necessarily crappy cores.

all we care about is the GH/s...  we don't mind whether they achieved it from rolled or unrolled hash engines.

some implementations will do better with rolled cores and some with unrolled.  depends completely on the design.

with rolled cores you can cram more of them on a die, but run at a slower speed.   with unrolled, you can run at a higher clock speed, but fit less of them on a die.   either of them could be better... depends on many factors, but the bottom line...  Performance, Power consumption, and Cost... are what we care about.   And much of that can be expressed as a GH's / Die area, that would give you a measure of efficiency - or in its simplest terms, GH's/S. per square mm of die area - at least when comparing like for like (all 28nm's for instance)

-- Jez

[DeathAndTaxes]

Bitfury chips actually have 756 cores.

Sounds like they're using "unrolled" (i.e. crappy) cores.

actually the doc says double hash or 768

Not exactly, they say they say each core has two units which "share work" across one "job".  Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.

Regardless of how they share work each "sub core" completes one hash per clock cycle so it isn't like they are only partial work engines.

So 4 * 96 * 2 = 768 hashes per clock cycle. 
At 550 Mhz that is 768 * 0.550 = 442.4 GH/s.

[RoadStress]

Bitfury chips actually have 756 cores.

Sounds like they're using "unrolled" (i.e. crappy) cores.

actually the doc says double hash or 768

Not exactly, they say they say each core has two units which "share work" across one "job".  Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.

Regardless of how they share work each "sub core" completes one hash per clock cycle so it isn't like they are only partial work engines.

So 4 * 96 * 2 = 768 hashes per clock cycle. 
At 550 Mhz that is 768 * 0.550 = 442.4 GH/s.

So making an analogy if they are using "unrolled" cores(bitfury) the chips will have 221 GH/s and the power consumption if denying refund(BFL) must be bigger by a factor of 4(BFL missed their power specs by 4 right?) achieving only 2.6W/GH

[DeathAndTaxes]

unrolled cores are not necessarily crappy cores.

Agree however they can't be compared directly.   It takes 80 clock cycles for a Bitfury rolled core to complete a hash where as an unrolled core will complete a hash in one clock cycle. So clock for clock Bitfury 756 rolled cores complete about the same number of hashes are 9 unrolled cores.  This isn't to say one method is better than another.  They are just different.  Given similar die efficiency a 9 unrolled core chip and a 756 rolled core chip would be comparable size, power usage, and hashpower.

Another way to look at it is GN's 768 nonces per clock cycle would be the equivalent of Bitfury announcing they have a new processor with 61,440 rolled cores.

Any way you slice it a single GN processor is a staggering number of cores each one processing a full nonce every clock cycle.   No existing design comes close to putting as much hashpower in a small package (Cointerra probably will be similar but so far specs are unknown).

And much of that can be expressed as a GH's / Die area, that would give you a measure of efficiency - or in its simplest terms, GH's/S. per square mm of die area - at least when comparing like for like (all 28nm's for instance)

Agreed and by that metric the GN is extremely dense.   A huge amount of hashing power per mm2.

[cypherdoc]

well, i told you the magic was going to be in the modules.