Process-invariant hardware metric: hash-meters per second (η-factor)

[ujka]

If I understand this metric correctly, it gives us some measure of how much design/development team optimized the performance onto the given die size.
I see the best use of it when comparing ASIC technology chips, since they are 'application specific' chips for bitcoin mining (GPU developers had different goals when designing their products).
KnC's chips don't stand well here. They just took some fpga desing, converted it to asic with some manufacturer's standard technique, and are going to put as many cores on a die as they can.
If they did the optimization in a range as Bitfury, Avalon or BFL, they would have a chip capable of 3,000 Ghash.

[1715002350]

1715002350

[1715002350]

1715002350

[1715002350]

1715002350

[1715002350]

1715002350

[runeks]

KnC's chips don't stand well here. They just took some fpga desing, converted it to asic with some manufacturer's standard technique, and are going to put as many cores on a die as they can.

So you gather it's a structured ASIC?

[RHA]

KnC's chips don't stand well here. They just took some fpga desing, converted it to asic with some manufacturer's standard technique, and are going to put as many cores on a die as they can.

So you gather it's a structured ASIC?

EDIT: Yes, they themselves state it as such.  No, Marcus from KnC said: "this specific design is standard cell ASIC 28nm"  (https://bitcointalk.org/index.php?topic=232852.msg2468045#msg2468045)

BTW: Optimizing it to get a chip capable of 3 TH/s is of no use, because it would need to take and dissipate 6000-7000 W of power.

[ujka]

BTW: Optimizing it to get a chip capable of 3 TH/s is of no use, because it would need to take and dissipate 6000-7000 W of power.

Thanks. Forgot about power and heat. I just reversed the formula...

[runeks]

Can we try to figure out this metric for the Block Erupter chips? I can't find the die area, but here are the other figures:

Our chips
Generation 1: Block Eruptor. 130nm with 6-8J/GH. Each chip's rated frequency is 336MHz at 1.05V. It translates to 336MH/s because it does one hash per cycle. The chips work stable and well at 392MH/s at 1.15V. Further overclocking needs proper handling of heat and power supply.

Judging by these pictures, it looks really small:

Update

After a long and anxious waiting, we have finally got our packaged chip samples at hand. Everyone would be busy in the following 2-3 weeks.

The following pics are taken from my cellphone.

30GHash/s of computing power on one table:


Top and bottom side of the chips:


A closer look at our baby:

These are some numbers derived from the RTL design.

Update

After further optimization and some trade-offs, we came up with this updated estimation results based on our improved design.

Hashrate: 1.00GH/s per chip
Area: 21.7mm^2 per chip
Power Consumption: 8.23W

Again remember that they are estimated from the RTL design and might have some differences to real products.

We know that the chips ended up hashing at around a third of that (336 MH/s), but the power estimate seems accurate (6-8 J/GH).

[RHA]

Code:

Avalon	275 MH/s	Custom	110nm, 55nm		16.13mm2	2,836.52
BFL SC	4.0GH/s		Custom	65nm, 32.5nm		56.25mm2	2,441.11

The Avalon above the BFL SC

Not only that, but the BFL SC is pure custom ASIC, whereas the Avalon seems more and more each day to be a quick a dirty hack implementation.

Kano, remember the BFL chips are artificially limited to 4 GH/s because of problems with power and heat density. In different circumstances (bigger boards, one good heatsink per chip) they possibly could reach 10 GH/s or more.
I think we will see such results when people start DIY with BFL chips. There can be of course problems with clock/capacitances/etc. in higher frequencies but the η metric will be quite higher than for current revision of Avalon chips.


As to figuring out η for Block Erupter chips:
(0.336 GH/s / 21.7 mm[su]2[/su]) * (130 nm / 2)[su]3[/su] = 4252.25

It seems the current formula attaches too much importance to the process node (the path width). I think it should be counted with power of 2 not 3.
(The path height is not directly proportional to its width - I think it can even be comparable between the processes in range 28-130 nm. I've found no exact info. I someone knows more, let us know.)
Relevant η' values would be:

Code:

Design           MH/s      Device  Process node,$\lambda$   Area      η'(pH/s)
Bitfury ASIC     2.0 GH/s  Custom           55nm, 27.5nm    14.44mm2  104.74
BFL SC           4.0 GH/s  Custom           65nm, 32.5nm    56.25mm2   75.11
Block Erupter    336 MH/s  Custom          130nm, 65.0nm    21.7 mm2   65.42
Avalon           275 MH/s  Custom          110nm, 55.0nm    16.13mm2   51.57
KnCMiner         100 GH/s  Custom           28nm, 14.0nm  3025.0 mm2    6.48
Bitfury FPGA     300 MH/s  Spartan-6        45nm, 22.5nm   120.0 mm2    1.27
Tricone          255 MH/s  Spartan-6        45nm, 22.5nm   120.0 mm2    1.08
BFL_MiniRigCard 1388 MH/s  2xAltera Aria II 40nm, 20.0nm   306.25mm2    0.91
Ztex             210 MH/s  Spartan-6        45nm, 22.5nm   120.0 mm2    0.88
ATI 5870         393 MH/s  Evergreen        40nm, 20.0nm   334.0 mm2    0.47

The above values are more consistent with the technologies used.

[Anenome5]

KnC's chips don't stand well here. They just took some fpga desing, converted it to asic with some manufacturer's standard technique, and are going to put as many cores on a die as they can.

So you gather it's a structured ASIC?

Yes, they themselves state it as such.

No, they specifically said it's not a structured ASIC.

[k9quaint]

Do you have enough info to do KNCMiner yet?

[RHA]

KnC's chips don't stand well here. They just took some fpga desing, converted it to asic with some manufacturer's standard technique, and are going to put as many cores on a die as they can.

So you gather it's a structured ASIC?

Yes, they themselves state it as such.

No, they specifically said it's not a structured ASIC.

Right. I was wrong.
Marcus from KnC said: "this specific design is standard cell ASIC 28nm"  (https://bitcointalk.org/index.php?topic=232852.msg2468045#msg2468045)

[Anenome5]

Maybe it's just me, but when you tell me Bitfury has a 2800 score and KNC a score of 90, that really seems odd. Especially considering KNC's gigahash/watt is better than Bitfury's or BFL's. It really makes me question the relevance of this metric to me. Are you saying KNC, or someone, if they had access to KNC's design could replace it with a design that's 30 times more efficient? Are we saying KNC's design is basically one giant fuckup? Doesn't seem to make sense or accord with known facts.

I'm gonna assume that we simply just don't have enough technical details to make a determination and that's why KNC still hasn't been added to the OP list.

[Syke]

Maybe it's just me, but when you tell me Bitfury has a 2800 score and KNC a score of 90, that really seems odd. Especially considering KNC's gigahash/watt is better than Bitfury's or BFL's. It really makes me question the relevance of this metric to me. Are you saying KNC, or someone, if they had access to KNC's design could replace it with a design that's 30 times more efficient? Are we saying KNC's design is basically one giant fuckup? Doesn't seem to make sense or accord with known facts.

KNC's chip is purely theoretical.

[k9quaint]

Maybe it's just me, but when you tell me Bitfury has a 2800 score and KNC a score of 90, that really seems odd. Especially considering KNC's gigahash/watt is better than Bitfury's or BFL's. It really makes me question the relevance of this metric to me. Are you saying KNC, or someone, if they had access to KNC's design could replace it with a design that's 30 times more efficient? Are we saying KNC's design is basically one giant fuckup? Doesn't seem to make sense or accord with known facts.

Area is taken into account in this metric. In theory, a gigantic die size could cram tonnes of hash power on a single "chip" and thus compare favorably with Avalon when measured per chip. When you measure using area, it normalizes for this and gives you a "better idea" about efficiency. I am not sure I am a fan yet, but it is an interesting way to measure ASICs

I'm gonna assume that we simply just don't have enough technical details to make a determination and that's why KNC still hasn't been added to the OP list.

That makes more sense.

[kano]

So ...  I come back again and find ...

The Avalon chip that hashes slower than the chip used in the old BFL FPGA, and uses at least 1.5 times the power of a BFL SC (per MH/s) and requires ~15 times the number of chips compared to a BFL SC (per MH/s) and a box somewhere between 5 and 10 times of a BFL SC Single ... rates:

Code:

Avalon	275 MH/s	Custom	110nm, 55nm		16.13mm2	2,836.52
BFL SC	4.0GH/s		Custom	65nm, 32.5nm		56.25mm2	2,441.11

The Avalon above the BFL SC

Not only that, but the BFL SC is pure custom ASIC, whereas the Avalon seems more and more each day to be a quick a dirty hack implementation.

Again these numbers are irrelevant to anyone but someone who wants to name a new number and pretend it's important.

Too bad you can't read, otherwise you would understand the metric being used.
Or can't you see the screen with your head up Josh's... 

All I see if you trying to make an excuse to pick some useless number to say the crappy tiny ASIC chips are good when in fact they suck.
The metric is useless except it seems to apparently show the low tech chips pretending to look better than the low tech crap they are.

[kano]

...
Clearly this a metric in progress and there is probably more that can be done to define it so it can shed light on different designs. Seeking out more information and being academically honest about it is what we need. It be nice for once to come to thread like this one and have people drop the puffery for BFL or AVALON chips etc and take an honest appraisal of the tech.
...

Clearly the progress is zero.

Again, compare the functionality, design and performance of the two chips in questions and you see the metric is pointless.

I guess we could even take it a step further and look at the implementations of 2 certain chips and see it's even worse ... but that's off topic.

The metric is basically ... "If we could actually get the manufacturers to produce chips at the nm size they should have and also parallelised them how many time they should have then here is a magic multiplier (that will get the answer wrong) to say how they compare"
Again the number is pointless and meaningless.

We even have someone ranting about the number of devices delivered so far ... well ... there have been WAY more BFL devices delivered than AVALON devices ... but that is again off topic.

Nothing has really changed since my first comments about the metric and the results even prove that.

[Bicknellski]

2) You shouldn't be praising BFL's chip because they barely got it working at all. They missed their clock rate AND power targets AND delivery date by a country mile. But they gave you a free unit before their customers go them so we are inflicted with your sycophancy.

And yes even though they missed their specs they are still better specs than anything else available ... lol

3) BFL maybe more efficient in hashes "per chip" but that is a useless metric. BFL uses 3.5 times the die size in a process that gives 4 times the density for 14 times as much logic. .275 x 14 = 3.850. That is why Avalon compares favorably to BFL using the reported specs.

Correct, this drivel makes the crappy Avalon chip compare favourably.
Exactly why it is drivel.

I think KANO would detest and argue against any metric that would compare Avalons favorably to BFL whether or not they were valid. That is what I would call bias. So we can disregard him and let the thread get back on track. Measuring things not posting personal opinions about chips and companies. Please post elsewhere Kano we get it you don't want to explore this metric. Can you guys take your bickering elsewhere please!

Bumping my question for the OP to the front again:

Can the metric say be bench marked against say past CPU chips to see how it compares existing tech development over the years and possibly show it is a reliable metric? That way we can pretty much shut down the hype-filled and adjective wielding fanboys on both sides, but particularly Kano as he seems to really take offense to anything that shines negatively on BFL for some unknown reason, and get to the meat "the quality of the underlying designs."

[ujka]

Data for many old and new CPUs, author colected most data we need here (die size, process node, benchmarks). I will try to put some of those in a spreadsheet.
http://www.alternatewars.com/BBOW/Computing/Computing_Power.htm

EDIT: Even better page:
http://www.x86-guide.com/en/marques/Intel.html

[Bicknellski]

Data for many old and new CPUs, author colected most data we need here (die size, process node, benchmarks). I will try to put some of those in a spreadsheet.
http://www.alternatewars.com/BBOW/Computing/Computing_Power.htm

EDIT: Even better page:
http://www.x86-guide.com/en/marques/Intel.html

Maybe just looking at AMD vs Intel over the past few years be an interesting gauge right? There is a clear "winner" in those two designs... I wonder if this metric would agree with the market?

[kano]

So ... who gave a moderator a blowjob to remove this particular post of mine?

It is indeed directly on topic and valid unless the moderator was a moron?

So ...  I come back again and find ...

The Avalon chip that hashes slower than the chip used in the old BFL FPGA, and uses at least 1.5 times the power of a BFL SC (per MH/s) and requires ~15 times the number of chips compared to a BFL SC (per MH/s) and a box somewhere between 5 and 10 times of a BFL SC Single ... rates:

Code:

Avalon	275 MH/s	Custom	110nm, 55nm		16.13mm2	2,836.52
BFL SC	4.0GH/s		Custom	65nm, 32.5nm		56.25mm2	2,441.11

The Avalon above the BFL SC

Not only that, but the BFL SC is pure custom ASIC, whereas the Avalon seems more and more each day to be a quick a dirty hack implementation.

Again these numbers are irrelevant to anyone but someone who wants to name a new number and pretend it's important.

Yeah good on removing all the other crap, but no reason at all to remove this one.

[gmaxwell]

So ... who gave a moderator a blowjob to remove this particular post of mine?
It is indeed directly on topic and valid unless the moderator was a moron?

The Avalon chip that hashes slower than the chip used in the old BFL FPGA, and uses at least 1.5 times the power of a BFL SC (per MH/s) and requires ~15 times the number of chips compared to a BFL SC (per MH/s) and a box somewhere between 5 and 10 times of a BFL SC Single ... rates:
[...]
The Avalon above the BFL SC
Not only that, but the BFL SC is pure custom ASIC, whereas the Avalon seems more and more each day to be a quick a dirty hack implementation.
Again these numbers are irrelevant to anyone but someone who wants to name a new number and pretend it's important.

Yeah good on removing all the other crap, but no reason at all to remove this one.

It wasn't deleted, it was moved to offtopic: https://bitcointalk.org/index.php?topic=250364.0

And it _is_ offtopic:  This whole thread is about a _process invariant_ metric. Its an approximation of the performance if fabricated on a similar process with a similar die size.  The absolute performance of the devices as fabricated are available all over (and even in the OP, at least in per-chip form).

You can yabber on about how BFL is "pure custom" and avalon is a "dirty hack"— but thats irrelevant to the thread, the thread is about the proposed process invariant number and your message was not, so it got moved with all the other off-topic dicksizing which it had inspired.

[GalaxyASIC]

And how would a consumer buying ASIC based product use this metric for choosing which product to buy?
Sounds to me like it's a calculation for the sake of calculation.
Not useful in any shape or form to anyone.

There are only 2 metric that are useful:
1) Cost in $/GH for manufacturer to make - only few know what it is exactly and can vary by 200%-500%
2) Cost in $/GH for consumer to buy.
2.1) Cost in $/GH of running the system