The fastest Jupiters will be from Day 69 of production:

http://www.youtube.com/watch?v=vUs1_OKQRwI#t=150

They will have such a high toggle rate that they will simply blast through the blocks.

Lets not obsess about the efficiency. In the broad scheme of things it doesn't really matter. What matters is TTM (time-to-market or time-to-mine). Wise men know that a birdVrm in the hand is better than two birdsVrms in the bushcatalog. The best Vrm module is probably the one that is the easiest to obtain and has the highest number of alternate suppliers and pin-compatible replacements.

Layout and board fabrication aren't trivial. Layout is actually extremely critical for a repetitive circuit that is simultaneous-switching-noise-limited. If you want to read a recent story take a look at the Enterpoint's Cairnsmore1 thread. They also apparently thought that they know how to put 4 chips on a PCB and look how much time it took for the developers to actually distribute the clock signal properly.


I don't share your concern about the importance of the rise time. I imagine that after the power-on all hashing engines are disabled. Then the SO-DIMM Linux computer will run some tests on the hasher cores and selectively enable and tune the PLL clock synthesizers. Thus the ramp-up could be quite gentle.

Thank you very much, guys. The problem is that there isn't sufficient information to make a meaningfull comment. I don't want to be like Amy Woodward from HashFast and start making some half-assed and quarter-brained assumptions.

If you want a productive subject for the speculation about the PCB, here's a one.

The Vrm requires some way of setting the output voltage. Thus far most of the dedicated mining boards had that voltage set using a pair of surface-mount resistors. That's the cheapest way. The most flexible way would be to have some software-programmable Vrm that can change the output voltage on command. But that is a risky feature to offer when KnC is offering a warranty and everyone will try to overvolt and overclock.

There's also am old-fashioned way: use a trim-pot to set the voltage. During the factory testing tune the voltage with a screwdriver and seal the trim-pot using lacquer, glue or epoxy before shipping to the customers.  To protect against tampering, use some lacquer imported from Chernobyl and test it with a Geiger counter when somebody returns a burned-out miner under the warranty. 

So what would you guys want to see in the shipping configuration:

A) surface-mounted pair of resistors
B) tamper-evident trim-pot
C) software-programmable voltage divider.

Can you explain why would rise time (or any other dynamic load parameter) matter for a miner power supply?

This isn't a CPU or anything similar that will have to cope with the changes of the load.

The bitminer works 100% load all the time. I wanted to write "full throttle", but it is more like http://en.wikipedia.org/wiki/War_emergency_power throttle setting.

I'm quoting this because this is a definition of waste and overkill in a mining operation.

Couple of years ago I read the report from people who did genetic programming experiments on a large scale. Genetic programming is somewhat like CPU mining: 100% CPU use, 0 disk use, very little RAM, very little network.

Firstly, for the $8k budget one could get approximately 100 off-lease but working office desktop computers. The important part: instead of expensive 19" racks you would use the much cheaper industrial warehouse shelving.

No reliable components are required in any of the particular unit. One can swap the failed parts after failure because there isn't any need to save any data or redo the partial computations.

The major areas for savings are:

1) use interruptible industrial electric power instead of the guaranted power. The cost of power where the utility can ask you to turn off your equipment when they need it more than offsets the losses caused by such interruptions.

2) instead of expensive datacenter real estate use the opportunistic short term leases, e.g. the cafeteria/food court areas in some underutilized office buildings. You can agree to move your farm within one week notice without much expense.

3) almost no capital expenses for the UPS. You need one or two UPSes for the private pool server that you are running and some SNMP monitoring concentrator that keeps you informed about the status of your hardware.

4) you completely don't need the advanced security of the data center. Nobody's going to sneak in and copy your hashes. The only real danger is that somebody physically steals the mining hardware. Such a security level is much cheaper, more akin to the security at the construction site.

5) natural convective cooling instead of the forced air conditioning. On the rare occasion that it is really hot outside just underclock/undervolt your farm.

If the bitcoin mining is going to become a low-margin game then the first ones to lose money and go bankrupt will be the ones who put their mining hardware into the conventional data centers.

Edit: several typos fixed

Thanks for the compliment.

Unfortunately sitting here in this thread and trying out to straighten out every bit of misinformation would be a full time job and a very boring one. So I was trying to come up with some sort of general help for the readers here. The advice of the type "get an EE degree" is completely impractical.

When "Who moved my cheese?" was published and became an instant hit I keept saying that the book is so exagerrated that it becomes an unintentional comedy. Now I know that this book was not an exagerration.

So my advice is go read that book. It is very short, a fast reader can read it while having a large coffe and a croissant in a bookstore. You can buy it or borrow from a library.

It is essentially a pop-psychology piece, but once you read it you'll understand that it is a perfect alegory for a person like kingcoin. For 10 to 20 years kingcoin knew where and how to get his cheese. First he had to slice it by hand; now he has an ATPG tool to slice it for him. But suddenly Bitcoin ASICs came and moved his cheese. That triggered a psychological defense mechanism and turned him to a concern troll.

Bitcoin had already moved the cheese for many professionals. It will move it for many others. So if you plan on being involved in Bitcoin go read that book. It will help you to recognize the people who suffer from the "moved-cheese syndrome" by the easily recognizable psychological symptoms.

Well, as I thought: Office Space 2 will have a character named Milton the test collator who will constantly mumble "scan insertion", "ATPG", etc.

But here's the usefull information for the future. Yield in semiconductor industry is defined as a percentage of the dies that are "good" as opposed to "faulty". The decision between good/bad is binary only when the die contains a single circuit. It obviously applies to a CPU or a similar chip, because such a device contains a JTAG chain that is essentially threading through the every flip/flop on the chip. So if a defect breaks the JTAG chain the die becomes untestable and it isn't even worth to package it.

In the Bitcoin mining ASIC realm currently only ASICminer and Avalon have a single-engine dies. So those are the only two vendors that could conceivably use "yield" as a single percentage value.

Every other Bitcoin mining vendor have multi-engine dies: BFL has 16, bitfury has 756. To make such a chip "fail" you'll have to either kill their control logic or kill all the engines. In all other cases the chip is neither "good" nor "bad", but has some "inbetween" value that is neither 0% nor 100%.

KnC went one step ahead and their die consists of 48 engines and 4 completely independent "control logic" and "power supply" circuits. To make such a chip "fail" you'll have to e.g. kill all 4 contol logic cicuits or 3 control circuts and all 12 engines in the quadrant with the working control logic. If you kill only 11 engines in the "good" quadrant your resulting chip is 2.08% "good" and still has more performace than the 100% "good" Avalon chip.

Semiconductor manufacturing plants are prepared to deal with both types of "yield": the binary "pass/fail" type and the contiguous "quality curve" type. The problem is that the "quality curve" testing is complex and expensive, and therefore used only for the analog or mixed-signal devices. The "pass/fail" test is indeed cheap and quick and it is used for the vast majority of digital devices. But the Bitcoin mining ASIC is a completely atypical digital device therefore applying even a very cheap pass/fail test to it is economically pointless.

I've typed all this because I hope this will be usefull for the readers not well-versed in the electroinic engineering. I don't hope to sway Milton the tester's kingcoin's opinion, but I presume that the concern trolls will like him will keep poping up on this forum for many months, until the ways to characterize yield and test Bitcoin ASIC will become a common knowledge and will move from this subforum to the mining software subforum.

If KnC has at least half of their brains working they will use the no-grade-A chips to run in the hosted environment that they offer. That way somebody who ordered say 400GH/s can have his order fullfilled with two physical boxes of say 200GH/s. No big deal at all to anyone.

In the old, analog, days I would call you a "broken record": there's no music, no feel and no rhythm in your repeating "testing methodology", "timing analysis", etc. I don't know the correct analogy for the modern, all digital, days.

But anyway, lets do a quick survey of the Bitcoin mining ASIC industry. Thus far we had 5 chips that reached the physical implementation. 4 of them (ASICminer,Avalon,BFL,bitfury) all foregone the ususal JTAG and other testing frameworks, and all of them are more or less happily hashing. 1 vendor (helveticoin) had a mining SoC prototype hashing in October of last year. I presume they implemented JTAG and the other testing goodies, because they had an ARM CPU on the chip. Yet they failed to field a marketable mining system so far despite being ahead of the several other vendors.

Thus far the no-JTAG-team bats 1.000 whereas the JTAG-team bats 0.000 . Obviously the match has not yet ended and the ball is still in play.

I actually now think that you are an art project: somebody is working on a screenplay for Office Space 2: Initrode does ASICs and wanted to test some jokes.

We always like to avoid confrontation, whenever possible. But if you aren't going to start putting the proper cover sheets on your http://en.wikipedia.org/wiki/TPS_reports, then we will have to go ahead and take away your red stapler.

1) Fun is fine.

2) They have a whole "Embedded Linux SO-DIMM module" to handle initialization and self-test. Why waste even a single gate and single trace on dedicated test logic? Hopefully they included some sort of "clock disable" register to avoid wasting dynamic power on the engines that keep delivering erroneous nonces. This is such a trivial design that any undergrad could do that. I'm willing to give KnC the benefit of the doubt.

3) All standard-cell libraries that I've seen have some "high fanout", "high load", "low-skew clock" cells that are drawn much wider than the nominal feature size of the process. What are you trying to imply?

4) He, he. My 28nm e-peen has measure-zero. How many circuits have you implemented/characterized that had no JTAG chain (for a valid reason, not due to a fault) and were completely multi-way redundand, including power?

5) Extra-credit question for people who aren't engineers but have experience mining: how many mining devices/rigs you had that booted and started mining correctly, but kept failing after several hours or only in specific circumstances? Were you willing to consider them completely faulty and throw them away or were you willing to delve in and debug the problem? How many hours of "testing" was your cutoff time before you decided to throw that device away?

6) Extra-extra-credit question for engineers: What do you think about other engineers that have an obsesive-compulsive disorder about some testing methodology but have no practical experience running an actual bitmine?

Look, what you do here is called "concern trolling".

You wrote: "Without access to the netlist it's not possible to analyze the probability of a single point of failure." No need to access anybody's netlist. Just access the critical thinking facilities. Everything is at least 4-way redundand: cores, I/O, clock and even voltage regulators. The only thing shared is ground.

You wrote "I can't see why KnC chose to skip this common design practice", while many other members of this forum, including bitfury, already wrote at length why the Bitcoin hasher is self-testing and why any advanced fault analysis is a waste of resources when 1% error rate on the output nonces is perfectly acceptable.

How do you guys know what was the objective? Maybe Android was just an unintended collateral damage?

Wasn't Crypto AG compromised through the similar means?

http://en.wikipedia.org/wiki/Crypto_AG

Personally I wouldn't know.

So I guess the answer lies somewhere in the changelogs for the affected projects.

Go ahead, make my day. Take the challenge. Run your ATPG toolset and come up with a "stuck-at" fault vector that will not be detected by the HW-error code in the cgminer. What are you trying to show?

The "yield issue" for "a large 28nm" chip is a bullshit concern from people who don't understand that one can't take data from chips implementing single, hyper-complex circuit like CPU or GPU and apply it to a repetitive chip that doesn't even have a JTAG chain. I discussed it already a couple of days ago.

Edit: It was in this very thread: https://bitcointalk.org/index.php?topic=170332.msg2723643#msg2723643 . End of edit.

Rest your post about what is the real available "margin upon margins" is definitely a valid concern, but it is too early to really quantify that. Bitfury disclosed how he had dealt with it: hashing cores are 55nm but the unique control logic is drawn much wider (150nm?), all using the same 65nm nominal process. I'm going to give KnC designers benefit of the doubt and assume that they were skilled enough to use similar design methodology in their 28nm-nominal design.

Thanks for the compliment.

Unfortunately, there isn't sufficient technical information available to do a meaningful engineering comparison.

The only meaningfull contribution I can make is to shot down impostors who use the correct English grammar and technical vocabulary, but have no actual understanding of the underlying technology, e.g. kingcoin.

KnC had published some general technical information couple of days ago: https://www.kncminer.com/news/news-25 . I can't access it now, but it clearly showed that the package has over 1000 pins and that the single chip is comprised of 4 disconnected sub-regions, with absolutely every feature symmetrically quadrupled. Each of the quad in turn contains 24 identical copies of the hashing engine. When you can access it take a look at the floorplan and make a guess: what would be the probability of randomly distributed defects to hit every of the 4 copies of "control logic". What would be a minimum required size of a "single defect" that would kill all 4 regions? Even if you aren't rocket surgeon or brain scientist your honest guess will be better than the kingcoin's assesment of "insanity" of the KnC designers.

Here is a fragment of the Wikipedia definition of a code monkey: a derogatory term for an unskilled programmer who is only able to perform trivial or repetitive computer programming tasks or a reference to a job that treats even experienced computer programmers in a way that trivializes their problem solving abilities.

CAD-monkey is the hardware equivalent of the above term, because most of the hardware engineer's work involves not writing/editing "code", but operating some "CAD" or "EDA" tool/program.

Edit: CAD-monkey is derogatory if the person claims to be a qualified engineer. It may be a very friendly, or self-depreciating, reference to a skilled/trained salesperson of the CAD tools. Working in sales could really require skill and patience at repeatedly explaining/presenting "how to import a netlist" or "how to export to an ATPG (Automated Test-Pattern Generation) tool".

A single "stuck at" fault that would disable a whole chip that is completely 4-way redundand?

You are incompetent.

The above is the proof.

What are you talking about? What would be an example defect that would completely disable a chip with 4 non-overlapping/non-intersecting clock trees?

Please go back to your ATPG tools and obtain the probabilities. Then report back here and re-state who is insane.

Also: use your best design-for-test methodology to create a test pattern. Then compare the coverage with just any 10 random 80-byte test patterns. Then come back here and report who is a CAD-monkey in this thread.

Edit: I'll add this explanation for the readers unfamiliar with logic design. SHA-256 is essentially self testing: there's no internal state that is either not controllable or not observable. Same with all the interconnects. It is possible to construct a very-low-probability faults that will go undetected in the unrolled design. But their probability is way lower than the acceptable hardware error nonce rate in a Bitcoin miner (single percentage points).

For the readers unfamiliar with logic design but capable of compiling a program: take an example working SHA-256 code and make a single character change somewhere in the code, e.g. '0' to '1'. Then recompile and compare the results of hashing a test file with 1000 randomly choosen 80-byte strings. You'll immediately understand what it means "high toggle rate" and "self-testing logic".

This self-testing property has been discussed on this forum multiple times, in English and in other languages.

So what? Bitcoin miner is an LSI circuit. Thus far people used VLSI design methodologies simply because the existing IC layout toolchains couldn't cope with thousands of copies of identical circuit and either failed to converge or converged very slowly. So they simply unrolled the rounds of SHA-2.

On the other hand alternative semiconductors offer radically lower leakage, radically lower parasitics and radically faster clocks, e.g. 250 GHz. Also it so happens that the characteristic impedance of a metal trace (as a transmission line) better matches both input and output impedances of the transistors. So instead of fighting with reflections and noise in the interconnect the circuit is using the supplied power to do an usefull work: toggle the gate/flip-flop.

If you know how do a simple experiment: simulate a paralled 32-bit adder with all the attendant carry-look-ahead logic. Then simulate a simple serial bit-wise adder at a clock speed 32 times faster. Then compare the total energy used by those two. The technology node doesn't matter so long as it is the same in both cases.

I wouldn't be that pesimistic. There is a lot of possible avenues for improvement in a dedicated hashing circuit on the back-end analog side of the design.

When Intel design their "digital logic gate" they make certain assumptions about the probability of the circuit making a transient fault. I don't want to spend time digging numbers, they published some of that in a HotChips presentation about Itanium RAS (reliability, availability, serviceability). A CPU of the complexity of the Itanium is rated somewhere around 10^-20 for the probability of undetected machine check fault.

On the other hand the experience of the FPGA & ASIC miners is that the optimum hardware error rate for miner is in the order of 10^-2, that is single percentage points. And the complexity of even a fully-unrolled double SHA-256 hasher is nearly nothing compared to a modern 32/64-bit CPU.

So there is an ample room to use the curcuit design methodologies that are less digital and more analog. I don't think that any of the current vendors of the Bitcoin mining ASICs has any experience designing this type of circuits. Bitfury did a little bit of exploration in this direction by checking how low he can go with the supply voltage, but he had used pretty much standard push-pull static CMOS logic gates. There are many other ways of implementing logic gates than static push-pull (a.k.a. bang-bang). Edit: There are many other semiconductor materials suitable for the manufacture of integrated circuits: GaAs, SiGe, etc. There are many other IC design companies that are not very well known, but specialize in other areas of circuit design than the well-known CPU/GPU/DRAM/Flash in silicon e.g. http://en.wikipedia.org/wiki/Vitesse_Semiconductor .

Hey etotheipi!

Microsoft Research is copying your ideas. Check this out:

http://mobile.slashdot.org/story/13/08/15/1431251/ms-researchers-develop-acoustic-data-transfer-system-for-phones

I'm posting this here to show the doubters that this wasn't unworkable idea. It was just somewhat difficult to implement. It clearly is competitive to NFC as far as technology goes. It may not be competitive marketing-wise.

For the edification of the readers I'm going to repost something I wrote last year. Since that time I also came across the information that the courts in other states than Nevada, e.g. California, Connecticut (and some others) concurred with upheld this definition even though it wasn't directly pertaining to their jurisdiction and to the "card games".

Something or somebody doesn't check out in this thread. "Clearing cryptocurrency transactions" without mining?

Again something doesn't check out. How they want to "become a reliable and trusted node" without mining?