Author

Topic: Swedish ASIC miner company kncminer.com - page 1825. (Read 3049501 times)

hero member
Activity: 532
Merit: 500
August 17, 2013, 02:14:42 PM
Any theories out there on who is delivering so much hashpower to the cloud right now? Avalon? Bitfury, Both?

Well it's funny because;

Butterfly Labs would really like you to think it's them,

Bitsyncom really don't want you to think it's them,

...whilst Bitfury, and ASICminer remain silent.

Wink
legendary
Activity: 938
Merit: 1000
LIR DEV
August 17, 2013, 02:12:00 PM
Any theories out there on who is delivering so much hashpower to the cloud right now? Avalon? Bitfury, Both?
full member
Activity: 196
Merit: 100
August 17, 2013, 02:07:16 PM
So how do all the manufacturers of CPU, GPU, FPGA and all the other high power devices manage then? Of course the test fixtures are expensive, have a long lead time, and need specific expertise to program  (my first job, 30 years back was writing test patterns a TekTest for the 5 micron ULA devices that were just coming onto the market). ORSoc will have outsourced this to the experts (one hopes).
Basically the way I have described it: scan insertion, automatic test pattern generation and analysis, and probably some built in self test.

And I think you missed my point with your selective quoting. Go back to the original post. You asked ...
Quote
BGA fixtures are expensive and not always so easy to deal with. It not impossible even though the package here is probably not the cheapest one around. But why?

To which I replied as above. What has that got to do with ATPG etc etc? The question was about how you physically handle a BGA packaged device in a tester, and I (slightly rhetotically) replied that you do it the exactly same way as CPU/GPU/FPGA devices are currently done!

Enough with the concern trolling, ORSoc know what they are doing (probably more than BFL, Avalon and the rest). They may or may not have decided to omit the packaged device test. Beyond the initial prototypes they will certainly need to have one in place, so unless there are problems with lead times on the test adapter/programming, they will almost certainly package test the prototypes too.
legendary
Activity: 2128
Merit: 1073
August 17, 2013, 12:30:43 PM
5b) Also how would you feel after spending X thousand dollars on your miner to discover that when you receive it it only has 100-Y% of the cores operating, while some other guy (also payed X K$) on the forum received his miner which has 100% of the cores operating? This after you have spent numerous of hours trying to restart your miner, upgrading software, power cycle, swapped pools, replaced the PSU you bought because initially because you thought it could not supply enough power to the miner, etc. Of course the hash rate is within the late announced hash rate given by the vendor, so you can't ship it back for a replacement.
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.

KnC is skipping a testing methodology used by the vast majority of the ASIC industry: chip level testing to make sure they detect faults at the chip tester and not in the assembled product, where they might not even know if the cause is a defective ASIC. Rather than stopping or sorting the bad chips at the fab, they pass them on to their customers. Again, which hopefully will receive miners above the later announced rate.

As I've mentioned earlier I would have expected the hash rate to be given by the architecture and static timing analysis (assuming they have designed the rest of the miner so the operating conditions of the ASIC timing model is not violated). I was not aware that KnC was skipping this common testing methodology, but it might explain why they are so uncertain about the actual final performance of their miners: It will depend heavily on the yield of ASIC's as they will be mounting defective ASIC's into the miners as they don't know in advance which chips are defective or not.
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.

BTW: Just keep your rude personal attacks and wrong assumptions of what I do and have or have not done coming. I simply ignore them, but they seem to be good for your inflated ego.
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.
sr. member
Activity: 262
Merit: 250
August 17, 2013, 12:27:42 PM
KingCoin...Ever thought that maybe Markus knows something you/we don't?

That might be the case. It might also be some misunderstanding that they don't have any intentions of running tests on the chip tester. If not I would be interested in learning the reason for not doing so. Makes me think that this is some pre-tested FPGA/eASIC style device again... But they have insisted on that they are using 28nm cell based technology, even though the process and vendor is to my knowledge still undisclosed.
sr. member
Activity: 262
Merit: 250
August 17, 2013, 12:21:21 PM
I'll probably get out of my depth here and show my ignorance, but WTF, its a quiet day so ...

Running scan insertion and inserting signature analysis on the hash core will require adding gates. More than what can be handled by a simple metal fix. Hence it would require a number of masks being produced at a high cost and more time and resources.  But why?

But (as has been pointed out upthread), this is totally unneccessary as its already built in - a bitcoin hasher is almost the ultimate in a self-testing design. Probably better than most of the self test bolted onto typical commodity ASICs.

You have missed my point. Somebody mentioned that KnC had no intentions on running test vectors on the chip tester. The hasher its great for generating coverage. That's what I meant by "free BIST" and signature analysis earlier. I've done similar things in the past, not with SHA's, but with CRC's. When you have this infrastructure on your device you should utilize it on the chip tester and detect the defects early and not after you have mounted the chips. And while you're at it do scan insertion and ATPG to increase you coverage further since catching errors and faults early is a lot cheaper than later in the product cycle.


So how do all the manufacturers of CPU, GPU, FPGA and all the other high power devices manage then? Of course the test fixtures are expensive, have a long lead time, and need specific expertise to program  (my first job, 30 years back was writing test patterns a TekTest for the 5 micron ULA devices that were just coming onto the market). ORSoc will have outsourced this to the experts (one hopes).

Basically the way I have described it: scan insertion, automatic test pattern generation and analysis, and probably some built in self test.

I've also manually written vectors for Gate Arrays in the early 90's. Making vectors manually and running fault simulations is very tedious and ineffective. It's like catching timing errors by running gate level simulations. Fortunately you now have tools to do scan insertions to increase coverage and ATPG to generate vectors and do fault analysis.

I would expect ORSoC to outsource this type work.

full member
Activity: 173
Merit: 100
August 17, 2013, 12:11:57 PM
Rather than stopping or sorting the bad chips at the fab, they pass them on to their customers. Again, which hopefully will receive miners above the later announced rate.

Chips are cheap, time to market is expensive. Every unit will be tested before being delivered to the customer(s) to ensure that the minimum hashing speed of 400 GH/s is met. Anything else is a bonus so I am not sure what's your point  Roll Eyes.
sr. member
Activity: 462
Merit: 250
August 17, 2013, 11:57:52 AM
Mebbe, DPOS, but I seem to recall that KnC gave off the vibe (if they didn't outright say) that power usage would be less than originally specified, but "don't buy PSU, yet!".

https://bitcointalksearch.org/topic/m.2520109

very true, but they still have the option either way when the tire hits the road soon
sr. member
Activity: 322
Merit: 250
August 17, 2013, 11:12:08 AM
Dang, I'm good.
 Tongue
hero member
Activity: 532
Merit: 500
August 17, 2013, 11:08:51 AM
Mebbe, DPOS, but I seem to recall that KnC gave off the vibe (if they didn't outright say) that power usage would be less than originally specified, but "don't buy PSU, yet!".

https://bitcointalksearch.org/topic/m.2520109
sr. member
Activity: 322
Merit: 250
August 17, 2013, 11:02:19 AM
Mebbe, DPOS, but I seem to recall that KnC gave off the vibe (if they didn't outright say) that power usage would be less than originally specified, but "don't buy PSU, yet!".
sr. member
Activity: 462
Merit: 250
August 17, 2013, 10:54:00 AM
You guys forget, these guys have a modular design were we probably get 50% more hashing power thrown in the case to be safe... They are in fast mode and don't look like they are trying to maximize profits on design testing and guessing, just make profits on how fast they send us stuff above what we paided for... If we get 600Gh on a Jupiter I don't think they care they gave too much

How does that work? The design I saw had one module for the Mercury and 4 for a Jupiter. 100 G/hash each?
Unless they built in some extra as recently mentioned and it wasn't such a surprise as we may think?

I just think that is where the confidence comes from..  fast & cheap but not good.. so they just make it up in volume!!

granted that will throw the power use up, but that also is probably why they say don't buy any PSUs yet


just a hunch, but it seems this is a path they may take to be sure of everything
hero member
Activity: 532
Merit: 500
August 17, 2013, 10:52:27 AM
In case anyone's interested, interview with Austin and Becky Craig on the 'Life on Bitcoin' film project;

http://www.coindesk.com/life-on-bitcoin-is-a-challenge-for-newlywed-documentarians/

Pretty cool but no mention of KNC.  Sad

They've agreed to distance themselves on the grounds this is about raising Bitcoin awareness and acceptance, not product placement. KnC's the official sponsor, but they don't want to distract from the purpose of the film is what Sam told me.

Clearly they will get a mention when there a product exists as they will be mining with Jupiter. Currently it's vapourware, so it wouldn't be wise to promote something that doesn't exist yet.

The purpose of the film is whether living on Bitcoin is possible, and the challenges Austin and Becky come across facing mainstream adoption.

It will certainly be an eye opener for any entrepreneurial types searching for Bitcoin related ventures that have a need fulfilling.
legendary
Activity: 966
Merit: 1000
- - -Caveat Aleo- - -
August 17, 2013, 10:44:08 AM
In case anyone's interested, interview with Austin and Becky Craig on the 'Life on Bitcoin' film project;

http://www.coindesk.com/life-on-bitcoin-is-a-challenge-for-newlywed-documentarians/

Pretty cool but no mention of KNC.  Sad
hero member
Activity: 532
Merit: 500
August 17, 2013, 10:31:27 AM
In case anyone's interested, interview with Austin and Becky Craig on the 'Life on Bitcoin' film project;

http://www.coindesk.com/life-on-bitcoin-is-a-challenge-for-newlywed-documentarians/
sr. member
Activity: 1176
Merit: 265
August 17, 2013, 10:12:36 AM
You guys forget, these guys have a modular design were we probably get 50% more hashing power thrown in the case to be safe... They are in fast mode and don't look like they are trying to maximize profits on design testing and guessing, just make profits on how fast they send us stuff above what we paided for... If we get 600Gh on a Jupiter I don't think they care they gave too much

How does that work? The design I saw had one module for the Mercury and 4 for a Jupiter. 100 G/hash each?
Unless they built in some extra as recently mentioned and it wasn't such a surprise as we may think?
sr. member
Activity: 462
Merit: 250
August 17, 2013, 09:12:46 AM
You guys forget, these guys have a modular design were we probably get 50% more hashing power thrown in the case to be safe... They are in fast mode and don't look like they are trying to maximize profits on design testing and guessing, just make profits on how fast they send us stuff above what we paided for... If we get 600Gh on a Jupiter I don't think they care they gave too much
legendary
Activity: 1498
Merit: 1000
August 17, 2013, 08:28:36 AM

KnC is skipping a testing methodology used by the vast majority of the ASIC industry: chip level testing to make sure they detect faults at the chip tester and not in the assembled product, where they might not even know if the cause is a defective ASIC. Rather than stopping or sorting the bad chips at the fab, they pass them on to their customers. Again, which hopefully will receive miners above the later announced rate.
Once they receive the completed machines they'll go a burn-in and anything not within specs will simply be set aside and they'll move to the next device and send you that one. It's not a big deal yo.


Would be great if they sold these too cheaper!
full member
Activity: 196
Merit: 100
August 17, 2013, 07:57:48 AM
Another way to put it - if a Hasher has errors, and those errors are undetectable, then those errors don't matter.  The system will mine away without any problems.

Although I did think of something - suppose a hasher had an error that caused it to miscount the number of trailing zeros, but only if they were above a certain threshold. in that case your miner would appear to be working working just fine - but it would be ignoring hashes above a certain difficulty.

It would mean that, if that difficulty were reached, everything would appear to be working perfectly and in fact you'd be getting full credit at a mining pool, but you would never find a block and the effect would be slightly reduced luck for the pool.

But that said, they're likely including known high diff block headers in their tests.

I don't think that's an issue. The pool will check the submitted share and reject it if the hash is invalid for the worker difficulty level (target). For that matter cgminer et all will reject it as a hardware error before it even reaches the pool.

The issue of the miner mis-calculating the hash against the target just means it will fail to report a valid hash, ie just another duff core fault. I'm not sure about current ASICs, but the original fpgaminer (and ngzhang's icarus and the ztex's) all work to a target of 00000000 (difficulty one). It would make sense for next-gen asics to accept a variable target to reduce the comms bandwidth to cgminer, but that requires a driver coding change. I guess cklovas or kano could confirm this.

[EDIT] Having thought about it, you are correct. If a hasher is incapable of reporting a high difficulty share, but OK for difficulty 1 shares. then it will act as a leecher, submitting valid shares but never solving a block. Its a pretty unlikely failure mode though, though could be designed-in at the development stage (evil grin  Grin ). That's the trouble with proprietary systems, no knowledge of exactly what is going on inside the black box (cue conspiracy theorists  Wink )
full member
Activity: 238
Merit: 100
August 17, 2013, 07:35:09 AM
I'll probably get out of my depth here and show my ignorance, but WTF, its a quiet day so ...

Running scan insertion and inserting signature analysis on the hash core will require adding gates. More than what can be handled by a simple metal fix. Hence it would require a number of masks being produced at a high cost and more time and resources.  But why?

But (as has been pointed out upthread), this is totally unneccessary as its already built in - a bitcoin hasher is almost the ultimate in a self-testing design. Probably better than most of the self test bolted onto typical commodity ASICs.

Another way to put it - if a Hasher has errors, and those errors are undetectable, then those errors don't matter.  The system will mine away without any problems.

Although I did think of something - suppose a hasher had an error that caused it to miscount the number of trailing zeros, but only if they were above a certain threshold. in that case your miner would appear to be working working just fine - but it would be ignoring hashes above a certain difficulty.

It would mean that, if that difficulty were reached, everything would appear to be working perfectly and in fact you'd be getting full credit at a mining pool, but you would never find a block and the effect would be slightly reduced luck for the pool.

But that said, they're likely including known high diff block headers in their tests.
Jump to: