Measure the DC voltage (if any) between the individual heat-sinks; while operating, but open, with additional external desktop fan providing additional cooling.

I'm kinda afraid that -ck may be politically or contractually restrained from answering my question. The only answer that he could make would be "feature parity with competition".

I used to work in the medical business and that phrase would actually mean "misfeature parity with influential political lobby". Imagine an electronic sphygmomanometer which instead giving you a numeric answer like "120/80" would be restricted to giving only a binary answer: "You are OK" and "Go see a doctor". ( This isn't a real example, I just wanted to write something that nearly anyone can relate to, without going into explaining medical procedures. ) In the medical field doctors frequently won't give you straight answers, to get to the truth you'll have to interrogate their office staff, both the medical and administrative side.

It is probably only partly true. They may tune the clock frequency synthesizer per each chip, but I think that the hashing core voltage is getting tuned in groups/strings/whatever is the actual limitation of their voltage regulators.

Hey man, nice angry rant. I clearly stroked a well known problem area.

Coin mining isn't a very complex problem. I'm pretty sure that an average car enthusiast is familiar with how modern cars autotune their engine management unit and automatic transmission shifting points. And how those are in need of recalibration when the car's driver changes for one with a different foot temperament or the driver decides to switch to a different brand of fuel. Even after a service or some part replacements cars need time to retune themselves.

But cars aren't typically operated 24*7, whereas coin miners are designed for continuous operation. The actual probing in the tuning process doesn't need to run for multiple tens of minutes. It should take just a few seconds, maybe at most few tens of seconds. And the results need to be stored and properly processed.

Analog TV is nowadays a history, but nearly every analog TV implemented with integrated circuits auto-tuned itself during the beam retrace period, so it was 60 times a second in the USA, and 50 times a second for most of the world. Color TVs did full calibration in steps over 4 frames or 8 fields. Video tape machines did more complex auto-tracking but this was mostly due to limitations of the quite complex mechanical tape transport. In a coin miner the only mechanical variable to tune is the fan speed in RPM.

But anyways, this wasn't some highly technical and patented research. It may have been patented in 197X to 199X, but any patents long expired.

So it isn't like I'm talking about some advanced rocket science or some other secret algorithms. It is all open source now:

https://en.wikipedia.org/wiki/Nelder–Mead_method

and the relevant code is GPL-licensed, exactly the same as -ck's cgminer.

With Spondoolies the situation was different. They intentionally hired an inexperienced developer for full time maintenance work on their code and never paid (or didn't pay in full) the experienced consultants that did the initial work.

I'm really curious what are the reasons for all this technical weirdness in the coin mining business.

Edit: made the link properly clickable.

-ck, I have to ask you: why don't you do the autotune correctly?

It is well known that autotuning at reboot is patently wrong: the device is probably cold and seriously out of the thermal equilibrium. It is well known that that type of tunning needs to be done repeatedly as the system reaches equilibrium. I don't have practical numbers for mining farms, but I presume most of them aren't working exactly in temperature-stabilized conditions, so thermal equilibrium will probably change at least twice per day. I doubt that 30 minutes is enough to reach the normal operating temperature from the cold start.

Is this a problem with storing the calibration coefficients in the flash memory that will wear out? Then why not store them in a circular log file with fixed-size records that are as long as the write-blocks of the underlying storage medium?  Those are fairly big 64kB or 256kB or some such, there's plenty of room to write some calibration results. And if writing at every calibration is too often then write the summary (average, minimum, maximum) once per day.

Or was the "autotune" simply a marketing requirement or a contractual agreement? I kinda don't want to see the repeat of what had happened to Spondoolies and their ill conceived POST (Power-On Self Test) and how people had to resort to preheating their miners with hair dryers.

Alice, what is the "voltage leak"? Where is it leaking from?

Is that why they are recommending to operate the units laying on a side? 

That proves nothing beyond the fact that somebody modified the source code of the pool software to change different bits in the block header. The blocks mined with ASICboost can be mined with no overhead using standard miners, so this could be used as propaganda for no additional cost.

The only technical benefit of ASICboost is that it could reduce the power usage when mining certain combination of the header bits.

IANAL in general, moreover IANA patent L, but I used to sit next one at the table during conferences and lunches.

The way they explained it to me that the history of US jurisprudence and legal precedents make it easier to defend a "device patent" against any sort of infringing "emulation" or alternative "embodiment" than vice-versa or any other combination in-between. Basically, if you think that your understanding of English grammar and Boolean algebra is sufficient to understand the patent, you are sorely mistaken. If your experience of patenting is only as far as getting it granted by the USPTO then you have less than half of the required knowledge.

Patent lawyers are so well paid, because they known the best combination of claims that's easiest to get approved and hardest to overturn in litigation.

I read some reports from people reverse-engineering Bitmain's firmware. According to them the AB is not only switchable on/off but also allows variable levels of boosting.

I wouldn't make that inference for any patent in the USA, probably even for most of the world. In my understanding the use of "device" abstraction is a method of strengthening the patent against counter-claims, not anything technical or technological.

I think you are needlessly conflating two separate things:

1) legalistic maneuvering related to patents and their licensing

2) deception and disinformation tactics like "covert AB"

They are only very loosely related and untangling the two is the key to understanding the situation.

It seems like a lot of bitcoiners had fallen into believing their own bullshit and now have hard time returning back to reality.

I think the company 21e6 (now 21.co ?) was a good early example of what happens when you believe your own propaganda. Their "Bitcoin Computer" was utterly non-competitive because it included some complicated DRM logic to guarantee coinbase payment address. If you think that Intel is somehow above making such a strategically stupid mistake, all I have to do is to remind you about Itanium and their completely unfounded in reality claims about advances in compilation technology.

This is both true and false.

It is all true if you really believe that the particular chip really implements the AB.

On the other hand is it possible to write a firmware that drives the regular non-AB mining chips in such a way that they appear to produce results that look like made with the AB.

But the only way to actually verify the existence and support for AB is via reverse-engineering of the firmware or attaching the logic analyzer to the signals sent to the mining chips.

Edit: As far as reverse-engineering the firmware, the cost and complexity depends on the MCU. I believe the recent hardware has been using Xilinx Zynq chips which is a dual core ARM chip paired with the Artix FPGA logic slices. Reverse-engineering the FPGA programming bit-streams is nothing like disassembling the microprocessor's instruction ROMs, it is several orders of magnitude more cumbersome and expensive. In particular there are no tools available publicly for that task.

On the other hand writing a firmware that fakes the AB (provided that you have the source for non-AB firmware) is fairly trivial exercise.

You are neglecting a whole branch of cryptography: https://en.wikipedia.org/wiki/Stream_cipher .

The shelf is reasonably well stocked, recent overview: https://en.wikipedia.org/wiki/eSTREAM .

This paper is about a way of implementing GALS (Globally Asynchronous Locally Synchronous) logic. IMO it won't help at all for SHA256D. It could probably work for something like scrypt() which is a sandwich of two layers of PBKDF2 with Salsa20 in the middle. Fixed length SHA-256 like in Bitcoin is too trivial to be susceptible to such advanced optimizations.

But you are some sort of an insider, with access to the information about the most current tools and processes. Why don't you use to produce some useful information, even if you don't have funding for the fully separate mask set production?

Why don't you actually run some representative simulations, even some reduced-rounds non-compatible version of SHA-256?

Why can't you squeeze a single Bitcoin mining engine into paid-for but left unused free space on some unrelated project taping out? The same way that Heveticoin did, and in the spirit of the long history of placing various more-or-less useable Easter Eggs into established silicon products?

Can you make an educated speculation as to what would be the underlying business strategy?

What is the technical merit of multiplying the complexity of the engine several times in exchange for the gains lower than the regular manufacturing tolerances?

Lots of ASICs get designed purely for non-technical reasons: copy protection, hiding of patent or license violation in a way that is extremely hard to reverse-engineer and litigate, etc.

I think there should be some constructive speculation that you could post without violating your NDAs, don't you think? Or maybe everyone at your company already knows that HyperMega is a pseudonym of their 1st VP of Sales, and everyone there already watches your back?

I haven't read the full patent application, but I understand how they are written with a goal of withstanding claim/counter-claim adversarial legal system in the USA and other anglophone countries. So I can confidently repeat: you are wrong, these numbers intentionally use idealized, abstract algebraic models to make a strong patent application. The whitepaper is just a marketing brief for the patent. This isn't a scientific report in the applied science field.

In the next paragraph you use the term "512-bit wide pipeline". This is just such a nice marketing speak. SHA256 is actually a 16-stage 32-bit wide shift register with some fancy feedback terms. The re-invention of it as 16*32=512 bit vector pipeline is nothing more than a workaround in for the bugs/design flaws in the front-end Verilog tools used preferably in the West Coast of the USA. If the design was done in VHDL (as preferred by East Coast USA boutiques) there would be no need  for that trick of making 32-bit slices out of 512-bit vector.

No matter which front-end was used the actual physical layout is very far from the neatness associated with the word "pipeline" and how e.g. AMD/Intel use it in theirs marketing literature and die photos.

The physical layout of such designed unrolled mining engine very much resembles the snake pit like one used in my avatar. That happens because the heuristic layout optimization tools cannot find any useful gradient to optimize for, fail to converge or converge extremely slowly resulting with semi-random rats nest of long traces.

I cut this paragraph into a separate quote because it is a beautiful sample of USDA prime marketing baloney.

Firstly duo-core was just a sample on the whitepaper, the Halong's implementation is quad-core. So it is 18.75% not 12.5%.

Secondly, you use values of bit much less than 2. Such a nice English creative writing trick. How do you values of "bit" compare with manufacturing tolerances which are about +/-20%?

Thirdly, it not about just (A) reduction of power use. You neglected to mention:

B) lower clock speed due to need to keep nearly four times larger area that needs to be kept in lockstep;
C) lower yield because the area of mutually dependent logic is increased nearly four-fold.

It is quite an achievement in marketing to squeeze 3-way deception into a single sentence. You must be a professional.

Finally, whatever one can say about Bitmain's chip that is ASIC-boost capable, at least it is somewhat honest in implementing switchable levels of ASIC-boost. One could actually measure the actual gains or loses from various levels of boosting and compare them with the table of theoretical values. It isn't as perfect an experiment as designing separate chips for each level of boosting, but a better scientific compromise.

All I can guess about Halong's chip is that it's design was worked out as some sort of political compromise or attack/defense strategy. I'm definitely not up to speed on the factions currently involved in the Bitcoin internecine warfare.

All the numbers in that paper are theoretical values assuming infinite speed of light and counting of ideal logic gates with no parasitic impedances, infinite input impedance and zero output impedance.

That has no bearing on any actual implementation in any realistic logic circuit technology. In particular even non-ASIC-boosted but unrolled SHA256 has same values used in 16 different places. This implies https://en.wikipedia.org/wiki/Fan-out of 16 when nearly all CMOS processes are optimized for fan-out of 4 https://en.wikipedia.org/wiki/FO4 .

The FO4 argument probably explains why that chip is built with fixed 4-way ASICboost.

Let's try different browsers from a different computer on a different continent.

But same schtick: enable Javascript to pass Cloudflare and Google captcha challenges and then browse and post with Javascript disabled.

If you see it, it worked.

This is an experimental post. I'm making it with Javascript disabled. I correctly saved the previous text to into SMF drafts https://bitcointalk.org/index.php?action=drafts , still without Javascript.

While writing this post I looked up some information on this forum in a separate window of the same browser, still with Javascript
disabled.

So it just looks like Cloudflare is requiring Javascript only to set up some ephemeral cookies when first opening a browser session. Once the browser session is started Javascript can be disabled.

Now I'm going to try to post it, with Javascript still disabled.

Edit: It appears it went through without a hitch. I'm now editing it with Javascript still disabled. Please post your experiences using your ISPs because Cloudflare is known for using various amounts of defensive technology for various ISPs and various traffic conditions.

Edit2: Further along this Cloudflare discussion, I went to a different site that is also using them for DDoS protection. In the past that site used to show the same Cloudflare screens about "Checking your browser". That other site didn't make that challenge this time at all, still with Javascript disabled. I know that this "other site" is nowadays not under attacks anymore, they are just using Cloudflare out of inertia.

Edit3: I just wanted to save my previous edits, still with Javascript disabled. Worked fine. Another variable as far as Cloudflare is that I'm typing this from a less popular browser. On the same computer I have bitcointalk.org opened in a very popular browser with most recent updates. In that browser Cloudflare re-challenged with "Checking your browser" despite the fact that I didn't close that other session and the ephemeral cookies are still present.

Edit4: So the summary is: YMMV (your mileage may vary). You can certainly browse and post on bitcointalk.org through Cloudflare with Javascript disabled. Just use tools less popular amongst the DDoS crowd and other script kiddies.

Don't make a mistake of putting nontrivial control logic onto the same chip as the mining circuitry. In case of failure you won't be able to distinguish between the real fault or bogus fault induced by the noise and/or heat from mining logic. By definition the mining logic has to work at the edge of starvation or hyperthermia death, otherwise it is operating far from optimal.

Helveticoin did something like you are thinking (including an on-die ARM controller) and it was completely non-competitive. It had to be severely underclocked to maintain the reliability of the controlling SoC.

Spondoolies included on-die power-on-self-test and then had to create software workarounds for mining engines that fail the POST but operate correctly after a warm-up. Some desperadoes resorted to preheating their miners with a hair dryer.

You'll be much better off with just temperature-sensing diodes or averaging multiple low-accuracy temperature sensors located in far-away corners of the die.

I don't think that there's any non-bullshit information available publicly about Halong chips, so I'll refrain from making comments.

"sandbagging" means that they used quite large factors of safety in their design ( https://en.wikipedia.org/wiki/Factor_of_safety describes is for mechanical/structural designs ). E.g. if the design tool came up with N um wide power rail they actually drawn the power rail as S*N where S > 1 . If their simulation computed that the maximum clock speed will be F MHz, they used D*F (where D < 1) in their published specification.

One of their executives enumerated their multiple layers of safety margins in the video they published upon initial release of their miners. Maybe somebody archived it somewhere in the KnC thread?

Europractice access is limited to educational/research/non-profit institutions. KnC from the beginning was a funded for-profit corporation. On the other hand Bitfury (person) initially developed his chip with cooperation from some Polish research institute before funding the Bitfury (corporation).

I keep mentioning Europractice/Mosis in the thread like this because it is an obvious and effective way of saving money in the initial stages of a design. Lots of folks keep mentioning multi-million dollar initial costs of developing the mining ASICs. But this is quite obviously not true if somebody knows how to use the educational discounts and how to deal with associated limitations on merchantability.