Hi,
I am wondering how much is the VAT of the S1 in the UK. Im not sure how the VAT works, because Im not british. Since I'm from Hong Kong only in the UK for study, can I be exempt from paying VAT?
Thanks
No. You have to pay it unless you are only here for a genuine holiday or business trip. Then you can claim back the VAT paid when you leave the UK - there are dedicated desks at the airports. But if you get one sent to another country from the UK, you don't pay vat, but you might have to pay import duty . |
|
|
|
|
What everyone forgets is that an efficient 28nm design will, for sha256 at least, outperform an inefficient 20nm one. KNC, for example, did a conversion from an FPGA for their 28nm design - soon to be ported to 20nm, and if you calculate back from their watts/GH metric, you can see that their pipelines must contain about 35 - 50% more switching gates than normal. So what's the advantage in paying twice as much NRE and probably three times as much for the silicon? This to be expected from a conversion.
Likewise, in certain circumstances a full custom 40nm design could easily outperform a 28nm (or even 20nm) design done at gate level, but it's an order of magnitude more difficult to implement unless you really know what you're doing, and not many asic designers nowadays have the necessary skills.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
I would guess it is going to get really hard to get a decent ROI until the rig vendors start charging reasonable prices per Gigaghash for their products. Some of the margins they earn are obscene, especially when they have the advantage of getting full payments up front.
But until you get suppliers that look at making rigs as a ongoing product rather than a ticket to easy riches (at others expense) then this is reality miners face. With the amount of product that's going to get dumped onto the network by the end of March - probably in excess of 180,000TH - you'll be lucky to break even paying $3/GH for your hardware.
And it's only going to get worse from there.
Whether we like it or not, its a "free market". And yes, most mining producers look very short term, certainly not for repeat customers. Maybe this will change, but how can one mining company change on its own. Its products will start to look "expensive" compared with others, and not sell. Since I don't mine I suppose I shouldn't be moaning on about the price of rigs. It's just that the short term mentality makes me mad, Bitcoin depends on the participation of lots of people to make it work, not just the ones who have the money to start with. It's more than possible for a rig supplier to make products for a few hundred dollars that can give $/GH less than 2, and I suspect that the market for said devices would be huge - not for a 'one shot' product but for many years to come if done right. But I guess that greed rules over common sense! |
|
|
|
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! |
|
|
|
I'm sorry if I sound a little cynical about all this, but Hashfast's end-of-2013 announcements seem a bit odd, to put it mildly.
Firstly, they claim chip performance of 'up to' 664GH/sec. Real engineers don't do 'up to', they quote maximum and minimum and specify under
what conditions each is valid.
Secondly, they say this performance test was " conducted by running a single GN die directly from bechtop power supplies, as opposed to powering it through the module". I'm assuming by die they mean one of the 4 functional blocks. Why not use the actual system power supplies? Something wrong with them?
Thirdly, because "This approach allows us to obtain data about what the ASIC itself can do, without having to make subjective estimates regarding the efficiency of the power supply on the module. However, doing things this way also has it’s own set of disadvantages.For example, the reason we are “only” able to announce a top speed of 664 Ghash per chip is purely because that’s the point at which we ran out of power to put through the chip. " then that means their chip, with all four cores running will use 664GH x 0.67w/GH = 442 watts, all from a silicon ares of 664/2 (their figures of 2GH/mm2 of silicon), ie 332 mm2. This, frankly, is impossible. You would need a heatsink with a NEGATIVE thermal coefficient to keep the die junction temperature below 75 degrees C. As far as I'm aware, none exist.
Can't they afford a decent PSU?
Anyone else care to add their observations?
both your assumptions could be argued arent safe assumptions... first, since hf were testing just one die in isolation (presumably with the others turned off) then they were specifically benchmarking one die and it should be treated more as academic interest than a marketing statistic. Its an interesting and exciting statistic but it ignores the reality of the power supply, the thermal characteristics of operating 4 dies concurrently in the same package, and presumably also avoiding the thermal limits of the package & cooling system that would be a different scenario with all four dies turned on in one package. Its a very exciting marketing statistic, but by testing one die in isolation and then presumably multiplying the result by four... does that still count as a legitimate benchmark for what the system is capable of? I say YES, provided all four dies, when run together can also achieve the same number... but conversely if that cant be achieved with all four dies, then testing one die in isolation and multiplying the result by four could be argued that its an artificial performance metric of academic interest only. Much the same as if you have a 4 core intel cpu and turn off 3 of the cores, that the remaining single core also will run much faster than when all 4 cores are turned on together. Of course, they could redesign the substrates and package and just put one die in each package... and that would allow them a board re-design.. and then have 4 chips in a baby jet instead of one big one... (which follows the Bitmine argument that using multiple smaller chips may achieve a better outcome than using fewer bigger chips). is it valid to measure the performance of just one die, and then multiply the result by 4 to give you what the total of 4 dies wouldve couldve done (.. in a perfect world where they had infinite power and cooling available to them)... when those 4 dies, in the same package, when run together, may not be able to achieve the same result? And, i should stress, if it CAN.. thatd be awesome and extremely impressive...! then there's the issue of the two stats. the two data points. The 664GH performance claim, And the 0.67w/GH power consumption are two separate stats. Hashfast didnt link them together. You did (incorrectly assuming they were done using the same conditions). HF didnt claim that when they were running at 664GH they were ALSO only consuming 0.67w/gh.. though thatd be simply fantastic if true! Those two are independent stats and its safer to assume that the 0.67w/gh ultra low power achievement was probably achieved when running at a lower voltage setting than when when the benchmark was showing a die running at the 664gh (/4) equivalent performance achievement. also, as they also identified... the tests were achieved when running off a bench power supply, without the inefficiencies of the dc/dc converters nor the limits of atx power supplies... so its an isolated measure of performance. Its testing the die on its own, but not testing the dies, in situ in the system as it will be supplied. we of course would love to know what the die will do on its own... but the more important statistic for us as customers is what the chip will do, when its on a production board using production power supplies and production cooling... and though its exciting to hear what it can do (with the wind behind it) in the lab, connected to a bench power supply, isolated from the other dies. thats a special case scenario that isnt necessarily representative of what will be achieved in the real world use case. 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. 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. |
|
|
|
|
I would guess it is going to get really hard to get a decent ROI until the rig vendors start charging reasonable prices per Gigaghash for their products. Some of the margins they earn are obscene, especially when they have the advantage of getting full payments up front.
But until you get suppliers that look at making rigs as a ongoing product rather than a ticket to easy riches (at others expense) then this is reality miners face. With the amount of product that's going to get dumped onto the network by the end of March - probably in excess of 180,000TH - you'll be lucky to break even paying $3/GH for your hardware.
And it's only going to get worse from there.
|
|
|
|
Thanks for sharing, brontosaurus. It's really interesting.
Very kind of you to say so, thanks. I have no personal interest in Hashfast or any other supplier of rigs, but I really don't like the way that some companies assume that their audience will swallow any old technical rubbish they serve up. I appreciate that a lot of people don't know a lot about the detailed technology and that's why forums are good for everyone. Plus there is a lot of accumulated knowledge out there - nobody knows it all and we can all learn from others experience, the rig companies included. Companies wanting customer's money on trust have an implicit duty to provide them with proper specifications - not one off measurements or guesses. By all means give them estimated performance but base it on proper maths and technical parameters and specify HOW you have arrived at your data. |
|
|
|
664GH x 0.67w/GH = 442 watts, all from a silicon ares of 664/2 (their figures of 2GH/mm2 of silicon), ie 332 mm2. This, frankly, is impossible. You would need a heatsink with a NEGATIVE thermal coefficient to keep the die junction temperature below 75 degrees C.
Not sure what makes you say that. 442W/332mm˛= ~1.3W/mm˛. Thats not enormous. A typical highend AMD or Intel desktop CPU has comparable thermal density, and in fact, for an x86 chip most of that power is concentrated in a few hotspots that are just a few mm˛. Not that 75+C should be a problem anyway. I do find it funny they claim measurements of their PSU would somehow be "subjective". Well, it's all to do with the thermal impedance of the chip (theta jc). That determines how many watts can be transferred from the die junction to it's 'case', or in this case the back of the die, per degree centigrade rise of the junction temperature. An Intel Core i7-970 cpu has a die area of 239 mm2 and a design power dissipation of 130W, approximately 0.54w/mm2 averaged across the whole die area. Don't know about you, but I hold Intel's engineering in very high esteem, they know how to make ultra high volume consumer silicon products reliable. So when a 'nobody' suggests than they can get 2.5x better thermal performance per square mm, I'm more than a little concerned. 1.25x, maybe. Just. Of course chips can exceed junction temperatures of 75 degrees C, power devices go up to 150 routinely but they're built with processes designed to operate at this level. |
|
|
|
Yes, looks like HF made some stealth-edits to those specs already: Original: http://web.archive.org/web/20140101023059/http://hashfast.com/were-shipping-2013/The Golden Nonce is:
The fastest Bitcoin mining chip in the world today — up to 735 Ghash/s per chip!
The most energy efficient mining chip in the world today — 0.59 watts per Ghash when run for maximum efficiency
The most silicon-efficient chip in the world — producing up to an astonishing 2.27 Ghash out of every square millimeter of silicon!
We couldn’t be prouder of these results – and can’t wait to see what the community can do with it. Edited: http://hashfast.com/were-shipping-2013/The Golden Nonce is:
The fastest Bitcoin mining chip in the world today — up to an unprecedented 664 Ghash/s per chip!
The most energy-efficient — down to 0.67 watts per Ghash when run for maximum efficiency!
And the most silicon-efficient — Each square millimeter of silicon on the GN chip produces an astonishing 2+ Ghash!
We couldn’t be prouder of these results – and can’t wait to see what the community can do with it. Well, lets be honest - if you can beat the laws of thermodynamics then specs become meaningless. So why bother tying yourself down? If I was a Hashfast customer, I'd be more than a little annoyed that the public seem to get 'new' information at the same time I do. If I've paid over my cash, I'd like to get the info first. |
|
|
|
I'm sorry if I sound a little cynical about all this, but Hashfast's end-of-2013 announcements seem a bit odd, to put it mildly. Firstly, they claim chip performance of 'up to' 664GH/sec. Real engineers don't do 'up to', they quote maximum and minimum and specify under what conditions each is valid. Secondly, they say this performance test was " conducted by running a single GN die directly from bechtop power supplies, as opposed to powering it through the module". I'm assuming by die they mean one of the 4 functional blocks. Why not use the actual system power supplies? Something wrong with them? Thirdly, because "This approach allows us to obtain data about what the ASIC itself can do, without having to make subjective estimates regarding the efficiency of the power supply on the module. However, doing things this way also has it’s own set of disadvantages.For example, the reason we are “only” able to announce a top speed of 664 Ghash per chip is purely because that’s the point at which we ran out of power to put through the chip. " then that means their chip, with all four cores running will use 664GH x 0.67w/GH = 442 watts, all from a silicon ares of 664/2 (their figures of 2GH/mm2 of silicon), ie 332 mm2. This, frankly, is impossible. You would need a heatsink with a NEGATIVE thermal coefficient to keep the die junction temperature below 75 degrees C. As far as I'm aware, none exist. Can't they afford a decent PSU? Anyone else care to add their observations? |
|
|
|
It's been a while since I looked on this forum. I'm really disappointed to read about what's happened with Hashfast as it looks as though a lot of trusting customers may end up losing a fair portion of their hard earned money. That's inexcusable as it would seem that HF got more than enough funding to develop a 28nm chip and build their customers' systems. How much they took out of the company in expenses and salaries is anyone's guess.
It's also going to make life very difficult for any new suppliers that might come along, and that leaves a bigger problem.
I've always felt that mining rigs are grossly overpriced, even at the current lowest offering of $3 per gigahash. It's simply not competitive with what the 'invisible' mining corporations can build capacity for, ie less than $1.50/GH. Think I'm kidding? Well, let me give you some insight....
Recently a previous colleague of mine got in contact. He works for a group of Venture Capitalists in the UAE and had been approached by some of my fellow countrymen with a business plan for the development of a 'consumer' electronic system - he wouldn't tell me what the application was as it was all under Non Disclosure agreements, but basically he asked me to check out their technical plan -edited, of course - and their costings. When I went over the facts and figures it became obvious that the plan centered on a custom silicon device; from the power specs, huge heatsinks and unusually low clock speeds it spelt out SHA256, or 'transaction engine' as my contact called it.
To cut to the chase, it was a very comprehensive and well thought out technical plan with realistic timescales, although I thought some of the costings were a bit on the pessimistic side. It's a real pity the plan I got was so heavily edited as it referred to 'commercial **** companies dominating the market with proprietary systems' and had several graphs and tables totally blacked out. It did, however, refer to a 'Network ##### Rate' and how much they expected it to grow in 2014 - to over 180,000####### by Dec 2014, no less. Whoever these 'companies' were, the guys that wrote the plan seemed to really disapprove of them.
But here's the killer - in their plan a basic system using one 'transaction engine' would retail at 'around' $300 with a manufacturing price well below $200 - I can't give you the real figure - including one-off costs! This system had a 'rated capacity' of 200 billion ###### per second, I'm pretty sure I don't have to spell the rest out.
My UAE contact said his principals were very impressed with the plan, but only if the systems were used in-house, as it were, due to their potential ROI - I never got to see that part. They most certainly didn't want them sold to the public under any circumstances. He hinted that a very attractive offer was made to the group, but was politely declined. He wouldn't tell me who the group were or how to contact them.
It's a very interesting thought - a 200GH miner for $300?? Anyone heard any hint of this?
Anyone who has heard or spoke of it has violated an NDA and risks a lot of fines and possible criminal prosecution. Sounds legit to me. Just to say there's no NDA been violated - the NDA in question related to a specific design implementation and the detailed commercial figures (which I never saw). My contact was very careful to screen his information - if I had never heard of Bitcoin or sha256 I would have assumed this was some kind of encryption device. But thanks for your comment, you're absolutely right that NDA violation can result in heavy civil penalties. |
|
|
|
BlackArrow has 100GH miners for $352,so a 200GH for $300 is very doable,but I don't think we'll see them till June or so.
Had a look at that, but don't understand their design specs. at all: - 1.56Ghz clock? Why so high - it's just making timing problems for yourself and it's unnecessary because: - at 0.5W/GH the chip will be dissipating 50 watts. To get rid of that heat reliably, even with water cooling (which isn't mentioned) you'd need a die size of around 140 square mm, giving a core area of about 127mm. With 'loose' routing that gives around 190 - 200 million gates, so; - their 64 unrolled cores use the equivalent of 3 million gates each. As each core has 2 x 64 stages then; - each stage has 3000000/128 = approx 23k gates per stage. This is 3 - 4 times too many gates per stage. - based on their own power specs then there are about 60 - 70 million gates switching every clock cycle. Even allowing for control circuits that's still 70 million gates used out of an available 190 - 200 million (loosely routed at that) It doesn't make sense. Why not put in more cores and lower the clock speed? This design really doesn't sound right at all, or someone has seriously screwed up. |
|
|
|
|
It's been a while since I looked on this forum. I'm really disappointed to read about what's happened with Hashfast as it looks as though a lot of trusting customers may end up losing a fair portion of their hard earned money. That's inexcusable as it would seem that HF got more than enough funding to develop a 28nm chip and build their customers' systems. How much they took out of the company in expenses and salaries is anyone's guess.
It's also going to make life very difficult for any new suppliers that might come along, and that leaves a bigger problem.
I've always felt that mining rigs are grossly overpriced, even at the current lowest offering of $3 per gigahash. It's simply not competitive with what the 'invisible' mining corporations can build capacity for, ie less than $1.50/GH. Think I'm kidding? Well, let me give you some insight....
Recently a previous colleague of mine got in contact. He works for a group of Venture Capitalists in the UAE and had been approached by some of my fellow countrymen with a business plan for the development of a 'consumer' electronic system - he wouldn't tell me what the application was as it was all under Non Disclosure agreements, but basically he asked me to check out their technical plan -edited, of course - and their costings. When I went over the facts and figures it became obvious that the plan centered on a custom silicon device; from the power specs, huge heatsinks and unusually low clock speeds it spelt out SHA256, or 'transaction engine' as my contact called it.
To cut to the chase, it was a very comprehensive and well thought out technical plan with realistic timescales, although I thought some of the costings were a bit on the pessimistic side. It's a real pity the plan I got was so heavily edited as it referred to 'commercial **** companies dominating the market with proprietary systems' and had several graphs and tables totally blacked out. It did, however, refer to a 'Network ##### Rate' and how much they expected it to grow in 2014 - to over 180,000####### by Dec 2014, no less. Whoever these 'companies' were, the guys that wrote the plan seemed to really disapprove of them.
But here's the killer - in their plan a basic system using one 'transaction engine' would retail at 'around' $300 with a manufacturing price well below $200 - I can't give you the real figure - including one-off costs! This system had a 'rated capacity' of 200 billion ###### per second, I'm pretty sure I don't have to spell the rest out.
My UAE contact said his principals were very impressed with the plan, but only if the systems were used in-house, as it were, due to their potential ROI - I never got to see that part. They most certainly didn't want them sold to the public under any circumstances. He hinted that a very attractive offer was made to the group, but was politely declined. He wouldn't tell me who the group were or how to contact them.
It's a very interesting thought - a 200GH miner for $300?? Anyone heard any hint of this?
|
|
|
|
|
Hi, thanks for the reply. The Getwork wiki stuff did'nt seem to make sense, but then I can't find a central resource for the detailed mining algorithm.
Got any ideas?
|
|
|
|
|
Sorry if this has been discussed before, but I'm buggered if I can find any threads that give me the answer.
Lots of pages refer to the 'double' sha256 hash in the bitcoin hashing algorithm. However, there seems to be a concensus that most miners only perform the inner hash once, then use the output digest from it again and again; indeed in the Getwork wiki, it actually says:
"running a full SHA256 round is generally inadvisable. Most miners will precompute the SHA256 "midstate" from the first 512-bit chunk of data, and only repeat the 2nd SHA256 round with the final 512-bit chunk (which contains the nonce). "
This may be out of date, and I'd appreciate some advice as to whether it is true or not.
Question is:
When an asic supplier quotes a hashrate, is it based on a 'true' double hash (taking twice the time) or an 'optimised' one as described above? It makes a big difference, I've only so far seem one supplier - Bitfury - mentioning a double hash. I recently came across the stats of the BFl chip - what a monster! 7.5 x 7.5mm2. That gives a useable chip area of 6.9 x 6.9 or 47.6 mm2. On TSMC's 65nm process, raw gate density is about 850k gates/mm2, so this device probably has a utilisation of 80 - 85% or 32 - 34 million gates.
BFL say there are 16 unrolled pipelines on the chip. If they are 'single' length, ie 64 sections, then each section is roughly 33*10^6/(16 *64), ie 32000 gates (or 16000 if a double length pipeline is used). Yes, I know there is control logic and so on, but it shouldn't take more than 500k gates.
Either way, they seem awfully large, by a factor of 10 or 5. Possibly due to an FPGA conversion?
Anyway, this is bugging me. Can anyone help?
Thanks.
|
|
|
|
But it's all too easy to get carried away with lots of pre-order cash and think you're some kind of Bitcoin or Silicon god.
Not really, real engineers are not driven by sales figures. Technical history of asic designs suggests that such arrogance usually gets rewarded with humiliating failure, and your boys in KNC / Orsoc are just about to go down the same sorry path.
Actually, its quite the opposite. Modern ASIC design tools employed by competent engineers usually produce working products. It is only in areas where you are pushing the boundaries of what can be done like GPUs and CPUs that is fraught with failure. SHA256 is not pushing any design boundaries. They are using a well established geometry at 28nm. It should be a layup. BFL pretended to have expertise in ASICs and you should not judge actual engineering firms (OrSoc) by BFL's track record. I mean, no chip testing methodology - just solder them to a board and see if they work?
Please prove that OrSoc & KNCMiner have no chip testing methodology. Links to posts where they say they are "employing no chip testing" would be sufficient. It's really a pity they won't put aside the pseudoscience and speculation and actually publish a proper datasheet for the product, just like any regular chip supplier.
The product does not yet exist. They are being careful about setting expectations. They don't want to "BFL" their customers. Something that tells their purchasers exactly what they are promising and - under European Law - they must then deliver (to buyers in the EU at least). It would certainly close off this thread if they did so, and might silence the skeptics, including me.
I am sure after the product exists, they will document what it can do. Right now they are releasing estimates. You confuse absence of evidence with evidence of absence and post no evidence of your wild conjecture. Please provide citations for your statements in the future. It's kind of obvious from the above that the writer has never actually worked in any commercial company, or, possibly in any company at all. Draw your own conclusions. |
|
|
|
|
Show Posts
