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

[steamboat]

what U value should I be expecting from the shortfin200 and 210 streams?

[1713504110]

1713504110

[1713504110]

1713504110

[Isokivi]

what U value should I be expecting from the shortfin200 and 210 streams?

If my memory serves me correct 200 should be above 5.2 (right now I have a 52h run saying 5.44 and 5.54 on 200mhs) I dont have a pair running 210 atm. Currently Im running a mix of 220-200mhs bitstreams, with U:'s between 5.44 and 6.06.

[ShadesOfMarble]

(MH/s) div 71.5 = (U/min)

[Isokivi]

(MH/s) div 71.5 = (U/min)

I believe the U factors in invalids too, am I right ? ..what about rejects ?

[zefir]

(MH/s) div 71.5 = (U/min)

I believe the U factors in invalids too, am I right ? ..what about rejects ?

Utility in cgminer is defined as (total accepted shares / total uptime in minutes), i.e. it is what the pool is paying you for. It considers HW errors, invalids and rejects and is therefore the best available measure for your effective hashing power in the long term.

In contrast to that, the MH/s value reported for Icarus / CM1 may be off if your board has problems. That is due to the lack of explicit reporting when the FPGA searched the whole nonce range without finding a share. If after the given or calculated timeout you do not hear from your CM1, you assume that it processed the range and add 2^32 (or more precisely: the number of hashes you assume should have been processed during this period) to the share counter. In fact, the FPGA might have entered a hang condition and just stopped before being restarted by the watchdog. Then your MH/s value looks better than it actually is.

If your board has no problems, in the long run MH/s = U * 71.58. If you find your board's values are too far off from this relation, watch your board and you should find it being restarted by the watchdog regularly (see the orange LEDs lit).

[Glasswalker]

Note, the orange LED doesn't directly mean the watchdog is firing. All that means is that literally the chip isn't currently hashing, it's waiting for more work from the host.

If the Orange LED is lighting though, it does mean your board isn't hashing during that period (So at least a small percentage of the time, depending on how much the led is lit, it's idle, and not making money). This can simply mean that the job interval is incorrect, or the pool is not providing work fast enough (if the led is only lighting for short bits here and there) but if it's staying on for longer periods of time, like a minute plus, and does it frequently then it likely signifies a hardware (or at least a bitstream) problem.

There is a watchdog in the software typically that attempts to send fresh work down if it hasn't heard from the miner in too long a period. The other watchdog in the FPGA itself is purely for detecting if the DCM goes unstable, and restarts the DCM to acquire a new clock lock.

[zefir]

Note, the orange LED doesn't directly mean the watchdog is firing. All that means is that literally the chip isn't currently hashing, it's waiting for more work from the host.
[...]

Yep, that's all true.

My statement is based on the observations I have with some of my boards running makomk's latest 200MHz bitstream. To be safe on the timeout value on SW side, I always run cgminer with --icarus-timing long, which effectively prevents FPGAs from running out of work and idling. What I observe are boards (that always have been 'problematic') flash their orange LED quite often (in the range of every 2 to 5 seconds), which I interpret as watchdog restart. The calculated hashrate for those boards is obviously inaccurate, i.e. the relation between U and MH/s does not match the 71.6 ratio in the long run (12h+).

[zefir]

Bounty transferred: 200 BTC sent to 1KqMBXSmZDFzCsZqp84mNB3QM3t2bV3BaB
Transaction: 2a6823eb8a6c578e5c66f6f9af94fae952acf1329e28b609c9ae09d2a006a707


Thank you all for the support. And of course thanks to Glasswalker, makomk, TheSeven, and all others for their enormous effort.

[steamboat]

after 14 hours 16/18 pairs running the new 210 bitstream on cg 2.6.something are reporting U between 5.46 and 5.72, which seems to be falling into the range of +/- 7% that i have been seeing with the streams.

2 pairs are reporting 3.95 and 4.8, which i will test the 200 stream on on monday to see if I can bring that up to the low 5's.

assuming it's only p3 on the pairs that are failing, that means 94% stable w/ the 210 on 9 boards, though they're only producing ~200mh/s.

nice work guys, keep it up.

[Glasswalker]

Hey, just wanted to say on behalf of Makomk, TheSeven and Myself, thank you all for your support and contributions!

I wanted also to confirm reciept of 200BTC for the bounty payment.

I have redistributed it in the way that makomk, TheSeven and myself discussed:
90BTC was sent to Makomk via TXID: d7381ae9e651f18d8ecb65b98e8d87f77010336b248dca13c97bf09f49ae585b
20BTC was sent to TheSeven via TXID: 063beec9f0cf6cfc602e0e734054d9ff3d9daeaf628d975ce0eb8d6e6d87789d

Bounty has officially been distributed.

Development will of course continue, and we hope to improve features, reliability and peformance significantly over the next little while.

Thanks again!

[makomk]

I have redistributed it in the way that makomk, TheSeven and myself discussed:
90BTC was sent to Makomk via TXID: d7381ae9e651f18d8ecb65b98e8d87f77010336b248dca13c97bf09f49ae585b
20BTC was sent to TheSeven via TXID: 063beec9f0cf6cfc602e0e734054d9ff3d9daeaf628d975ce0eb8d6e6d87789d

Bounty has officially been distributed.

I can confirm that I've received my portion of this. Thank you!

Development will of course continue, and we hope to improve features, reliability and peformance significantly over the next little while.

Indeed, though there's probably not going to be any huge performance improvements from my end of things in the immediate future. The latest dcmwd4e bitstreams are already into ztex territory speed-wise, even though getting your rigs there requires more manual fiddling than it ought to.

[Cranky4u]

all stable now with <1% errors...I added "--icarus -timing long" and now have stabilised 2 CM1s at 380~399MHs...very happy camper

[LazyOtto]

Is it now time to close/lock this thread and redirect all conversation over to "Quad XC6SLX150 Board - Initial Price £400/$640/520€"?

I'm in favor of having one less thread to watch.

[LazyOtto]

Oh, BTW, thank you Glasswalker and makomk.

Once I actually *have* some of these boards, I'll send some BTC to y'all.

(And, TheSeven. Which is high time since I'm using MPBM with my BFL Single. And I've enjoyed hacking the Python some myself.)

[Stephen Gornick]

redirect all conversation over to "Quad XC6SLX150 Board - Initial Price £400/$640/520€"?

Link:

 - http://bitcointalk.org/index.php?topic=78239.0

[LazyOtto]

This question is directly related to 'the bounty'.
Maybe there are still a few loose threads to be resolved.

Even though the bounty has been paid, IIRC, one of the conditions was that it be solved by an open-source solution with a clearly defined tool-chain and build process.

Have those conditions actually been met?
If so, I'm having a bit of a problem chasing down the info.

Can we have some 'close-out' posts summarizing all that, please.

--

I'm not saying I don't appreciate all y'all's hard work to date, but I am interested into digging into the guts of this stuff myself.

[Glasswalker]

For hashvoodoo, I still need to flesh out the documentation a bit more. But the project files and all required metadata are included in the github, the release is fully opensource.

Using Xilinx ISE 14.1 just clone the git repo, open the project, and synthesize/implement the project. All settings and whatnot are included in the project file already.

Eventually I'll flesh out some documentation on how to do that in detail, but ultimately that's getting into the grey area of using ISE in general, and being familiar at least on some level with FPGA development.

I also believe Makomk's version includes the same project files, but not 100% sure.

I've also included an NCD/NGD of the built version, and the project is setup to use smartguide so you at least get "close to useful" performance...

If you have specific questions, I'll do my best to answer for now, and soon we'll update the docs with more details. But even with the current release, it is a fairly straightforward process to *build* it. The problem is making a release worthy (ie: with useful performance) bitstream isn't a straightforward process regardless of how well we document it. There is a fairly steep learning curve to working with FPGAs in general versus for example compiling a C program.

Does that help?

[LazyOtto]

Yes it does. Thank you.

--

edit: I'll just search this thread to find the git link.

[ShadesOfMarble]

It's in his signature

[makomk]

Mine's a bit annoying in that you can't actually build it from source and get the same level of performance that the released bitstreams reach. There's a source archive in the dcmwd4e release, and if you unpack that, download and unpack the .ncd from http://www.makomk.com/~aidan/shortfin_dcmwd4e_ed_ncd.7z, and add the unpacked .ncd to the supplied project as a SmartGuide file (right-click fpgaminer_top in the left pane in ISE, select SmartGuide, point it at that file) you ought to be able to get speeds that are good enough for testing purposes. If you're willing to do a long SmartXplorer run you ought to be able to get the speeds up to release levels; I didn't because it's a bit hit and miss and would delay the release by quite some time.

Edit: As I've said before, honestly you might be better off using the hexanchus branch if you want to build from source right now ("git clone https://github.com/makomk/Icarus.git; cd Icarus; git checkout -b hexanchus origin/hexanchus"). Slightly slower than the released bitstream, but I think it's the fastest of mine that can actually be built from source, and you should literally just be able to open the project file up in ISE and build it.

Edit 2: hexanchus requires different DIP switch settings though; on all the FPGAs where you'd normally set switch 2 to off, you also need to set switch 4 to off as well.