Pages:
Author

Topic: HashFast launches sales of the Baby Jet (Read 119626 times)

sr. member
Activity: 434
Merit: 250
They are in full legal lock-down mode. Say nothing or do nothing that can be used against you later. We're just along for the ride now. See you all on Jan 1st. I hope to get better news earlier, but I've hoped twice before and been burned. Thanks BFL, Avalon, and now HF.

I don't think it's that, I think it's that they just kinda don't know what to do, and the missteps with Taco and the silly (and ill-timed) drawing for people putting ads in their sigs show the lack of a coherent communication plan. 

Dealing with this situation is different than selling bondage or fisting pron, as our marketing man is probably finding out!  I don't mean that too meanly, after all, it's a really strange situation, and I can't think of any especially valuable prior experience he could have had to help deal with bitcoin miner preorder fumbles, so I guess pron sales are as (in)applicable as anything else.  (Except maybe crisis communication.)

I don't think they have to come on here and respond to every bitchy post, but having said that, Amer has a number of good suggestions, even if some of them veer too far into the "promotional" aspect rather than providing information.  Hashfast can certainly do a better job getting the facts out there, and doing so with some regularity. Personally, I'm not so much interested in success stories ... except maybe new information that shows how they are addressing and overcoming delays.  Data points. Stuff that speaks for itself.  Not any spun items. Why not commit to a factual update every week, with some of the industry-specific insight information that Amer suggests (i.e. for those of us that aren't personally into hardware design)?
No, it is exactly that. Reading over all their latest communications, you can easily tell  they have passed and sanitized by a lawyer first. They have carefully worded everything as to not take any liability, past future and present. Are my claims so far fetched? This is the company that is NDA'ed out the asshole.

Oh how I wish I wasn't right.
legendary
Activity: 2856
Merit: 1520
Bitcoin Legal Tender Countries: 2 of 206
January 29, 2014, 12:04:01 PM
Why must you bump this thread..

cause you should pay 34.7 mBTC to cedivad.  Grin
hero member
Activity: 991
Merit: 500
January 29, 2014, 10:05:21 AM
Why must you bump this thread..
legendary
Activity: 1596
Merit: 1100
legendary
Activity: 1596
Merit: 1100
RHA
sr. member
Activity: 392
Merit: 250
January 11, 2014, 08:24:10 PM
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. Smiley
sr. member
Activity: 462
Merit: 250
January 03, 2014, 06:44:34 PM
maybe Luke Jr can give some insight??   He's probably between a rock and a NDA though

hno
newbie
Activity: 2
Merit: 0
January 02, 2014, 07:32:25 PM
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.
staff
Activity: 4284
Merit: 8808
January 02, 2014, 04:33:28 PM
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.
sr. member
Activity: 441
Merit: 250
January 02, 2014, 02:06:33 PM


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.
donator
Activity: 543
Merit: 500
January 02, 2014, 01:39:57 PM
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.)
hero member
Activity: 702
Merit: 500
January 02, 2014, 01:31:13 PM

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?

legendary
Activity: 1904
Merit: 1007
January 02, 2014, 01:27:19 PM
....
Incidentally, got a very interesting email from my friend in the UAE today.

What is it about?
sr. member
Activity: 441
Merit: 250
January 02, 2014, 01:12:01 PM
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.
sr. member
Activity: 441
Merit: 250
January 02, 2014, 12:48:03 PM
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.
hero member
Activity: 702
Merit: 500
January 02, 2014, 12:19:28 PM
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)

donator
Activity: 543
Merit: 500
January 02, 2014, 12:10:29 PM
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.
hero member
Activity: 702
Merit: 500
January 02, 2014, 11:35:18 AM

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
sr. member
Activity: 441
Merit: 250
January 02, 2014, 11:32:41 AM
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?
Pages:
Jump to: