HashFast launches sales of the Baby Jet

[BeepBeep2]

heck, if they want to quote even higher performance numbers (quite legitimately) they should be pouring liquid nitrogen down a tube directly onto the die... for the ultimate in cooling - the way that pc overclockers do it.  But you have to bear in mind that Intel never makes claims as to the performance that the overclocking teams hit, as theyre doing it using extreme methods that arent available to regular customers.

An expensive heatsink (usually called an LN2 Evaporator or "Pot" which contain a heavy base of copper) is necessary to do that, in HashFast's case it would cost probably $1000 and too much time, probably a few weeks.

I'm a "regular customer" if you look at me as a normal consumer...most of the overclockers work on their own (belonging to a team but only for the sake of working together for points)
http://hwbot.org/submission/2426492_beepbeep2_cpu_frequency_fx_8120_8009.9_mhz
http://hwbot.org/submission/2371619_beepbeep2_cpu_frequency_phenom_ii_x4_955_be_7005.96_mhz
http://hwbot.org/submission/2334802_beepbeep2_cpu_frequency_core_i7_2600k_5759.36_mhz

Not only would this give HF higher performance numbers though, it would increase the efficiency of the GN chip by a sizable amount.
They would probably be able to claim around .4w/GH under "extreme conditions" or however they would spin the truth with the chip underclocked this way.


See the way intel's Core i7 3770K acts:

[aerobatic]

Hi Aerobatic, good of you to take the time to reply. Like I said before, I have no interest in Hashfast other than that I'd like to see them fulfill their obligations to their paying (or rather paid up) customers, and I'm sure said customers would agree. So to me it's odd to trumpet what they 'may' be able to achieve rather than supplying tracking numbers for what they have dispatched, especially when those number don't add up - from the engineering point of view.

I'd like to address your points in more detail, but it's 9 pm in the UK just now and I'm just about to watch Sherlock Holmes (the new series) on BBC. Don't know if you get it where you live, but it's well worth a watch on the iPlayer. So I'll reply tomorrow, but one thing I can confirm to you is that the watts/GH figure remains constant no matter what clock speed is used. It's generated from the equation:

watts/Hash = Ng * Pg * F / (Nc * F) where:

Ng = number of gates switching per clock cycle - a design constant which depends upon the pipeline stage architecture
Pg = average switching power per gate per Mhz - a silicon process constant; about 0.6 nanowatts per Mhz for most LP 28nm processes
F = clock frequency (variable)
Nc = number of cores (pipelines) in the device; each core produces one result (hash) out of the pipeline every clock cycle, the pipeline latency is
       ignored as it's irrelevant in practice. So hashes = NC * F.

Or to simplify, P = Ng*Pg/Nc.  F cancels out, ie frequency is irrelevant. Static device power is also ignored here as it's relatively low in comparison.

If your pipeline design is very efficient then P goes down. Inefficient design = up.

Hope this helps.

Hey Bronto.. i too am a huge sherlock fan... and also live in London.. and am writing this halfway through watching it on sky hd.  Ive had to survive on a diet of Elementary, until this new sherlock came out...  im sure you'll agree, elementary is a poor cousin.

Anyway... back to the plot... ;-)

You ignored the most important point.  Voltage.    Raise the volts and you can clock the chip faster (but it draws more power per GH)...  lower the volts, and you can clock it slower (and reduce the power per GH).

So... when theyre benchmarking it for max performance, they will run it at higher volts than nominal (eg 0.82v+)... because the goal is the fastest GH possible.  And they dont care how much power it will use.   Especially because theyre only benchmarking one die, so it wont get anywhere close to the thermal or power draw limits of the chip itself.  It could easily draw more than 1W/GH when theyre in that 'max performance' volt mode.   Therefore its likely the volts used to hit the top speed benchmark were higher than the volts used to benchmark it for the 'lowest power consumption' mode.  And im assuming they lowered the volts to quite a bit less than nominal to hit the 'low power consumption' benchmark of 0.67w/GH...   possibly as low as 0.76v but certainly less than the nominal 0.82v, etc.

As you know, tiny changes to the volts make large changes to the power consumption (squared)

[smoothie]

‏@HashFast
https://twitter.com/HashFast/status/418107074979971072
A big thank you to Amy for camping out in Montreal for the last week!

We did it!! Shipped the first Baby Jets and Sierras today.

"We did it"?


lol what exactly did you do? Pull a BFL and "ship" one half-broken unit to your supposed business acquaintance across the room from you?

[brontosaurus]

Hi Aerobatic, good of you to take the time to reply. Like I said before, I have no interest in Hashfast other than that I'd like to see them fulfill their obligations to their paying (or rather paid up) customers, and I'm sure said customers would agree. So to me it's odd to trumpet what they 'may' be able to achieve rather than supplying tracking numbers for what they have dispatched, especially when those number don't add up - from the engineering point of view.

I'd like to address your points in more detail, but it's 9 pm in the UK just now and I'm just about to watch Sherlock Holmes (the new series) on BBC. Don't know if you get it where you live, but it's well worth a watch on the iPlayer. So I'll reply tomorrow, but one thing I can confirm to you is that the watts/GH figure remains constant no matter what clock speed is used. It's generated from the equation:

watts/Hash = Ng * Pg * F / (Nc * F) where:

Ng = number of gates switching per clock cycle - a design constant which depends upon the pipeline stage architecture
Pg = average switching power per gate per Mhz - a silicon process constant; about 0.6 nanowatts per Mhz for most LP 28nm processes
F = clock frequency (variable)
Nc = number of cores (pipelines) in the device; each core produces one result (hash) out of the pipeline every clock cycle, the pipeline latency is
       ignored as it's irrelevant in practice. So hashes = NC * F.

Or to simplify, P = Ng*Pg/Nc.  F cancels out, ie frequency is irrelevant. Static device power is also ignored here as it's relatively low in comparison.

If your pipeline design is very efficient then P goes down. Inefficient design = up.

Hope this helps.

Hey Bronto.. i too am a huge sherlock fan... and also live in London.. and am writing this halfway through watching it on sky hd.  Ive had to survive on a diet of Elementary, until this new sherlock came out...  im sure you'll agree, elementary is a poor cousin.

Anyway... back to the plot... ;-)

You ignored the most important point.  Voltage.    Raise the volts and you can clock the chip faster (but it draws more power per GH)...  lower the volts, and you can clock it slower (and reduce the power per GH).

So... when theyre benchmarking it for max performance, they will run it at higher volts than nominal (eg 0.82v+)... because the goal is the fastest GH possible.  And they dont care how much power it will use.   Especially because theyre only benchmarking one die, so it wont get anywhere close to the thermal or power draw limits of the chip itself.  It could easily draw more than 1W/GH when theyre in that 'max performance' volt mode.   Therefore its likely the volts used to hit the top speed benchmark were higher than the volts used to benchmark it for the 'lowest power consumption' mode.  And im assuming they lowered the volts to quite a bit less than nominal to hit the 'low power consumption' benchmark of 0.67w/GH...   possibly as low as 0.76v but certainly less than the nominal 0.82v, etc.

As you know, tiny changes to the volts make large changes to the power consumption (squared)

Hi Aerobatic, you are of course quite correct in that voltage affects the power dissipation, but in the case of SHA256 it would be very unusual to increase the supply voltage - as the games do to get faster running cpu's - because the pipelines can generally switch much faster than they are clocked at. In SHA256 the problem is that almost every transistor in the pipelines switches every clock cycle - the real problem is how to get rid of the heat that's generated without having to increase the die size (and so wasting silicon area), I'm sure I remember the guy from Bitfury posting stuff some time ago about lowering the supply voltage on his asic to run cooler, which on the face of it sounds sensible but then that has a knock on effect on threshold voltages and that in turn can result in unreliable operation due to increased susceptibility to noise.

For my part, I'd much rather get a device that operates reliably within it's rated parameters that has been designed from the start to be efficient rather than buggering around to try to squeeze out more performance. Intel don't design 'to the limit', that's why their chips can be overclocked so readily, the engineers have built in a margin for error. The Bitcoin asic designers don't seem to grasp this point which makes me high suspicious of some of the 'credentials' trumpeted on their websites.

I chose my username because my colleagues do view me as a bit of a dinosaur, but that's because I started out designing things when you only had a few tens of thousands of transistors to design with, not hundreds of millions and so you had to be very creative with your resources. I like doing things right that work the way they were specified first time around. A lot of the technospeak from the rig vendors make me shudder and I wish to goodness someone would come along with a mining product minus the bullshit, fantasy project timescales but with some solid engineering behind it.

As an example of what bugs me, I had a look recently at Cointerra's Team, and to my astonishment found they have a 'Chief Crytographic Advisor'. Why would they employ such a guy? Don't the engineers understand SAH256? Nothing against Dr.Hanke, I'm sure he's very good at what he does but if I was a prospective rig customer I'd much rather see a VP in their team that actually had some experience of volume product manufacturing because the chip design for SHA256, whether anyone wants to admit it or not is fixed and well within the capabilities of most EE graduates. So the chip design is a given. What's proven not so easy is the actual system integration and product engineering part.

Nothing against Cointerra by the way, they seem less suspect than most of the other suppliers but they're still way too expensive for what's on offer and are excluding a huge number of people who would like to participate in mining.

Sorry for the rant. It's old age that causes it!

[ShadesOfMarble]

For my part, I'd much rather get a device that operates reliably within it's rated parameters that has been designed from the start to be efficient rather than buggering around to try to squeeze out more performance. Intel don't design 'to the limit', that's why their chips can be overclocked so readily, the engineers have built in a margin for error. The Bitcoin asic designers don't seem to grasp this point which makes me high suspicious of some of the 'credentials' trumpeted on their websites.

I don't think you can compare Intel (et al.) CPUs with Bitcoin mining hardware. In the mining world, it's crucial to have your equipment up and running in the shortest possible time and to squeeze as much performance out of it as possible, as mining equipment becomes obsolete within months, usually. You actually don't need your equipment to work longer than, say, a year. But you want your Intel CPU to work longer than a year...

[Syke]

I don't think you can compare Intel (et al.) CPUs with Bitcoin mining hardware. In the mining world, it's crucial to have your equipment up and running in the shortest possible time and to squeeze as much performance out of it as possible, as mining equipment becomes obsolete within months, usually. You actually don't need your equipment to work longer than, say, a year. But you want your Intel CPU to work longer than a year...

Exactly. 2013 was all about getting the gear up and running as fast as possible to maximize return in the first 3 months. 2014 will be about the same. Eventually, maybe 2015, miners will need to care about long lasting hardware.

[brontosaurus]

For my part, I'd much rather get a device that operates reliably within it's rated parameters that has been designed from the start to be efficient rather than buggering around to try to squeeze out more performance. Intel don't design 'to the limit', that's why their chips can be overclocked so readily, the engineers have built in a margin for error. The Bitcoin asic designers don't seem to grasp this point which makes me high suspicious of some of the 'credentials' trumpeted on their websites.

I don't think you can compare Intel (et al.) CPUs with Bitcoin mining hardware. In the mining world, it's crucial to have your equipment up and running in the shortest possible time and to squeeze as much performance out of it as possible, as mining equipment becomes obsolete within months, usually. You actually don't need your equipment to work longer than, say, a year. But you want your Intel CPU to work longer than a year...

Thanks for your input. The only comparison I was trying to make was that you should design systems, Bitcoin ones included, with reliability as the priority. I appreciate what you say about squeezing out every extra bit of performance, but how do you know that the hardware is actually working correctly 100% of the time? Most semiconductor companies making a commercial chip subject it to a process called 'characterisation' to determine the performance 'envelope' of the device to make sure that it has sufficient margin to be consistently reliable. The asic rig companies ignore all this to get product out sooner, but that doesn't necessarily mean that what's shipped lives up to it's publicity.

For instance, I've never yet seen a bitcoin asic design with any kind of error correction or detection in it's pipelines, yet it's common practice for 'mission critical' systems. What mission could be more critical than making money?

[aerobatic]

Hi Aerobatic, you are of course quite correct in that voltage affects the power dissipation, but in the case of SHA256 it would be very unusual to increase the supply voltage - as the games do to get faster running cpu's - because the pipelines can generally switch much faster than they are clocked at. In SHA256 the problem is that almost every transistor in the pipelines switches every clock cycle - the real problem is how to get rid of the heat that's generated without having to increase the die size (and so wasting silicon area), I'm sure I remember the guy from Bitfury posting stuff some time ago about lowering the supply voltage on his asic to run cooler, which on the face of it sounds sensible but then that has a knock on effect on threshold voltages and that in turn can result in unreliable operation due to increased susceptibility to noise.

For my part, I'd much rather get a device that operates reliably within it's rated parameters that has been designed from the start to be efficient rather than buggering around to try to squeeze out more performance. Intel don't design 'to the limit', that's why their chips can be overclocked so readily, the engineers have built in a margin for error. The Bitcoin asic designers don't seem to grasp this point which makes me high suspicious of some of the 'credentials' trumpeted on their websites.

I chose my username because my colleagues do view me as a bit of a dinosaur, but that's because I started out designing things when you only had a few tens of thousands of transistors to design with, not hundreds of millions and so you had to be very creative with your resources. I like doing things right that work the way they were specified first time around. A lot of the technospeak from the rig vendors make me shudder and I wish to goodness someone would come along with a mining product minus the bullshit, fantasy project timescales but with some solid engineering behind it.

As an example of what bugs me, I had a look recently at Cointerra's Team, and to my astonishment found they have a 'Chief Crytographic Advisor'. Why would they employ such a guy? Don't the engineers understand SAH256? Nothing against Dr.Hanke, I'm sure he's very good at what he does but if I was a prospective rig customer I'd much rather see a VP in their team that actually had some experience of volume product manufacturing because the chip design for SHA256, whether anyone wants to admit it or not is fixed and well within the capabilities of most EE graduates. So the chip design is a given. What's proven not so easy is the actual system integration and product engineering part.

Nothing against Cointerra by the way, they seem less suspect than most of the other suppliers but they're still way too expensive for what's on offer and are excluding a huge number of people who would like to participate in mining.

Sorry for the rant. It's old age that causes it!

hi Bronto... have to disagree with you there.   There's plenty of 'innovation' that goes into designing these high end bitcoin mining asics.  Those that are just doing a textbook SHA256 design or are licensing an sha256 block and cookie cutting their chip design are now suffering from extremely poor performing asics that consume too much power per GH and dont fit many hashing units on their die.  They have no way to differentiate their products.  whereas the guys who are doing it right, are getting huge improvements in power consumption, performance, and size efficiencies.

i think both bitfury, knc, hashfast and cointerra.. would say that they have applied significant r&d and innovation to their respective designs.  They're not just dialling in how many hashing units are in the die.. nor whether to use a single cycle pipelined hash or an iterative one...   though there are designs that use either style... instead, theyre making fundamental power, die size and performance optimisations to the architecture and implementation of the hash itself.. and the ways to keep the pipelines full.   Bear in mind that any improvements in the power consumption mean you can hash faster (no pun intended) since youve got more headroom before hitting the thermal limits of the package... and any improvements to the die size mean you can fit more hashing units in the same space, which has obvious advantages.

some of the special sauce is in architecture and rtl design.. and some of it is in back end layout... optimising the data paths and making the most of the process available.  

as for why companies might employ a crypto consultant like Dr Timo Hanke.. well, i dont think theyd necessarily be using him to invent new crypto algos.. but instead someone of his background and skillset can add value in designing the architecture and software to make the best chip.  In his case, he's also a very strong software engineer and is consulting (he's based in germany) on their software and architecture effort.  Im sure all other bitcoin mining asic companies employ or consult with someone similar, though not necessarily from a crypto background.

If you really think there's no engineering innovation possible, then there's no point designing a new bitcoin asic... and you might as well just license the ip and subcontract the whole lot.  Some companies did that.  look where they are right now (VMC/AMC... im thinking of you)

i actually really like analyzing what happens in this bitcoin mining asic field... as its the perfect HPC arena.  Its a microcosm of new technologies designed in record time.  It really focusses many aspects of engineering from asic to system design.. with significant attention to power consumption and cooling technologies.   these guys are doing state of the art stuff, that may perhaps be teaching lessons to the HPC and Intels of the world.   Certainly most bitcoin mining asics have been designed and fabbed in record time and many of these companies have broken world records for how to go from concept to silicon in literally single digit numbers of weeks...   if only the rest of the silicon world worked on those timescales.

i should also re-iterate what someone else said...  that in bitcoin mining, since performance is the ultimate goal, and since the life of the hardware is very limited (months, not years)...  the hardware designs are optimised to go for extreme overclocking and maximum performance.. at the bleeding edge.  if they didnt, they wouldnt have competitive performance.  thats the nature of the beast.  if you want it to run cool for hours, im sure you can do that.  but it wont generate that many coins!


-- Jez

[ShadesOfMarble]

The only comparison I was trying to make was that you should design systems, Bitcoin ones included, with reliability as the priority.

That's true for almost all systems, that's right. But "almost" is the key here. If I had to choose between an ASIC delivered now with an expected lifespan of 6 months and the same ASIC (same as in same performance, power consumption and price) delivered in 6 months with a lifespan of 10+ years, I would choose the former. Wouldn't you?

For instance, I've never yet seen a bitcoin asic design with any kind of error correction or detection in it's pipelines, yet it's common practice for 'mission critical' systems. What mission could be more critical than making money?

Because it is not necessary. If you ever saw the screen output of miner software like cgminer, you will notice a counter for hardware errors. So there is your error detection. There is no need for correction, as you will just a throw away a invalid share. You actually do know how many errors your ASIC makes, and as long as it's low (like 1%), there is no problem. 1% HW errors means you are losing 1% of your hashing power.

There is really nothing worse that could happen with hardware errors on Bitcoin mining hardware. It's not like you are transfering money to someone else if your ASIC returns an invalid share.

[aerobatic]

The only comparison I was trying to make was that you should design systems, Bitcoin ones included, with reliability as the priority.

That's true for almost all systems, that's right. But "almost" is the key here. If I had to choose between an ASIC delivered now with an expected lifespan of 6 months and the same ASIC (same as in same performance, power consumption and price) delivered in 6 months with a lifespan of 10+ years, I would choose the former. Wouldn't you?

For instance, I've never yet seen a bitcoin asic design with any kind of error correction or detection in it's pipelines, yet it's common practice for 'mission critical' systems. What mission could be more critical than making money?

Because it is not necessary. If you ever saw the screen output of miner software like cgminer, you will notice a counter for hardware errors. So there is your error detection. There is no need for correction, as you will just a throw away a invalid share. You actually do know how many errors your ASIC makes, and as long as it's low (like 1%), there is no problem. 1% HW errors means you are losing 1% of your hashing power.

There is really nothing worse that could happen with hardware errors on Bitcoin mining hardware. It's not like you are transfering money to someone else if your ASIC returns an invalid share.

.. and there's some schools of thought that are operating the hardware at beyond its tolerances, to hit even higher hash rates than the specs allow in exchange tolerating even higher percentages of HW errors, in exchange for faster performance that more than makes up for the error loss.  Apparently, the bitfury designer makes use of this.

talking of bitfury thats another example of lots of innovation.  not only did he do a full custom design (unheard of in most asic design these days)... but he also put in unusual cool features like the ability to operate in series... for instance, running at 12 volts, with 12 bitfury chips in series, would effectively mean each bf chip gets 1volt...   thus saving the need for dc/dc converters.   a brilliant innovation (though a really hacky one that has potential to go very wrong).  but whether it works out well or not, the point is that there is genuine innovation and exciting experiments going on in bitcoin mining asics, any one of which could end up being a competitive feature for its designer to have a better chip than the rest...  or like hashfast's use of a double-hasher unit... (saving some die space by re-using common parts of hash engine and doing two hashes at the same time on different parts of the nonce)

[brontosaurus]

The only comparison I was trying to make was that you should design systems, Bitcoin ones included, with reliability as the priority.

That's true for almost all systems, that's right. But "almost" is the key here. If I had to choose between an ASIC delivered now with an expected lifespan of 6 months and the same ASIC (same as in same performance, power consumption and price) delivered in 6 months with a lifespan of 10+ years, I would choose the former. Wouldn't you?

For instance, I've never yet seen a bitcoin asic design with any kind of error correction or detection in it's pipelines, yet it's common practice for 'mission critical' systems. What mission could be more critical than making money?

Because it is not necessary. If you ever saw the screen output of miner software like cgminer, you will notice a counter for hardware errors. So there is your error detection. There is no need for correction, as you will just a throw away a invalid share. You actually do know how many errors your ASIC makes, and as long as it's low (like 1%), there is no problem. 1% HW errors means you are losing 1% of your hashing power.

There is really nothing worse that could happen with hardware errors on Bitcoin mining hardware. It's not like you are transfering money to someone else if your ASIC returns an invalid share.

Sorry, that's not real time error detection. It would be impossible for a piece of software to tell if the hardware is making an error in any stage of a pipeline in real time unless it puts in a known value to be hashed and looks at the digest that comes out, but that's a one-off scenario.  Otherwise the software would have to calculate the full hash itself every time which would be slow as hell.

[brontosaurus]

The only comparison I was trying to make was that you should design systems, Bitcoin ones included, with reliability as the priority.

That's true for almost all systems, that's right. But "almost" is the key here. If I had to choose between an ASIC delivered now with an expected lifespan of 6 months and the same ASIC (same as in same performance, power consumption and price) delivered in 6 months with a lifespan of 10+ years, I would choose the former. Wouldn't you?

For instance, I've never yet seen a bitcoin asic design with any kind of error correction or detection in it's pipelines, yet it's common practice for 'mission critical' systems. What mission could be more critical than making money?

Because it is not necessary. If you ever saw the screen output of miner software like cgminer, you will notice a counter for hardware errors. So there is your error detection. There is no need for correction, as you will just a throw away a invalid share. You actually do know how many errors your ASIC makes, and as long as it's low (like 1%), there is no problem. 1% HW errors means you are losing 1% of your hashing power.

There is really nothing worse that could happen with hardware errors on Bitcoin mining hardware. It's not like you are transfering money to someone else if your ASIC returns an invalid share.

.. and there's some schools of thought that are operating the hardware at beyond its tolerances, to hit even higher hash rates than the specs allow in exchange tolerating even higher percentages of HW errors, in exchange for faster performance that more than makes up for the error loss.  Apparently, the bitfury designer makes use of this.

talking of bitfury thats another example of lots of innovation.  not only did he do a full custom design (unheard of in most asic design these days)... but he also put in unusual cool features like the ability to operate in series... for instance, running at 12 volts, with 12 bitfury chips in series, would effectively mean each bf chip gets 1volt...   thus saving the need for dc/dc converters.   a brilliant innovation (though a really hacky one that has potential to go very wrong).  but whether it works out well or not, the point is that there is genuine innovation and exciting experiments going on in bitcoin mining asics, any one of which could end up being a competitive feature for its designer to have a better chip than the rest...  or like hashfast's use of a double-hasher unit... (saving some die space by re-using common parts of hash engine and doing two hashes at the same time on different parts of the nonce)

Hi Jez, it's good to have this discussion to get different points of view, so thanks for taking the time to put in yours.

I must strongly disagree with you on the subject of sha256 'architectures' - despite some of the nonsense that various asic mining companies try to promote, there is one and only one. You can't change it, period. When I look at all the various offerings, they're essentially using the exact same pipelines with more or less identical gate counts, sha256 can't use any look-ahead or predictive techniques, otherwise the academic community - who by and large are a great deal smarter than most commercial designers - would have found it out along time ago.

There are some very clever design techniques that can be applied, but they're old hat - I used the same ones 20 years ago, so if there's significant R&D it's on how to spend the vast profits the rig manufacturers stand to make.

Try doing some research on the subject, I think you will find it genuinely interesting and rewarding.

As for the Bitfury guy and his 12 in a line solution - turns my blood cold. Gave me a good laugh, though. (eventually).

Incidentally, got a very interesting email from my friend in the UAE today.

[RoadStress]

....
Incidentally, got a very interesting email from my friend in the UAE today.

What is it about?

[aerobatic]

Hi Jez, it's good to have this discussion to get different points of view, so thanks for taking the time to put in yours.

I must strongly disagree with you on the subject of sha256 'architectures' - despite some of the nonsense that various asic mining companies try to promote, there is one and only one. You can't change it, period. When I look at all the various offerings, they're essentially using the exact same pipelines with more or less identical gate counts, sha256 can't use any look-ahead or predictive techniques, otherwise the academic community - who by and large are a great deal smarter than most commercial designers - would have found it out along time ago.

There are some very clever design techniques that can be applied, but they're old hat - I used the same ones 20 years ago, so if there's significant R&D it's on how to spend the vast profits the rig manufacturers stand to make.

Try doing some research on the subject, I think you will find it genuinely interesting and rewarding.

As for the Bitfury guy and his 12 in a line solution - turns my blood cold. Gave me a good laugh, though. (eventually).

Incidentally, got a very interesting email from my friend in the UAE today.

we will just have to beg to differ about whether there's any innovation going on in the bitcoin mining asic world.  i say there is, you say there isn't.   neither one of us is capable of changing the others' mind so lets move onto less controversial subjects, like religion and politics.   ;-)

ok.. so i was in the uae only a few days ago.. had family hols in dubai.  they neglected to tell me about any new bitcoin mining they were doing...  so what did they tell you?

[ShadesOfMarble]

Sorry, that's not real time error detection. It would be impossible for a piece of software to tell if the hardware is making an error in any stage of a pipeline in real time unless it puts in a known value to be hashed and looks at the digest that comes out, but that's a one-off scenario.  Otherwise the software would have to calculate the full hash itself every time which would be slow as hell.

If the error happens in a way that the last 8 bits (IIRC) of the hash are still zero, so the software cannot easily detect it as an error, the pool will still reject your share. If the pool didn't re-calculate the share you submit, you could submit loads of invalid shares and make money this way... So, it's really not possible to do any harm with "faulty" Bitcoin mining hardware.

Bitcoin mining hardware manufactures might act in a way that makes some engineers cry - but, hey, it works well. VERY well. So I really don't see what's wrong with it. (Still, I get your point.)

[brontosaurus]

we will just have to beg to differ about whether there's any innovation going on in the bitcoin mining asic world.  i say there is, you say there isn't.   neither one of us is capable of changing the others' mind so lets move onto less controversial subjects, like religion and politics.   ;-)

ok.. so i was in the uae only a few days ago.. had family hols in dubai.  they neglected to tell me about any new bitcoin mining they were doing...  so what did they tell you?

Look back at my post #1360 in this thread - it was in relation to the group of guys and their $300/ 200GH machine. I'll pm you later.

[gmaxwell]

Sorry, that's not real time error detection. It would be impossible for a piece of software to tell if the hardware is making an error in any stage of a pipeline in real time unless it puts in a known value to be hashed and looks at the digest that comes out, but that's a one-off scenario.  Otherwise the software would have to calculate the full hash itself every time which would be slow as hell.

If the error happens in a way that the last 8 bits (IIRC) of the hash are still zero, so the software cannot easily detect it as an error, the pool will still reject your share. If the pool didn't re-calculate the share you submit, you could submit loads of invalid shares and make money this way... So, it's really not possible to do any harm with "faulty" Bitcoin mining hardware.

No, control software re-validates the shares that are returned from the miner, just like the pool does. The number you were looking for was 32 bits, as thats the definition of diff1 and also all the hardware is checking... if the hardware makes an error and the error is still a valid diff1 share, you're right— the controller won't notice. But it's very unlikely since diff1 is 32 bits.

[hno]

There is only one error which goes by undetected by the mining software and it's a not-found valid nonce. But the end effect of such error is nothing more than slightly lost hash rate, i.e the same as hashing completely wrong and returning invalid nonces.

So yes bitcoin mining is very different from CPUs when it comes to error tolerances. The silicon is designed with performance as priority and fault tolerance is spent on... perforance by multiple redundancy.  If you look at a bitcoin mining asic then it has a very large number of hashing cores, each relatively simple. It is expected that likely not all parts of all chips will function optimal, but that is outweighted by the parts that do work, all together delivering bitcoin hashing performance.

Being a competitor I won't comment on the validity of Hashfast performance numbers other than that their numbers do not match with our thermal calculations. Will be very interesting to see what is reported in the field when delivered to customers outside the lab bench.

[DPoS]

maybe Luke Jr can give some insight??   He's probably between a rock and a NDA though

[RHA]

Being a (...)

Hno, nice to see you here. (#kncminer is so volatile...)
The last pages of this thread turned to be old good technical discussion, which surely has attracted you.