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

Is this correct?

REVISED Thanks BKKCoins.

Just noisy and use more power. This one is 12V @ 0.3A, so that's 3.6W. It's nice if you can control it to reduce power and not be noisy but ultimately one can just plug fans into the molex on the PSU and they work.

Fans are cheap. 100% fan speed isn't that big of a deal imo.

Keep up the good work.

Are you guys both on Windows? I noticed that the Windows timeout values are defined much longer and I wonder if this is related. For Linux the timeout is 200mS but WIN32 is 999 mS. Note that I do all my testing on Linux and libusb could behave differently here.

Today I've been trying to verify the Fan Control FET circuit so that the board can be finalized. So far it will only work at 100% duty cycle. I've tried different things but always partial duty cycles cause immediate restart/shutdown. I added a resistor from the PIC output to GND to ensure the FET gate drops to GND when off, but no better. I just have a generic cheapo 3 pin fan and usually they can be controlled with PWM, according to my reading online, but perhaps some are different. (Note I'm not talking about PWM control in the fan like 4 pin fans, but just switching the 12V line with PWM.) I based my circuit off another well known working one so this is odd. I'll keep working on it.

I just changed the 220p capacitor to 30p and the circuit is also exactly the same as BBKCoins drew. Ktest still gives "GOOD" from 128M to 300M with correct return time.
However, cgminer's stuck more frequently. The WU at 128M goes down to 2.5/m, and WU at 256M goes down to 2/m.

It seems that this issue has a lot to do with the clock generation circuit. May be some results cannot be captured.

I will test your method.

UPDATE:

Your method works!!!

I added

nmsleep(100); \

and everything works like a charm.

128M ~ 8/m WU
256M ~ 17/m WU

BBKCoins, please be noticed. This might be a common issue.

Clocked it at 275. These are the results:


WU started with around 72/m and has slowly stabilized around 61/m.

Yea I was having the exactly same issue. It has disappeared magically. Maybe the logging code I added, created a little delay and thats why the lock conflicts disappeared. Try adding some delay before wr_lock around line 1500 in usbutils.c


I hardly get any good nonce if I clock it over 279. I have the exact same circuit as provided by BkkCoins. The only difference is that my capacitor is 33pF, instead of his 30pF.

Great to see this!

I am having the same problem with CGMiner as you mentioned before. I am having 4 chips working. The same 2 NOR gates trick as BBKCoins suggested and the RC values are 100Ohm and 220pF.
I have tested the board with "ww" in ktest, it always return "GOOD" from 128MHz to 300MHZ and the return time is always correct as expected.

However, when I run CGMiner, it's stuck for up to 1 or 2 minutes  from time to time and the hashing  rate is always much lower than expected (128M WU=4/m, 300M WU=7.1/m).  And the HW is very high 10-20%.
I have tested it with different pools, all give the similar results.

I am going to change the 220pF capacitor to 30pF and test it again.

Progress update. The board is currently clocked at 256 and its mining at 3.6 GH/s. See https://bitcointalksearch.org/topic/m.2712124

WU: ~55/m. Error rate is really low too.

I still don't know what happened. I mentioned periods of total inactivity that I was noticing in the log file. I tried to debug it and realized that there was some kind of locking conflict while writing to the USB. I didn't change anything, was just trying to log additional information. Added a few lines of code to log in logging.c and miner.h. Tried to run again, and there were no conflicts anymore. Will look at everything again tomorrow and try to pin point the issue.

- I just thought that you run some test tasks on your first-revision board, not real mining. Thanks for the clarification - this point really drowned in the technical details.


- This information from you was, too, very helpful. Thank you again.

Cant wait for to hold the miners in my hands!  You are doing great job!

Cheers!

I'm not sure what you mean. I'm mining now at btcguild, which is a real pool. Maybe you mean, when can people actually get boards made? I need to revise the board design and then it will take time for companies to make boards and assemble them. You could probably allow for 2 weeks for that minimum. For my time to revise the board - it will take a few hours but I have put it off until I know for sure what revisions I need. The testing I'm doing now is focussed on finalizing hardware, and things like I2C and bootloader have been left until after I order new boards.

Ideally if it wasn't such a crazy rush to market everyone would wait until I test revision 2 before making production boards but I get the sense that no one wants to wait for that. So there is some non-zero risk that a 2nd revision could have errors. I'm really trying to avoid that. It would be great if others can check my revisions when released so there is better confidence that the board is really final.

Dear BkkCoins,

could you please to share your 'best guess' with us - how soon can we see your board mining at the real pool, even with incomplete set of chips (4 of 16 or so) installed?

Thank you in advance for your reply, we understand that you're working hard.

I should point out the reason to avoid duplicates is because it's evidence you're wasting time hashing due to overlap. You can monitor the duplicate values and take the mod with BankRange value to see how many hashes extra it went.

eg. this is my last duplicate 4021a1e5 and my Bank Range is 40000000 so it overlapped by 21a1e5, which is 2204133 decimal. So we know it hashed at least that many too far.

At 300 Mhz that is 7mS too long. The subtick clock is 21.33 uS so this is 7000/21.33 = 328 subticks too long. This is not the same as TICK_TOTAL because the subtick is divided according to clock rate,

TICK_TOTAL / Cfg.HashClock

For 300 MHz that is 12300/300 = 41 subticks per tick. So 328/41 = 8 ticks too far.

To zone in on best TICK_TOTAL you might reduce it by 8 and run some more looking again at duplicates.

***
Here's something interesting:
I can actually program the PIC while cgminer is running and the time from KLN failure to re-init and new work being sent is only 6 seconds lost. I'll see how 12292 does now.

MOAR BKK ARTS!

Try pushing up the TICK_TOTAL value from 12000 to 12300. The calculated correct value is 12307 but it needs a fudge factor for the "push time" and overhead timing error. I had it down at 12000 because earlier code gave too many duplicates higher, but I've changed how it works since then. I just ran at 12300 and it wasn't giving more duplicates and increased the nonce rate somewhat. Basically you want that close as possible to 12307 without giving many duplicates.

You can check duplicates easily by grepping the log file but it only makes sense statistically over a long run.

grep -P "FOUND NONCE|duplicate" cgminer.log |less -S

The correct measure of actual work rate is WU/min and that should be close to 60 / (2^32 / clk / chipcount). The MH/s rate will vary statistically due to luck but should average the clk rate.
eg.
60 / (2^32 /256000000/16) = 57.2

With that adjustment and my 4 chips at 300 MHz I'm getting 1146 MH/s on btcguild page. Error rate hovers around 3-5% now usually, so if you add that loss it's 1180 MH/s - pretty close now.

Regarding your clock limits - what NOR gate circuit and RC values do you have currently? I'm running the Dual NOR as scribbled up above further with 100R and 30pF. It works in manual work with ktest to 390MHz for me but I actually didn't try higher.

There is an API statistic collected that you can use to verify all chips are hashing. Make sure the API is enabled on default port 4028, then try this command, (you may need to install jsgrep, I don't recall where that came from, but if not findable I can post it here, or just skip the pipes below and look at raw data);

echo -n "{\"command\":\"stats\"}" | nc 127.0.0.1 4028 |tr -d "\000" | jsgrep |grep "Chip"

jsgrep is very short and useful for viewing any JSON output generally. It's one page python. I posted it here - http://pastebin.com/42EAYdiY - save and chmod +x.

If anyone is comparing stats on a long run, here are the multiple nonce percentages from a 300k+ run from Kano's git:

36.79% / 36.96% / 18.29% / 6.04% / 1.56% / 0.30% / 0.0040% / 0.0018% / 0.00%

More observations:

With Ktest:

1. With default clock (256) all the nonces come back good.
2. With clock 350, no nonces come back.
3. Upto clock 275 all nonces come back good.
5. At clock 276-279 some nonces come back bad, others good.
4. Clock 280 and up, all nonces come back bad.

After halving the work count:
The repeating nonce problem is solved. However, cgminer is not going over 200 MH/s (avg). I have tried with clock 256 and 275. (Update: Its actually crawling at around 25-50 MH/s)

After changing back work count:
cgminer went up to 800 MH/s (avg), with clock 256 and 1.2 GH./s with clock 275.

Hopefully this will help.

+1. I'll be tipping you quite heavily once I get miners in the hands of my customers. (My margins are, unfortunately, still too fluid to allow me to give you what you deserve until then.)

I'm sure this will be posted all over the place on BCT, but latest info from Avalon (via their email newsletter):


BKK -- you are doing a great job. The community really appreciates your hard work and talents.