Topic: KNCMiner and their 'magic' SHA256 alogorithm (Read 8798 times)

Could it be that they are calculating with worse case scenario that about 23% of the cores in the chip will be dead, so the expected lowest hash rate in total is 350GH, with potentially 30% higher performance for all perfect chips ?
(in other words, 23% dead, 77% equals 350GH, and an unlikely 100% perfect chips will be 30% better, equals 455GH.)

Could it be that they are calculating with worse case scenario that about 23% of the cores in the chip will be dead, so the expected lowest hash rate in total is 350GH, with potentially 30% higher performance for all perfect chips ?
(in other words, 23% dead, 77% equals 350GH, and an unlikely 100% perfect chips will be 30% better, equals 455GH.)

I was there and and im not dissagreeing with you on that last statement bro. But the potentential "up to 30%" increase was to be on top of those figures. Thats why i made sure to ask twice. hence my "could be around 420?" in the transcripts. Thats what marcus and sam answered me any way. Maybe i missunderstood theyre answer or they missunderstood my qustion. But two positive answers, and the specs the way they are formulated on the website makes me somewhat confident that im right. But it is a "potential, up to 30% increase", thats why they didnt want to commit to any numbers more than 28nm 175/350, september.  Hence the "could" in the transcripts from both marcus and sam. Sounds in accordance with "Underpromise, overdeliver.

Excellent. I wanted the source of the material, not brontosaurus' warped view of it. Thank you for providing it.   

It sounds like KNC are not doing binning. They are confident that the yields will result in a low number of completely dead chips.
If they were making products with 1 or 2 chips on them, one completely dead chip would prevent that unit from being shipped as product.
Since there are a large number of chips per device, it is unlikely that 1 dead chip would make the device undeliverable.
Even 2-3 completely dead chips would still result in a partially functional product, it might not meet spec but it could sit in the corner at KNC and mine, it could serve as a test bed for firmware, etc.

Obviously, chip binning would increase the quality of the product but by how much we don't know. Perhaps spending time and money to get a 5% increase in quality is not worthwhile if they are beating their specs by 30%.
Time will tell.

Chip binning can be done post hoc, to screen out dead chips of there is an unforeseen yield problem.

Dude you 100% were there when I was pressing Sam as to what milestones we should hold them to, I asked exactly that, and he pointed to the banner with the specs and said, "minimum 350gh/s, 28nm, September".   I have this all taped.

You also know if you've done your research, and/or followed this thread; Jupiter was 250gh/s originally and the 30% increase in hashing power was offered then. 250gh/s with a minimum of 30% is a minimum of 325gh/s. This falls totally inline with the 350gh/s promised as a +30% optimisation of 250gh/s.

Just looked over some old emails now, and the only message where I had touched on the subject that I can find easily I was referring as to whether Mars had been optimised at 6gh/s, or not, but come on anything over 350gh/s is crazy! If this is something that's going to make you walk away, you need to clear this up with him, so you can get a refund.

It's called trying to inflate the actual performance of your product and/or design knowledge. If your product is good, quote firm numbers based on hard, verifiable FACTS rather than allude to 'improvements' to a mathematical process which has data dependencies which cannot be changed or improved.

The academics who wrote the paper quoted are experts in their field - Dadda has an adder type named after him - and designed a method of reducing delay paths on an actual asic. They did'nt change or say they could change an algorithm. KNC claim to have an 'improved' algorithm, and that is just plain rubbish. Ask any mathematician.

Any respectable company would not make such ridiculous claims, if KNC have indeed used the methods from this paper in their design,then they should acknowledge it. Hence my annoyance.

Incidentally, Dadda and co. got their SHA256 engine to run at 'a clock speed of well over 1Ghz' on a 130nm process.

Since I've made several posts pointing this out, I'll help out here ...


Possibly my post here was the origin of the "just solder chips on board" claim https://bitcointalksearch.org/topic/m.2468261

And ChipGeek (who seems pretty knowledgeable on chip design) made the following observation https://bitcointalksearch.org/topic/m.2474760

I don't want to get too trollsome on this point, just pointing out the source of the rumour.

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.
Please provide citations for your statements in the future.

Q&A

–
ChipGeek


3) Are you doing pre-package wafer test?

Marcus: No.

4) Are you doing post-packaging testing on a real production tester (Teradyne or similar)?

Marcus: No. We...and...and...I..I..I need to say a little bit about why; ah because we will have a self built in test that will automaically test...the...because the chips are so large, so that we can compensate for any losses in the Bitcoin engines. If there are any failing ones then we can compensate for that.

Me: Physically large?

Marcus: The...the die size of the...the?

Me: Yeah

Marcus: The die size will be...very large.

Me: But does that...ummm...

Marcus: That, that means that some of the parts in the ASIC might work and some will not, but we can compensate for that.

Another member: We can compensate for that.

Me: So does that mean you yield less per wafer?

Marcus: So yeah, you will always have a yield problem, and when you increase the die size, the yield problem becomes larger of course.

Me: ok

"This device is being designed in parallel by the ORSoC engineers and will offer industry leading performance and power consumption per GH.The final specifications for this device are being ironed out now but we can confirm the following.Minimum 175/350GH/s per device.28nm Standard ASICAn additional gain of 30% more hashing when the advanced algorithms provided by ORSoC are applied"

Those are the specs for the product that i bought, as advertized by KNC, and have gotten it verbally confirmed twice by both Sam and Marcus.
So that will be what i expect, and hold KNC to, come delivery time.

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.

Ok, now I'm not going to just drop this. I'll try to put this as plain and simple as I can for you once again; I'm not saying that their 30% boost is, or is not a part of the current rated speeds of 175 and 350 Gh/s. There was a post earlier from blastbob saying, "It has been advertised with 350GHs with possible 30% more with optimization..," and to which Bitcoinorama replied, "No it hasn't." The point in my posts were simply to say, "Yes, it has. And it's on the damn product pages." This shouldn't be speculation either. This should be a simple, confirmed fact that, considering a potential 30% boost, absolutely does matter.

You say it's a mistake, but as far as I can tell, it's based on assumption, Bitcoinorama, as I can't find any record stating clearly that the 30% boost is already accounted for in these currently rated speeds. I'll concede that yes, maybe it is a mistake, after all. However, I absolutely will argue semantics because if you think the language used in which to say something never matters, then you're a fool. In many cases, if not every, context matters just as much as does content. In this case, imagine a new customer, perhaps one new to the mining scene and unaware of the absurd amount of research already here on btctalk, decides they like the Jupiter as they see that not only is it comparatively highly rated (speed-wise) to other ASIC options, but KnCMiner are also promising a 30% increase to hashing power with the advanced algos applied by ORSoC, so they make a purchase. Now, are you to say KnC wouldn't be liable for the information they advertise about their miners? Before you say anything, of course, the customer should "do their homework" as you have so adamantly stressed through a great number of your posts, but the "hypothetical fact" it is an inadvertent mistake on the part of KnC is entirely irrelevant.

Are you able to provide where you did this as I certainly have not been successful at finding such a statement.

What bothers me most, Bitcoinorama, is you approach me with a condescending attitude and make numerous assumptions in your response regarding what I have and haven’t done, while giving no source to counter the position you've assigned to me, namely, that I think the 30% isn't accounted for in the current specs. Well, just for shits; I will accept that position and say, "yes, the 30% is absolutely not accounted for and any additional gain from the advanced algos from OrSoc will be applied above and beyond the currently given hash speeds." Now, show me how I'm wrong. I'll show you the evidence to the contrary.

1; See product pages of Jupiter and Saturn
2; 125*30% = 162.5 ≠ 175 - - & - - 250*30% = 325 ≠ 350 (in order to make your assumptions correct, you'd have to increase those original specs by 40%, not 30%) Interesting how titomane followed your request to KS to do the very basic math and when he supplied it, your response was, "lol. I didn't actually mean you do th..." Incomplete thought?
3; From your open day report, Q&A portion...
Do you think this other anonymous member pulled the number "420" completely arbitrarily? I understand it can be dangerous to begin quoting hard numbers before they're ready to commit to them, but why cut off the discussion there?

I'll finish by saying that I mean no personal jab at you, Bitcoinorama, and the information you've provided the community has unquestionably been a great value. You're willingness to attend the meeting, offer up your efforts in answering the community's remaining questions and report back is commendable. It's even possibly arguable that we've heard more information from you about all things KnC than we've heard from KnC themselves (which may be a little disconcerting, in fact). Ultimately, though, this 30% issue is something I'd honestly like to know, as do others apparently. If you can provide a definitive answer, I'd be further grateful. However, having said that, don't accuse me of being too lazy to dig up information for myself and say that my intent on sticking with this 30% gain issue is meaningless nonsense as "it's obviously a mistake" because most following already have the "very simple answer", and then expect me not to come defend myself. My last word; the promised hash speed may be the only thing that matters to you, but for me and probably one, maybe two other people, the Gh/watts ratio is rather more important, followed by purchase price.

My apologies for smothering the page.

Not really, real engineers are not driven by sales figures.

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.

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.


The product does not yet exist. They are being careful about setting expectations. They don't want to "BFL" their customers.

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.

Gotta say, the discussion is overall so lucid, reasoned, non-ad hominem, and civil as to threaten to give bitcoin forums a good name. 

but i could swear that the first announced miners were only
saturn with 250gh/s and the Mars. And about 2 weeks later they announced  the saturn again but with only  175 gh/s and the new "born" name and Miner Jupiter with 350 gh/s

No look, it's cool, you just haven't been here from the start. Anyone here from the start (April time) is welcome to chime in on this, it's certainly within the main thread.

--

KnC pre ORSoC promised a machine for around $3k, no real specs, just a choice to;

A) pay upfront pre-order and be in the first 1-500
B) pay half upfront and half when proven and be 501-1000

This was purely to gauge interest and pich to ORSoC, who they admit if weren't on board this venture would never get off the ground. THIS is why they rewarded the first 500, their interest and attention sealed the deal.

--

Next we hear ORSoC have come aboard. This is where my interest was sparked.

Two units were announced

Jupiter ASIC at 250 gh/s at $7k

Mars FPGA at 6 gh/s at $2,795

No one really understood the point of Mars,  but they were promising to uphold the queue order unless you paid for mars so you got guarded early order on Jupiter and a $2k discount for Jupiter.

I wanted Mars as a Litecoin FPGA so that's basically how I got in contact and involved as I pushed an quizzed their motives there. You should be able to see all that from the OG thread.

Anyway they need Mars for the ASIC design and we are promised it will lead to at least 30% hashing optimisation.

--

A lower entry model is introduced

Saturn 175 gh/s
Jupiter is revised at 350gh/s

Optimisation included 250 x 1.3 = 325

--

Mars is dropped from sale and exists purely to abuse for Saturn/ Jupiter's gain, but there will be a Mars Rev.2, just different...


I know it still appears like the 30% isn't added, but it is.