Thank you for the support. And thanks to all contributors so far, we just entered the three-digit range (113BTC as of writing).

Keep it rolling!

As far as I understood Yohan and Glasswalker, the Baudrate is dependent on the array controller's clock. And Glasswalker's recent bitstream operates in 25MHz mode, effectively requiring to set serial line to 57.6 kBd. Just posted a pull request to add support in fpgautils.c as preparation for a CM1 driver for cgminer.

Let's fix that outside this thread, I'll contact you personally.

You need to build from source with the following patch applied:

To build:

And finally run with
assuming you have a valid ~/.cgminer/cgminer.conf

Got Glasswalker's test bitstream programmed and working.

Took my most stable board (2.63 + 2.63U with twin-test), programmed to SPI and seems to work. After ~25 minutes I get:

As Glasswalker mentioned, one FPGA is idling (orange LED lit), but 7.5U is way better than 5.3U

For programming the DIP switches are to be set as Yohan was explaining in the post here, while for mining the mini-howto is almost complete: you need to switch all FPGA DIP switches (2-5) ON.


For those working with Linux, I am using the xc3sprog toolsuite natively, built from SVN with the patch I posted here and the following script (ran as sudo):

You'll need to build cgminer from source with the Baudrate set to 57.6k to mine.


Edit: copy-paste garbage fixed

Hi Isokivi,

sorry if I got it wrong: you as the thread owner and bounty initiator should have done the escrow, but AFAIR you refused to do that and since some of the folks here know and trust me, I took the initiative. That might have been premature, but anticipating the bitstream to be ready this week it was not too early. If you changed your mind and want to take the responsibility, I'll be glad to send you the collected coins or give you the private key to the existing address.

Otherwise (as already stated somewhere) having 50 CM1 boards I have a personal vital interest that the advanced bitstream shows up as fast as possible and the bounty gets paid. If you need to check whether you want to trust me, just visit my mining bond thread (see my sig) and read the second post.


Thanks, Zefir

Ok folks, here we go.

I have put up a spreadsheet where I will account the contributions for this bounty.

The coins will be deposited to 1CM1bj7jxVskkvKE2kcw6L16rHMXL38aFm.

I am not going to send every contributor a personal address for correct assignment. Instead, send your money to the given address and at the same time PM me (forum mail to zefir or via email) with how much you contributed. That should be enough information to match the payment to sender.


Did I forget something? If not, let the coins roll!


@Isokivi: could you please copy the related info to the first post? Thanks!

Thank you for your trust and support. If majority is fine with me, I'll do the escrow.

In fact, I think the coins should be collected beforehand, instead of waiting the bitstream to be finalized. Due to the persistent dynamics in the Bitcoin world, too many potential events (like BTC skyrockets to 100$, pirate loosing all our coins in Vegas , etc.) can make it harder to collect the coins later people are willing to contribute today.

If everyone is ok, I'll set up an offline address for the bounty and a Google Docs spreadsheet to account the contributions.

Cheers, Zefir

Update: dividends for week 29.2012 paid, external mining contracts terminated

Dear Investors,

the dividends for week 28.2012 were paid in time with no significant news to be told. With today's payment for week 29.2012, ZETA-MINING is independent again: the external mining contracts that backed the hashing power until the Cairnsmore1 boards arrived were canceled effectively by mid of July.

The current hashing power is around 20GHps:

• the 5 BFLS still provide 4GHps (so far, summer in Switzerland is cold )
• 30 CM1 boards work stable in Icarus mode with a constant 0.38GHps, providing another 11.4GHps
• the remaining 20 CM1 are unstable with various problems (e.g. only one FPGA pair mining, low hashrate, no valid shares, etc.) and deliver a combined hashrate between 3 and 5 GHps; they will be soon returned to Enterpoint for further inspection.

Note that the given hashrate is provided in Icarus mode, which means that
 a) only half of the FPGAs are used for mining
 b) the bitstream is not optimized for the CM1 HW

An Icarus based bitstream working on all four FPGAs will be available soon and double the hashrate per board, while a dedicated CM1 bitstream is supposed to unleash the full power and provide up to 1GHps per board, but will take longer to get finalized. The week I first see ZETA-MINING total hashing power exceeds 50GHps, I will add a one time 100% bonus and double that week's dividend payments. Stay tuned!


Have a nice and successful week,
Zefir

Once things get started, they are getting momentum

Yohan's announcement to me sounds like Glasswalker successfully took a major hurdle and might finalize what he is working on soon.

I am still committed to support the bounty, but do we need to clarify that the winner can't be Enterpoint or someone already being paid for his work by Enterpoint? Or do you think it would be ok to pay the bounty on top of the payment as additional incentive to hurry up?

Hm, something's fishy, though. During the last cycle it went up to 9.7 to get kicked back to 8.725 - it is obviously not cycling always over the same data, but the spikes continuously reach higher limits. Will be interesting to see where it continues when Gox opens their doors again...

Anyone has a clue on what is going on right now? Either the charting tool suffers from some hick-up, the market runs crazy, or a bunch of trading bots are fighting the final fight: the bids are eaten up to ~9.30 and then plumped down to ~8.79 with the race being repeated continuously

Maybe Mt.Gox is performing some tests (trades are disabled right now), or someone placed an order to trade 1M Bitcoins and Mt.Gox is not capable to clear it in real-time.

Danke für das Interesse, habe die Karten verkauft.

Seit ich auf FPGA mine, bin ich bei GPUs nicht mehr auf dem Laufenden. Hätte gedacht, die 7990 wären mittlerweile draussen, aber offenbar sind die 7970er immer noch das höchste der Gefühle bei ATI, oder?

I also prefer requirements to be kept simple. But I had one specific thing in mind with my second part: competition for higher speed. We have two measures to achieve here, getting a fast bitstream and getting it soon. Paying only the developer that shows up first biases the development effort towards a bitstream that just passes the minimum requirement but no more. Say someone that is already working on a bitstream and delivers 750MHps begin of August, but someone else had an idea for a 900 one, but this will take him at least end of August to finalize. The second part of my proposal would allow him at least to earn the delta for some while and motivate him to finish his work even when we had already a 'winner'.

I do not like ET's approach either, but if someone succeeds to run it on CM1, I will use it. Alas, this would not qualify to get the bounty we are discussing here - fully agree that it must be a transparent bitstream that operates with any established pool without third party interaction.

Not sure if 'whatever happens last' is ok. What if Enterpoint releases a bitstream late (say: never)? I am not going to pay for that in 2013. Shouldn't it be more 'whatever happens first'?

To
1: if there are 400+ boards in the wild and anyone is willing to contribute 1BTC per board, we should reach that.
2: a) there might be NDA information that prevents open sourcing
    b) also preferring open source, but does it really help here? we have Icarus source available, but nobody is able to correct one RX/TX line swap
    c) if it goes open source, those who contributed to the bounty should get it 4 weeks before it goes public (incentive against free-riding)
3: is this realistic? this are only two weeks from now on, do you think Enterpoint had not already provided a bitstream if it was that easy?


All in all, we should reach a consensus soon and have 500-1000BTC waiting for a smart developer, which (besides theymos' offer for rewriting SMF) should be one of the largest bounties around

I am willing to support this bounty, but also agree with Entropy-uc that it does only makes sense if the folks mining with CM1 can profit from it.

Right now the greatest uncertainty factor is how 'soon' Enterpoint will provide their dedicated CM1 bitstream unleashing the full power of the board. Nobody would start working on a new bitstream when we fully make it dependent on non controllable third party events - it must be a combination of intra- and interdependent compensation.

This is how I would word my contribution to the pledge:

1) I will pay out 50 BTC to the first community member that develops and releases a bitstream for CM1 before 2012-08-31 that provides long term operation with an average hashrate of at least 760 MHps per board. The bitstream does not need to be open sourced itself, but the API must be provided along with a proof-of-concept implementation support for an established open source miner (cgminer, MPBM, etc.) and full step-by-step documentation to reproduce the correct set-up.

2) Starting from the release day of the developed bitstream and until 2012-10-30, for each day I will pay the developer a performance bonus of (B - N) / 200, where B is the bitstream's hashrate and N is the hashrate of the second best publicly available bitstream. Example: if B was 840MHps and twin_test.bit still the fastest one with 380MHps, I'd pay a daily bonus of 2.3 BTC until end of October. The bonus payments are calculated daily, i.e. from that day Enterpoint provides a bitstream operating at 760MHps, the bonus drops to 0.4BTC/day for the remaining period.


I must admit that I don't have a clue on how long it takes to develop a new bitstram from scratch (seeing that ngzhang is already months late for Lancelot raises some doubts). Also I did not put much thinking on whether the both incentives are well balanced. It is a first shot, but this is basically what I would be willing to contribute.

Thanks kano for the extended explanation. Happy that I was not too way off understanding the code

WTF! I spent so many hours analyzing the Icarus driver code and it was all already written in a Readme? Serves me right for not remembering to RTFM...


I was maybe not clear: not saying that the Icarus driver reports the wrong hashrate, only that the cgminer core has no own measure to report the rate other than what the driver is claiming to have processed. I could claim my SoundBlaster DSP can do 1THps and write a driver for it to fool people with that rate being displayed. But you can't cheat the U factor.


Thanks again for all the clarification.

From the info I collected so far, it seems that right now we are restricted to these two. User Glasswalker was the one trying to 'fix' the original Icarus bitstream to handle the swapped RX/TX lines, but he run into problems getting it stable and had to reduce the clock => that is the shipping_test.bit one. The twin_test.bit seems to be ngzhang's original one that does well with only one FPGA per pair enabled.

Many of us are trying to get EldenTyrell's TriCoreMining working on CM1, to my knowledge nobody was successful so far. You might want to watch the related thread.

Other than that I read somewhere that Glasswalker is still working on some CM1 bitstream, but is right now busy and stressed after he got hacked and robbed 12k+$.

I discussed once with Yohan and he told me that everyone who is able and willing to work on a bitstream can get all required information. Anyone

The effect was correctly explained, i.e. what cgminer reports as hashrate needs to be halved to get the correct value for the CM1 operating with the twin_test.bit bitstream, while the U factor is correct.

Alas, the root cause is not related to the timing settings that are floating around, it is more a result of how cgminer and the Icarus driver work and the fact that one FPGA of each pair is not operable. If you don't care the details, skip to the tl;dr line.

Cgminer Work Processing
To understand the numbers, it is important to understand how the work is processed between pools/bitcoind and the worker: work is fetched from pool(s) and provided to the related driver in chunks of a whole nonce ranges (2^32 hashes). The working unit (being it CPU, GPU, or FPGA) calculates the hashes and reports back valid shares and how much hashes have been processed.

Using Icarus driver for CM1
You need to know the Icarus API to understand the numbers. The API to the Icarus provides no status queries: there is no command to ask the board if it is present or how far it is in processing the nonce range. The only function supported is: you sent it work and it reports you the nonce generating a share - thats it.

As a result of this limited functionality, two workarounds are used in cgminer:

• To detect whether an Icarus is attached to a serial line, you feed it with work containing a 'golden nonce', that is known to be found very soon (say after some milliseconds) in the range. If an attached device reports what you expect, you found an Icarus, otherwise you see a warning that an unexpected nonce (or nothing) was reported.
• Being unable to query the process in the nonce range requires some timeouts, in case there is work containing zero valid shares. For that you need to know how long the Icarus is busy crunching the work package, which is easily calculated by (2^32 / hashrate). If after that time you did not hear from your board, you just give it something else to work on. If the timeout value is too long, you risk the FPGA idling around, if it is too short you are aborting nonce ranges and feeding more work than required, which impairs efficiency due to serial line communication delays.

Icarus processes the work by equally distributing it to the two FPGAs with each one generating 2^31 hashes (0-0x7fffffff and 0x80000000-0xffffffff). The Cairnsmore1 has been planned as a dual Icarus board, but for the known design mistake the second FPGA of each pair is deactivated for the original bitstream. Therefore running CM1 in Icarus mode gives you two times half the processing power - or just one Icarus equivalent.

Hashrate
The hashrate is calculated as (hashes reported by driver / elapsed time). cgminer fully relies on what the related driver reports and has no means to verify that the work has really been completed - one can easily write a driver that reports 10TH for a device. It is a tribute to the established MHps measure, but a not exactly precise and controllable one.

When a CM1 FPGA-pair is fed with work, it only operates the first half of it, but reports that the whole range was done. As a result, the reported MHps value is exactly doubled. A side effect of this fact is that twice as many getworks are required. It is possible to modify the reported hashes in a dedicated CM1 driver to correct the hashrate displayed, but given that the Icarus bitstream is only an interim solution, it is easier to add some brain-work and just halve it.

Utilization Factor U
This is the real performance factor, since it reports the average accepted shares by the pool per minute. It is what you get as income and calculated by cgminer independent of the underlying driver. For a CM1 this should be somewhere ~2.5/m per FPGA, a board should provide you 5/m.

Icarus Timings
With CM1 operating with the twin_test bitstream, there is no need to adjust the timings as the clocks are the same as with Icarus. This is only required when the clocks change (like it was for the shipping_test bitstream).


Tl;dr
When operating CM1 in Icarus mode (twin_test.bit)

• the reported hashrate must be halved and should be around 380 MHps per board
• the reported U is correct and should be somewhere around 5/min per board
• no timing parameters are required

HTH

I'm on eu.

I observed the same: the hashrate of my workers was reported as 0, while the total of all workers combined seemed correct (25-35 GH). My 24h-income dropped from 15 to 5 BTC. It might be just bad luck, but to me it looks like shares were not accounted correctly.