Topic: Bounty[PAID OUT] : a bitstream for better utilizing the Cairnsmore1 157-294.5btc - page 3. (Read 21992 times)

Let the coins roll 

I'm more than happy that my personal requirements have been pretty much met. Everyone has been working hard to get it where it is and i'm only to glad to hand over the bounty now. Hopefully other people feel the same way. Overall i'm very impressed

I dont see way to exclude every forum member that did not pledge, so I feel the poll is a useless tool for our purposes.

Think it has to be done as a new topic, but instead you select "post new poll". Might be able to do it on an existing post, but it think it's fine to just make a new one.

https://bitcointalk.org/index.php?action=post;board=76.0;poll

Vote up. ..as soon as I can figure out how to make one. As soon as someone tells me where the fuq do I find tools to post a poll.

Actually screw that: If someone is opposed to paying out the bounty speak up in 24h.
After the latest run of flashing my boards, my mpbm reported hashrate is 854Mhs/ board, my average U is 5,78 and the hashrate reported at poolside is 845Mhs/ board. This leaves little room for doubt that the conditions have been met imo.
If your pre #50 board dosent get there, it's hardly the bitstream developers fault.

I'd pay the bounty out and suggest we do so unless relevant and valid arguments emerge and ppl not testing the bitstreams is no argument.

Hi Entropy,

great to hear you kept your promise and also compensated kano for the CM1 related tweaks in the Icarus driver.

Generally, I was following the development process most of the time at #cm1 and understand that reaching the current state is the outcome of a great teamwork between Glasswalker and makomk, with lots of help from more supporters. Going through the chat logs I'd say that TheSeven contributed significantly, not only with real-time updates to MPBM to support CM1 bitstream development, but also with bitstream development itself and code reviews.

Even if I do not use MPBM, I feel that his contribution deserves some compensation, but this is only my personal view. For the bounty that is soon to be paid out, I therefore suggest to not split the pledged coins to individuals by ourselves, but to send them to Glasswalker and let him distribute them in a fairly manner. He proved his professionalism and can best rate whom to thank for getting where we are now.


@Isokivi: I understand that most of us testers agree that the terms are sufficiently met to pay out the bounty. From my personal contacts with contributors I'd guess that 60% are ok with it. Are you going to initiate a vote and define acceptance criteria to get that officially passed?

Question on stability...

I am running the 200MHs bit stream by Makomk on 2 * CM1s, series 460-ish (at work and using memory) and mining using cgminer 2.7.0 (have used 2.6.1 for a few weeks previous to upgrade).

My concern is that the CM1 boards hang several times a day with all orange lights coming on. This is normally preceded by a "lame duck" event were one of the FPGAs go offline first (normally #2 and rates drop to 2~4u/m). The red "heart beat" still continues. The only way to get them mining again is to shutdown cgminer, then disconnect power to reset the boards and fire it back up. 75% of the time I also need to disconnect the USB comms cable whilst off inorder to reset the comm port. The boards are connected to independent USB ports on my gigabyte MB which has "power boost" dedicated lines so I dont think USB brown outs are the issue.

Is it peoples opinion that the poroblem lies in;
1. the bitstream is unstable, or
2. the CM1 hardware is unstable, or
3. the independent USB lines are causing EMI/EMC issues resulting in the system being unstable, or
4. cgminer has a bug, or
5. something else.

Your help in providing the most popular line of investigation is appreciated.

Awesome! Thanks Entropy-uc! We really appreciate your support! (I know I do, and I'm pretty sure I can speak for makomk and kano in that regard too)

Thanks!

I do think the total performance issue is a function of my network performance and pool performance.  I also think a little more time tweaking icarus-timing might push it over the hump.

Thanks for the advice Makomk.  I will give the new bitstreams a try once things settle out and my brain is on the same time zone as my body.  

Paid
25 BTC to Glasswalker
25 BTC to Makomk
5 BTC to Kano

Thanks for all the hard work you've put into this guys!

Glasswalker: I gave your 200 and 210 versions of the hashvoodoo a try. I can attest to the stability issues, so reverting back to what is rock solid performance of your 175 version.

Hope work allows you to some down time soon, I commend you for still being able to do much else while working those sort of hours.

Ah, that could be the bitstream bug I just fixed, though it doesn't generally seem to cause problems with the 200 MH/s bitstream. Please do reflash the badly-performing board with the new dcmwd4e bitstream when you get back home and have got a moment - this is a pain for me to test because the issue takes a while to show up and affects some boards more than others.

Curious. Have you been getting a lot of warnings from cgminer about your pool not providing work fast enough? It's not just the U/m that's underperforming, the MH/s reported by cgminer is lower than it should be and I think that's generally caused by a slow pool.

OK, thank you! I see Glasswalker has spotted this and replied already. Hopefully (touch wood) with the fixes above and/or the new 210 and 220 MH bitstreams I've already released performance should be comfortably over the line and you won't regret paying out. My testing board is actually at 855 MHash/s of a theoretical 860 based on the U/m reported in MPBM right now, though it's only been running for 12 hours. I believe ebereon was seeing similar speeds on his farm with the bitstream this is based on before it started falling over, so (fingers crossed) the new one ought to be able to manage that stably on a decent proportion of boards.

I've actually released full-performance bitstreams (dcmwd4e) with the fix now and am waiting to hear how they work out. My own testing is looking really, really promising though.

Ouch. No wonder you didn't have any time for bitstream development.

PM Sent.

I also want to apologize for the delays in the last few days. My day job kind of exploded (critical project went into crisis mode, and I got pulled in to deal with it, so starting this past weekend I've been working from about 8am till 1am every day. Today I'm working from 3am until god knows when due to a timezone shift with one of our partner offices... So I've had to pause my work on the bitstream for the past few days.

This insanity should be resolved by this weekend.

In the meantime, I have released an updated 200Mhz bitstream that runs at 200Mhz with almost no invalids. BUT it has some stability problems. In my absence, makomk has been working on the problem, as he began experiencing similar instability in his bitstreams as well. I thinks he has found the solution to the problem and is doing some test builds of his bitstream to see if it resolves them. If it does, we'll backport those changes to the HashVoodoo bitstream. In addition, collaboration with TheSeven has resulted in a few more improvements we plan on dropping in to the next build as well to once again re-inforce stability.

This should get us to a usable 200Mhz plus bitstream with the rock-solid stability we saw in the previous hashvoodoo bitstream (so working on ALL boards, including the older gen, sub50 serials, and any "problem" boards). At least that's my hope.

Then we're going to take a short break from releases for an unavoidable step:
We'll be building (and releasing with the source) a full testbench for use with the Xilinx simulator, allowing simulation of the bitstream before building. This will allow us to debug (in a more conventional software dev form) the bitstream, by walking through clock cycles, and seeing where things muck up. This will also allow faster problemsolving as the simulation can happen after only a partial build (basic synthesis) not requiring mapping, or placement and routing, and timing closure. So with the simulation we can test new features, ensure they work, saving build time drastically...

Making a testbench isn't quick or easy (at least not doing it properly) but I think it's the right thing to do. I've been avoiding it until now, but at the urging of TheSeven and makomk, I think it's the right thing to do to have a single solid bitstream we can all easily develop and debug. This will likely mean a week or so "pause" in any future releases (once I get back to it) so aside from this next "bugfix/stability" release using makomk's fixes, I wouldn't expect any additional releases until approximately the end of Aug, maybe first week of Sept.

After which, progress should be faster, and our ability to squash bugs will be greatly improved

Anyway, what I'm getting at is a rediculous amount of effort has gone into these bitstreams, and both the HashVoodoo, and makomk's direct fork have benefited greatly by our cooperation and collaboration since we decided to join forces. And we still have several surprises coming once we get the foundation laid and the core features settled (the new hashing core promises to present a significant boost in performance, once we've ironed the kinks out).

Development isn't going to halt on this bitstream, it's just going to keep getting better. But I also think we're lightyears ahead of where we were with the cairnsmore. We now have several "semi-stable" bitstreams in the 200Mhz range as posted by several others on this and the other thread. And for those of you having problem boards, the 175Mhz hashvoodoo bitstream (08_16_2012 release on github) has been tested thuroughly on many boards, including some of the most troublesome boards that were already packed up for RMA, and it works beautifully and 100% stable. So give that a shot to revive your lost-cause boards.

If you're having problems flashing, please read the readme in the latest HashVoodoo release. It has several tips/tricks for flashing that help in problem cases.

Anyway, just wanted to post that update (I had a few minutes waiting on an email response, so had some time to breathe between marathon work sessions). So you were all aware of where we're at.

Thanks for your support!

I will give my opinion.  Others may think differently, there is such a broad range of hardware performance that everyone is going to have different experiences.

Below is the performance of 8 recently build boards (>04xx) after running Makomk's latest 200MHz bitstream for 4 days.

cgminer version 2.6.4 - Started: [2012-08-17 13:46:13]
-------------------------------------------------------------------------
 (5s):6241.1 (avg):6106.0 Mh/s | Q:998120  A:576799  R:366  HW:0  E:58%   U:79.1
 TQ: 1  ST: 16  SS: 0  DW: 26304  NB: 840  LW: 0  GF: 2106  RF: 8
 Block: 000005866228c10025bc465254296925...  Started: [15:04:14]
-------------------------------------------------------------------------
 ICA  0:                | 381.4/381.9Mh/s | A:38392 R:34 HW:0 U:  5.27/m
 ICA  1:                | 387.2/382.1Mh/s | A:39066 R:26 HW:0 U:  5.36/m
 ICA  2:                | 390.1/382.1Mh/s | A:39067 R:20 HW:0 U:  5.36/m
 ICA  3:                | 388.1/382.0Mh/s | A:38908 R:25 HW:0 U:  5.34/m
 ICA  4:                | 386.1/384.1Mh/s | A:38836 R:22 HW:0 U:  5.33/m
 ICA  5:                | 380.6/381.9Mh/s | A:39043 R:21 HW:0 U:  5.36/m
 ICA  6:                | 390.7/384.2Mh/s | A:38854 R:31 HW:0 U:  5.33/m
 ICA  7:                | 385.1/382.0Mh/s | A:38711 R:23 HW:0 U:  5.31/m
 ICA  8:                | 390.9/384.4Mh/s | A:39281 R:24 HW:0 U:  5.39/m
 ICA  9:                | 382.9/382.0Mh/s | A:38805 R:24 HW:0 U:  5.32/m
 ICA 10:                | 371.0/375.4Mh/s | A:15949 R: 9 HW:0 U:  2.19/m
 ICA 11:                | 371.0/375.4Mh/s | A:16269 R: 9 HW:0 U:  2.23/m
 ICA 12:                | 384.3/382.2Mh/s | A:38974 R:22 HW:0 U:  5.35/m
 ICA 13:                | 378.8/382.1Mh/s | A:38997 R:36 HW:0 U:  5.35/m
 ICA 14:                | 386.5/382.1Mh/s | A:38864 R:25 HW:0 U:  5.33/m
 ICA 15:                | 392.9/382.0Mh/s | A:38784 R:15 HW:0 U:  5.32/m
-------------------------------------------------------------------------
               

The total utility of 79.1/minute corresponds to 708 MH/s per board but this is being dragged down by one badly performing board.  If I remove that board from the calculation, I get an average performance of 740 MH/s.  That is still a hair under bounty target.

But it is close enough that I think the spirit of the offer has been satisfied. There is also some risk that the value of bitcoin will dump in the near term as the pirate dust settles (or hits the fan).  I don't want them to get shorted in such a situation. So, I intend to pay out my share of the bounty reward equally to Makomk and Glasswalker as they agreed.  I have an address for Makomk already; Glasswalker if you PM me a deposit address, I will pay out the bounty the next time I have access to my wallet.

If you want any help writing up documentation, you know I've tested it enough

For sure, I just wanted to make sure I wasn't setting wrong expectations

Yeah documentation will come soon. The readme is there and it is "complete", but it is rather vague. And doesn't cover any "special" cases, or odd problems. It basically just covers hardware settings, and installing (referring out to the enterpoint instructions, or assuming access to ISE Impact and a JTAG cable).

Once we have the next version out that's the last major feature change. After that the bitstreams should remain functionally identical, just with performance improvements or internal structural improvements (without changing overall functionality at all).

Eventually way down the road more documentation will be needed for the new protocol but that's a ways off still.

Once I get the next release out and it's working, (dynamic clocking) then I'll take a bit of time to do a full documentation writeup, and hopefully the community can help me flesh it out once I get a foundation laid down.

I've had more problems than most, I wouldn't disagree there. Also I'm not blaming your bitstreams, just like I said before I don't know what is causing the problems I am experiencing. I get it working eventually, it just doesn't always stay stable, I can't pin down what is causing it yet.
Documentation is the only thing left, you guys working flat out, I don't expect a lot, It's why I do my best to write mine up.

Keep in mind that your recent experience with the 2 boards dropping off, that is not a bitstream issue (or rather I'm 99.9% sure it's not a bitstream issue).

For 2 physically different boards to drop off at nearly the same time, all 4 ports to vanish from the OS, but the chips keep the heartbeat going. That's not a bitstream problem. It's either hardware (board level) or infrastructure (cabling, host PC, software, driver, hub, ports, whatever) which is unfortunately outside our control. The only part of the bitstream that it could be (on a long shot) is the controller, as that interfaces directly to the FTDI and could impact the performance of the FTDI (and therefor cause this "dropping off". But the fact that 2 boards did the same thing in approximately the same time leads me to believe it was something outside the mining boards themselves.

That said I'll do my best to try and help you identify the issue, as many others will I would hope as well. Hopefully it either never happens again, or it happens again but you're able to get more detailed info from it to help diagnose.

Just wanted to clarify that the future bitstream releases will be focusing on first the dynamic clocking, and next the new hashing core. Neither of which would have any impact at all on this particular issue. So I wouldn't waste time hoping that the new versions will solve this particular issue. That said the FINAL goal of the new controller, with the completely new communications protocol (that would use only a single USB for an entire cluster of boards) would likely help aleviate this, due to an architectural change, but it wouldn't actually solve the problem (merely work around it). But that one is a long way off.

Just wanted to make sure we're not setting the wrong expectation

When I had it stable I agreed with many, that yes it did meet the requirements. However I've had stability problems since and I don't know what the cause is.
However they haven't really finished a polished version yet and apparently working together now, so I guess that new combined one once ready will win it.

What's the current status regarding the bounty? The way I see it, all requirements for paying out the bounty are met... (I cannot judge point 6, documentation)

I opted for this instead (will probably get it in 3 weeks):
http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=120927703340
I hope it works as advertised, I could have bought the cheaper parallel version, but I have far more USB ports than parallel ports...

With some pains and various makomk bitstream combinations I think I can hit a ~650MH/s per board configuration which doesn't crash every day while waiting for it. I really hope the new controller firmwares are worth it!