Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 22. (Read 435369 times)

Hoping it's not a case of "Bangkok disappearance".

I'm just checking in to send out some well wishes for bkkcoins safety.  Sorry for interrupting any technical speak.

Even when he was busy working on these designs he would take the time of day to write me pages of info about what life is like in Thailand. 

I hope all is well and I miss ya bud.

I have been reading this thread for months.
Sorry if some of us require translation of some of the things that are obvious to others.
Your insults are not necessary - I am here to help - I thought maybe if I better understood the problem I could help gather some information to make this project a success.

Is there a verifiable source that officially has the Klondike design hashing on all 16 chips with an acceptable hardware error rate?  I haven't been keeping up with the status of all the different K16 variants, but I noticed the new 3.5.1 version of cgminer appears to have Klondike support.

Thanks!

Chad

The one that has 0 accepted you might want to replace the resistors and see what happens.

Since you seemingly didn't follow the posts originally, re-posting them might not help since the re-posts will likely scroll away beyond your attention span of backscroll just as fast as the original posts did?

-MarkM-

I've replaced C274 on 5 of my K16s now with a 220pf cap, with mixed results.

I now have 3 that hash at somewhat low rates, 1 that has a zero hashrate, and 1 that fails to be detected on USB.

The 3 that hash seem vary somewhat in their performance:


Unfortunately I was less scientific about things than I ought to have been, and I didn't test all the boards before I went to work on them, so I'm not really sure what the initial behavior of all of them was.

I also accidentally shorted the fan output pins with the USB cable shield while plugging/unplugging on at least 2 boards and saw sparks, which is way too easy to do.  I'm not sure if that messed anything up.

I initially had 2 with a zero hashrate.  I reflowed C274 and that fixed one of them.  I made several attempts at reflowing C274 on the second one, and then replaced it with a fresh 220pf cap, and reflowed it a couple times, but nothing fixed this one.

"Same data is missing, funny thing..."

Could you or someone elaborate on this?

Thanks

Well, so I tried replacing just C274 with a 220pf cap on just one board, and it does appear to have brought some life to it:


That's using cgminer 3.5.1, run without any special arguments.

The hashrate still looks low, but it's an encouraging sign.  I might try that on the rest of my boards now.

Edit: I also took the 1Ks off one of my boards, and stacked them on top of R45 and R46 on the modded board to make them 500s.  It didn't seem to change anything.

My bad - the profusion of alternatives some times get jumbled... Of course, the same questions can be leveled at the Avalon, both old & new. Same data is missing, funny thing...

Thanks for the thoughts, even when I was way off topic.

--DickMS

This is an Avalon thread, you won't get much on BitFury here.

Yep - I suspect that there is a well known (by the designer, not by the DIY community) method for selecting nonce initialization data, to prevent engine overlap, and hence lost utilization efficiency. I'd really like to understand those semantics - they have serious implications for chip-chaining lengths, polling times, and so forth, which could result in significant performance optimizations on systems that are "in-the-know", versus ours, where we just poke in the dark.

To be TRULY open source, all the magic sauce needs to be known publicly - companies like SCO, who sold OS based systems and concealed all the build instructions and parametrization necessary to get the systems working from the "open source" base they provided were bankrupted, eventually, by lawsuits. They used the fruits of others' development efforts, and conspired to ensure that no-one could use their derivative works to compete with them.

It can't take but a few sentences to describe how the internal semantics work, at least to the extent that we need for designs - answering these questions would be a good 5-minute break from heads-down development.... Take a break, Fury!

I'm not sure how it generates the nonces locally on chip, but if it was just spitting trillions of duplicated hashes then cgminer would report a very low rate of accepted shares and it would be clear that the chip was not performing at all.

Please excuse the simplistic question, but does anyone know how the BitFury chip works? It apparently has about 700+ rolled-up double SHA256 engines, each of which must have a unique nonce to be useful. It seems (according to what I read in this forum and the supporting links) to claim that it can perform a complete pass through each of those engines in about 65 clocks, at several hundred MHz. On the other hand, someone has displayed a scope trace showing a load sequence, with Merkle data, pre-calc, and block data, along with about 110 uS of nonce initialization. Since the init sequence in total is over 300 uS long, and there are only a few nonces in it, I have two questions:

1. How does ~800 bits of nonce initialization data set up the 700 * 4 * 8 = more than 22,000 bits of nonce needed for all 700+ engines?

2. If, indeed, the engines run for about 65 clocks, at say 300MHz - which is about 1/5 of a microsecond - at which point they have used that nonce data, how is the chip getting more than a small fraction of 1% utilization: run for 0.2uS, init for 300uS, repeat as desired...

I am presuming that somewhere out there is a document that exposes what the chip internals do with the initialization nonce data, and what happens to the nonces once each round of 65 clocks has passed.

WHERE IS THAT INFORMATION?

Presumably, the initialization nonce data is expanded some way, by a factor of 22k/800 = 28 to get initial nonces for all 700 engines, then each round of 65 clocks results in those nonces being incremented or shifted, or something. With only a one-bit "I found one!" notice coming from the whole chip, decoding which nonce was the golden one becomes rather time consuming and depends upon knowing the number of 65 clock rounds since the startup...

So where is all this crucial information? I've searched and searched, and the best that I've found is to reverse engineer one or more of the miners, but there is a crucial step missing - I see what the program does, but I can't see how that data is manipulated before being shipped into the chip via that Manchester encoded serial pair.

Does anyone have a pointer to the real information? Has anyone analyzed the WU readouts of the demo'd miners to see if we are actually getting the number of results expected for the hash rate, and not just getting trillions of duplicated hashes on duplicated nonce streams?

Thanks for any help or pointers, folks.... making boards and firmware for this kind of a system should be a piece of cake for any experienced design team - I've run such teams for nearly 45 years, and we've done many more complex systems. But it's impossible if the chip semantics aren't available, unless you have a government lab at your disposal that can treat it as a black box and run dozens of probing tests at a time. They don't open-source the results.

I'm wondering the same thing.  I bought some odds and ends for the museum.

Not yet.  I guess I can try it, leaving the 1k resistors in place, and see if it helps.

Have you already replaced the capacitor?

Well, it seems I failed to get the right resistors, and I've got 560 mOhm resistors.

Fortunately I noticed this before I installed them.

I did measure the resistor I removed, and it measures 1001 ohms, so the "mod" has not already been done to mine.

I've got some actual 560s on the way now.

Has anyone tried one of these boards? might be making one using the opensource thing if it works.

Did anyone ever receive parts from his store? I ordered a klondike board for decorative purposes months ago.. wonder whats going on with that.