Bounty[PAID OUT] : a bitstream for better utilizing the Cairnsmore1 157-294.5btc

[Cranky4u]

ok...after 18 hours of testing, well short of the 48 hours I hoped for, here is my 190 bit stream findings;

System - Win 7 64bit, cgminer 2.6.1 + phatk, cm1 #62-0432 & #63-0433
Average hash rate per cm1 = ~725MHs at pool & via cgminer Note: neither board is reaching the bounty threshold of 750MHs
Average U = 17.5~17.8/m
HW & R are very low. HW = 0 & R <5
Maximum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 14 hours
Minimum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 0.5 hours
Average restarts of cgminer before both boards detect successfully - 3
Identified conflicts - use of 2nd 6770 GPU for mining causes system to BSD on start up of cgiminer or intedpendent start of of phoenix miner when cgminer is FPGA only. Note: Can mine on 1st 6770 GPU though.

I hope this helps developers...
Tweakers, any idea on how to tweak to get up to 750MHs and improve stability?

What are your per worker U values? U=17.5 on 2 boards looks like 1 fpga isn't hashing which is a common issue with that bitstream.

running as pr above but on + poclbm gives (approx)
ICA 0: 360/360    U: 4.30/m
ICA 1: 355/360    U: 4.15/m
ICA 2: 355/355    U: 2.05/m
ICA 3: 360/360    U: 6.75/m

overall U: 17.3/m

hint? is ICA2 not flashed properly despite VM saying it was a success?

[1714193762]

1714193762

[1714193762]

1714193762

[1714193762]

1714193762

[spiccioli]

Hi,

I've sent my second 10 BTCs bounty part.

https://blockchain.info/tx-index/14400138/b6f539f3d23fe868d1e204f88c8e91f417435134b62bd64f79ffbc3844c5ab88

spiccioli

[makomk]

running as pr above but on + poclbm gives (approx)
ICA 0: 360/360    U: 4.30/m
ICA 1: 355/360    U: 4.15/m
ICA 2: 355/355    U: 2.05/m
ICA 3: 360/360    U: 6.75/m

overall U: 17.3/m

hint? is ICA2 not flashed properly despite VM saying it was a success?

It probably did flash properly, it's just that one of the FPGAs on ICA 2 has frozen. Probably FPGA1, that always seems to be the one that falls over first on ebereon's boards.

[Cranky4u]

so after some time...I stabilise around the U: 5/m ICA line in cgminer...is this right for the 190MHs bitstream?  basically what sort of rate should I be getting? My pool is reporting about 1200~1400MHs for 2 * CM1 190bit flashed systems

[ShadesOfMarble]

Multiply U with 71.5827883 to get the MH/s.

[Lethos]

@ cranky4u

I've got 2 boards and 1 of my boards does that. The other mines full throttle.
Reflashing sometimes helps. I am 50/50 on if it's a hardware or bitstream issue.

I do figure however since one works perfectly it atleast has a chance of being fixed by an improved bitstream.

[Cranky4u]

ok..so I have finally deduced what functions the cm1 board lights represent and no, I didn't find it in any enterpoint instruction manual.

FPGA on standby or idle (not mining)
Orange, constant - standby

FPGA mining
Green, flash - found a successful result
Orange, flash - normally with green flash, mining
Orange, constant - FPGA not responding  ---shit itself or controller not communicating with it

I have p1 on 62- 0433 presenting a constant orange during mining so I assume it is playing up...will reflash 190MHs bitstream tonight and report back

[Cranky4u]

ny1 know if I can run different bitstreams in each FPGA..eg p0,p2,p3 = 190MHs bitstream whilst p1=180MHs

thinking of this as p1 is unstable and keeps shitting itself. NOTE: "Shitting itself" is a professional engineers term for fucking up or crashing

[Glasswalker]

To be exact, the LED meanings in the "standard icarus" bitstreams (such as makomk's current 190oc release for example) are:
0 - Found a Share (flashes, then fades out)
1 - RX (FPGA received data on the serial port)
2 - TX (FPGA sending data on serial port)
3 - Idle (this lights when the FPGA has no current work to do)

The colors in order are:
0 - Green
1 - Red
2 - Blue
3 - Amber

Those functions are static (ie: they don't change depending on what "mode" the fpga is in).

For the HashVoodoo bitstream (Still not working right as of yet) the LED meanings are:
0 - Found a Share (flashes, then fades out)
1 - Clock Heartbeat (flashes on a heavily divided clock signal to indicate the FPGA is getting a good clock signal and hasn't locked up)
2 - Serial Activity (blinks on transmit or receive on the serial port)
3 - Idle (lights when the FPGA has no current work to do.

It should be noted that on both bitstreams currently the serial rx/tx LEDs light so fast typically you hardly notice them (if at all). I intend to add a (faster) version of the "fader" code from the share found LED code to the serial activity LED, to stretch out the blink duration some, to allow it to be more obvious when the FPGA is communicating.

To answer your question about multiple bitstreams:

In theory that should work fine. The comm clock, and hashing clock are different clock domains, so the communications code should keep on working just fine, while the hash clock can be at different rates. It may end up resulting in the entire nonce range being missed sometimes though (ie the 190 is in "front" and 180 in "back" the 190 starts the job, and forwards half it's nonce range to the 180 bitstream, but the 190 will finish before the 180 has finished, resulting in a small percentage of the second half of the nonce range being "skipped"). I don't think that will hurt overall hashrate, but it might skew some of the other stats slightly. Ultimately the impact should be nearly nothing.

Hope that helps

Also a quick status update on HashVoodoo development:

The first test bitstream using LVDS clock signalling was completed, but we're still having communications issues. So I'm now doing some debugging of the comms stuff.

The good news is that the LVDS clocks seem to be stable in all 4 slots, even on my 0001 serial number board! So I think if we can solve the comms issues, we're really onto something with this one!

Please note, I don't reccomend installing this bitstream just yet, (the .bit isn't released) because it's not quite working right. Once I get it hashing on my end, I'll release the full binary bitstream for you all to test out. I don't want to cause more headaches by releasing a malfunctioning bitstream (and I've encountered some wierdness on the jtag lines now, so I want to rule out the bitstream as a cause. The last thing I want to do is release an update that breaks your usb updating ability).

I'll post more when I have it.

[Cranky4u]

Glasswalker...thank you for that great update!

[steamboat]

the escrow held by Zefir is now up to 185 btc. lets go glasswalker/makomk/mystery genius, we need more MH/s!

[makomk]

Right now I'm mostly waiting to hear how Glasswalker's latest bitstream will turn out. It sounds really promising, touch wood.

[Glasswalker]

Right now I'm mostly waiting to hear how Glasswalker's latest bitstream will turn out. It sounds really promising, touch wood.

Well I closed timing (175Mhz target, with about 1us to spare) this morning. Unfortunately the build was missing termination on the LVDS clock lines. So that will hurt overall performance. When I get home I'll run that through fpgaeditor and see if I can correct it and do a bitgen from that. Then I'll test that out.

Also I'll try to get the controller fixed so USB programming isn't broken. Then we can get the .bit for the current source code released so everyone can try it out.

If we can get this thing up to 200Mhash, and reliable on all the boards, then I'll shift my focus back to the HashVoodoo core, to replace the ztex/icarus core I'm using now. Which will shift us to a "sea of hashers" style approach.

Anyway I got super busy this past week roughly, so haven't been able to spend as much time on it. Luckily I had a like 5 day long smartxplorer build going, so I wasn't wasting time completely.

Also FYI: the current source code on github is what I've done the current build based on.

If this works (even marginally) then the next step is to backport any of makomk's tweaks into this bitstream, and a few other fixes/adjustments I've thought up. Then provided we can get roughly 200Mhash out of this one, I'll leave it there.

[Isokivi]

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

Im seeing an average speed of 800Mhs reported at poolside, one troublesome core-pair is pooping out an invalid rate of 3,15%. but it seems like we have a winner, I dont have a long enough test-run yet, but there should be no uptime-issues to be expected.

If you want your word in on wether or not this qualify's for the bounty: the time to act is now, test it, call out about missing or insufficient documentation, do something.

[ShadesOfMarble]

I will start testing the 200 MH/s bitstream on my SN 26 board tomorrow.

[steamboat]

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

Im seeing an average speed of 800Mhs reported at poolside, one troublesome core-pair is pooping out an invalid rate of 3,15%. but it seems like we have a winner, I dont have a long enough test-run yet, but there should be no uptime-issues to be expected.

If you want your word in on wether or not this qualify's for the bounty: the time to act is now, test it, call out about missing or insufficient documentation, do something.

I'm running it now on 9 boards. will tell you in 24 hours how it looks.

update:
after 2 hours cgminer shows 6942 total, 771 per , pool shows 6761, 751 per , 99.9% accepted on both.

22 hour update: cgminer shows 6839 total, 759.8 per, pool shows almost exactly the same, 99.98% accepted on both.

[makomk]

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

I should note that whilst I have released the source corresponding to those bitstreams, there are no instructions to build similar bitstreams from the source because you can't do so trivially. That source is actually back-modified to match several direct edits I made to the compiled .ncd in FPGA Editor - you can download that from http://www.makomk.com/~aidan/shortfin_dcmwd4c_ed_ncd.7z if you want to poke about yourself. You should be able to get fairly close by pointing Smart Guide to that ncd (unzip it, right-click fpgaminer_top in the Hierarchy pane in ISE, choose Smart Guide and point it at the NCD, then click the green Implement arrow in the toolbar) but that dents performance by several tens of MHz. You'll also need to run mkrelease.sh which executes some FPGA Editor scripts that are needed to get the bitstreams to run.

(Honestly, if you want to do development the halffin-dev branch in my git repository is much nicer to work with, it just doesn't quite have the same performance yet. Or there's Glasswalker's stuff, which is quite nice too.)

[Isokivi]

As far as my boards are concerned the latest 200Mhs bitstream takes the bounty. I have been hearing about issues with pre #50 boards,but Im fairly sore most or all of us can agree that that has got to be a hardware issue.

[gyverlb]

My boards (62-0110 and 62-0111) aren't happy yet :

This is with the 190 version in the same batch after 1 hour on cgminer 2.6.4 with --icarus short:

Code:

ICA 0:                | 377.5/375.7Mh/s | A:304 R:3 HW:0 U: 5.19/m
ICA 1:                | 377.3/375.2Mh/s | A: 21 R:0 HW:0 U: 0.36/m
ICA 2:                | 379.3/374.2Mh/s | A:318 R:1 HW:0 U: 5.43/m
ICA 3:                | 384.8/410.8Mh/s | A:213 R:2 HW:0 U: 3.64/m

ICA 1 and ICA 3 are linked to the third ttyUSB interfaces of each cairnsmore 1 board on my systems (the latest udev rules published on the forum are quite nice) :
ICA1: /dev/cm-62-0111-if02
ICA3: /dev/cm-62-0110-if02

From what I can tell (orange LED often on), these are the interfaces linked to the 1st and 2nd FPGA on each board. The #62-111 board has indeed both FPGA 1 and 2 orange leds on most of the time. I can see the FPGA 2 orange LED on #62-111 quite often too.

I had a run with 190 on all FPGAs except FPGA 1 where i put the 160 bitstream from the same batch on each board.
Here is the result after 6 hours :
60-110-if02: 3,84
60-110-if03: 5,03
60-111-if02: 3,44
60-111-if03: 5,05

My main problem is that results are quite inconsistent and most of the time hard to get: the tty interfaces vanish often and unpredictably. Some days I have to reset boards by removing power/USB half a dozen times.

My problem might be that I can't update the controller and still use the 1.1 firmware on it but I don't have any solution for it (no Windows license here).

[Doff]

My boards (62-0110 and 62-0111) aren't happy yet :

This is with the 190 version in the same batch after 1 hour on cgminer 2.6.4 with --icarus short:

Code:

ICA 0:                | 377.5/375.7Mh/s | A:304 R:3 HW:0 U: 5.19/m
ICA 1:                | 377.3/375.2Mh/s | A: 21 R:0 HW:0 U: 0.36/m
ICA 2:                | 379.3/374.2Mh/s | A:318 R:1 HW:0 U: 5.43/m
ICA 3:                | 384.8/410.8Mh/s | A:213 R:2 HW:0 U: 3.64/m

ICA 1 and ICA 3 are linked to the third ttyUSB interfaces of each cairnsmore 1 board on my systems (the latest udev rules published on the forum are quite nice) :
ICA1: /dev/cm-62-0111-if02
ICA3: /dev/cm-62-0110-if02

From what I can tell (orange LED often on), these are the interfaces linked to the 1st and 2nd FPGA on each board. The #62-111 board has indeed both FPGA 1 and 2 orange leds on most of the time. I can see the FPGA 2 orange LED on #62-111 quite often too.

I had a run with 190 on all FPGAs except FPGA 1 where i put the 160 bitstream from the same batch on each board.
Here is the result after 6 hours :
60-110-if02: 3,84
60-110-if03: 5,03
60-111-if02: 3,44
60-111-if03: 5,05

My main problem is that results are quite inconsistent and most of the time hard to get: the tty interfaces vanish often and unpredictably. Some days I have to reset boards by removing power/USB half a dozen times.

My problem might be that I can't update the controller and still use the 1.1 firmware on it but I don't have any solution for it (no Windows license here).

I would just try and download a copy of Windows 7 install it without a key, you get 30 Days trial, or borrow someones Win7 Cd and load it from that. That way you could at least get to 1.3, or 1.4 now. You don’t actually need to own the copy just get it installed and use it for 30 days.