Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[punin]

Heads up: there is a really stupid mistake in the host software that is causing it to simply lose up to 20% of the nonces.  The higher the hashrate, the more it loses both because work is loaded more often and because each second of time spans a greater part of the nonce-space.

I wanted to go directly from 0.99 to 1.0 but this is too important.  I will post a fix ASAP.

Fired it up with command:
java -Xbootclasspath/a:ZtexBTCMiner-120221.jar -jar tml-0.999.jar ztex:0 http://mywallet:foo@mining.eligius.st

Result:
[ztex:0:1  ] decrypting nonce at address 0x000000b8                                              
[ztex:0:1  ]   encrypted nonce = 0x7e27cb87                                                      
[ztex:0:1  ]   invalid nonce: 0x6986b80e                                                          
[ztex:0:1  ] signcrypting ee52b1778658629c131a2fa600e293dd8f7b2eb34a16cfea39947b2f38770e03:a39a33904ff68ce71a099431
[ztex:0:1  ] loading job  ee52b1778658629c131a2fa600e293dd8f7b2eb34a16cfea39947b2f38770e03:a39a33904ff68ce71a099431
[ztex:0:2  ] signcrypting ee52b1778658629c131a2fa600e293dd8f7b2eb34a16cfea39947b2f38770e03:a39a33904ff68ce81a099431
[ztex:0:2  ] loading job  ee52b1778658629c131a2fa600e293dd8f7b2eb34a16cfea39947b2f38770e03:a39a33904ff68ce81a099431
[ztex:0:0  ] decrypting nonce at address 0x0000005c                                                
[ztex:0:0  ]   encrypted nonce = 0xf95536c8                                                        
[ztex:0:0  ]   invalid nonce: 0x30f95961                                                          
[ztex:0:0  ] signcrypting ee52b1778658629c131a2fa600e293dd8f7b2eb34a16cfea39947b2f38770e03:a39a33904ff68ce91a099431

H:0/0,0,0 X:223 C:152,136,157 E:100/100,100,0 T:15m   |  H:0/0,0,0 E:100/100,100,0 A:0 R:0 T:1m19s


EDIT: Tried using church (0.95) bitstream with tml-0.999.jar . Seems to be working, I'll leave it running to see the performance.

EDIT2: Best results so far by running with recalibrate_clock=false and setting clocks manually to 172,164,164 giving me X of whopping 250 on a standard ztex board

[1713897779]

1713897779

[1713897779]

1713897779

[1713897779]

1713897779

[1713897779]

1713897779

[punin]

Let me guess.. next bitstream will be called fraenkel?

[chrisp]

TML-0.999 is posted.

Please upgrade if you care about performance; all previous versions have a serious performance bug that causes valid shares to silently be "lost".  The number of shares-per-second lost scales non-linearly with clock rate which is why I didn't notice it before.  Please do not report performance numbers using anything earlier than 0.999; those numbers will be skewed low.  The bug manifests itself as the hashrate (H: number) being much lower than the expected hashrate (X: number) even when the error percentage is zero -- that should never happen!

Attempted the new bitstream and java jar on enterpoint.  Able to program the bitstream, however, clock detection fails.  It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection.  K20 doesn't seem to be an issue and reliably detects 0.  Then when detecting the J1 pin should it get that far, the results are quite unreliable.

Chris

[eldentyrell]

Let me guess.. next bitstream will be called fraenkel?

Yes, but only because I couldn't find a name that starts with "E".

[eldentyrell]

Attempted the new bitstream and java jar on enterpoint.  Able to program the bitstream, however, clock detection fails.  It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection.  K20 doesn't seem to be an issue and reliably detects 0.  Then when detecting the J1 pin should it get that far, the results are quite unreliable.

Chris, you'll need to be more specific than that.  Please post a log file for each of these behaviors.

[chrisp]

Attempted the new bitstream and java jar on enterpoint.  Able to program the bitstream, however, clock detection fails.  It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection.  K20 doesn't seem to be an issue and reliably detects 0.  Then when detecting the J1 pin should it get that far, the results are quite unreliable.

Chris, you'll need to be more specific than that.  Please post a log file for each of these behaviors.

Both runs completed back to back.  Input clock should be 50 mhz on cairnsmore pin.

http://s15.postimage.org/cni27ojaz/Capture.png

http://s10.postimage.org/44qjz8rs9/Capture2.png

[eldentyrell]

Attempted the new bitstream and java jar on enterpoint.  Able to program the bitstream, however, clock detection fails.  It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection.  K20 doesn't seem to be an issue and reliably detects 0.  Then when detecting the J1 pin should it get that far, the results are quite unreliable.

Chris, you'll need to be more specific than that.  Please post a log file for each of these behaviors.

Both runs completed back to back.  Input clock should be 50 mhz on cairnsmore pin.

Chris, a few things:

1. Please post (a link to) the logs, not a screenshot of the logs.

2. Please don't use -Dtriconemining.avoid_reprogramming=true unless you're 100% sure you know it won't cause problems.  In this case that option is preventing the chip from being reset between runs, which is causing at least part of your clock-pin-detection problems.

3. The logs you posted are incomplete; it seems like you either truncated them or killed the software after the first "ramping clock" line -- please let it keep running until you get an error and/or things work (or get stuck).

[punin]

Let me guess.. next bitstream will be called fraenkel?

Yes, but only because I couldn't find a name that starts with "E".

How about eilenberg or euler?

[punin]

My plots church vs davis:

http://pastebin.com/td4u9FBw
http://pastebin.com/Z47eHfXy

[kakobrekla]

I spent over one whole day fiddling with this and I am kind of giving up for now,... I can't replicate any of these results, yet they were real.
I saw

Code:

H:181/34,78,92 X:256 C:168,172,172 E:9/22,0,11 T:15m | H:181/34,78,92 E:9/22,0,11 A:34 R:3 T:14m31s

with my own eyes. And upon it, i ran

Code:

H:138/38,23,84 X:254 C:165,172,172 E:14/0,50,0 T:15m | H:124/35,23,84 E:14/0,50,0 A:29 R:0 T:16m19s

with fixed clocks. Ring 1 was still a bit too hot apparently, but after that I didn't get any good runs. Maybe one.


davis, 1.313v, 30m


davis, 1.35v, 15m


Right now one in 5 or 10 runs starts with returning valid results and they mostly end up like this:
(1.307v: 10m, 12m, 15m, 22m)




-Dtriconemining.recalibrate_clock=false and/or -Dtriconemining.allow_local_reset=true didn't seem to help.

EDIT: After running ztex over night, board seems to respond to TML again. At least the first try... we'll see.
Got again just one short run out of that.

[BCbitcoin]

Let me guess.. next bitstream will be called fraenkel?

Yes, but only because I couldn't find a name that starts with "E".

How about eilenberg or euler?

Or Elden?

[wildemagic]

Elden, im getting some better cooling for my icarus next week so ill give your bitstream a shot on one of them once im setup.

Am I reading it right that I have to run your bitstream while attached to my jtag setup?

kind regards

[eldentyrell]

Am I reading it right that I have to run your bitstream while attached to my jtag setup?

I'm not sure I understand the question… but if you have any board other than the ztex 1.15x then you must use a JTAG cable.  Did that answer it?

[eldentyrell]

How about eilenberg

Ah, how could I forget!  For some reason Wikipedia left him off the list.  I ought to use my bookshelf instead of their page.

or euler?

Eminent, but not eligible.

[wildemagic]

I'm not sure I understand the question… but if you have any board other than the ztex 1.15x then you must use a JTAG cable.  Did that answer it?

I think I already answered my question when I posed it, but yes, you confirmed it.  I must have the jtag cable to use your bitstream.

At the moment, just bumping my icarus boards up from 190 to 200mhz makes them have heating issues.  1 has a 40mm fan and the other 3 have 50mm fans, ill be getting 4x120mm and making a flow through enclosure for them next week.  That should enable me to test out your bitstream too.

kind regards

[BR0KK]

Hm i want to try this but i dont know if my Cooling of The Singles is Good enough..... Im using the stock heat sink (xilence) and no cooler on the underside of the board.


I do have the heat pads provided with the cooler and some not so cheap but 5mm thick (phobya, really expensive leftovers of my oc trials ) ones.

I think the stock pad is to thin but the phobya one are to thick ....

Witch one did u use (I recall that u used some under your cooler?)

[Isokivi]

Quoting from the Cairnsmore thread:
quote author=yohan link=topic=78239.msg1017131#msg1017131 date=1341773836]
An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.

We will do some more testing and work on the controller this week and there may be further updates.

Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.
[/quote]

I have no clue if this may or may not be usefull for you Eldentyrell, but taking a look in hopes of getting some actual RoI on my investment in these boards would be greatly appreciated.

[eldentyrell]

I have no clue if this may or may not be usefull for you Eldentyrell

Neither do I!  But if they or one of their users submit a driver for their proprietary USB interface (i.e. a Java class implementing either JtagRawWires or else MiningChip -- whichever is easier; if they use an FTDI chip like I do they're welcome to cut-and-paste from the nexus6 implementation) I will certainly include it.  Until then carinsmore is supported via JTAG like all other boards.

[eldentyrell]

Just a heads up, I have finally managed to convert my entire mine over to the same code that I'm distributing from tricone-mining.com.  This took about a week longer than I expected, but the process forced me to fix a lot of software bugs that would have been pretty embarrassing.  If it keeps running smoothly for another day or two I will post the latest stuff and declare it production-ready.  I'll also be updating the thread topic with the latest performance numbers after a bit more tuning.

[wildemagic]

Elden, is there enough info on the icarus through the wiki http://en.qi-hardware.com/wiki/Icarus for usb support?
I only have 1 jtag cable and therefor can only support 1 of my 4 devices that way.

kind regards