Pages:
Author

Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 23. (Read 119444 times)

hero member
Activity: 560
Merit: 500
Let me guess.. next bitstream will be called fraenkel? Smiley
hero member
Activity: 560
Merit: 500
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:[email protected]

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
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Interestingly I'm getting better results with 0.95. Setting same clocks on 0.99 gets me loads of errors.

Please try running the 0.999 software with the 0.95 bitstream (named "church").  You can do this by changing the command line to:


java -Dtriconemining.bitstream=church -jar tml-0.999.jar

donator
Activity: 980
Merit: 1004
felonious vagrancy, personified

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!
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
hero member
Activity: 560
Merit: 500
Interestingly I'm getting better results with 0.95. Setting same clocks on 0.99 gets me loads of errors.
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
davis, 1.32V, 30°C ambient,

H:152/38,62,52 X:240 C:168,148,164 E:0/0,0,0 T:15m   |  H:178/55,64,61 E:7/6,8,7 A:179 R:0 T:1h11m37s

10mh more than ztex at same conditions.
sr. member
Activity: 397
Merit: 500
...  Again, support for these boards is via urjtag only.  

Can you please provide us with a already patched urjtag windows binary? I don't have a clue how to patch a binary file and compile the whole thing with all required libs and such.

Thank you!

greets,
eb


Nevermind... Got it now after some hours...

But thanks for help  Undecided
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
TML 0.99 is posted.

We have (finally) emerged from BUFGMUX-placement-hell and are able to generate bitstreams again.

Starting with this release the bitstreams have names, issued alphabetically.  There is also a new bitstream, "davis", which in theory supports the following boards via JTAG cable: x6500, nexus6, modminer, icarus, carinsmore.  If you can confirm that any of these work, please let us know.  Again, support for these boards is via urjtag only.  If you want support for board-proprietary USB interfaces, ask your board manufacturer, not us.

Lots of new software features:

Code:
04.Jul.2012  Release v0.99, new bitstream "davis"
04.Jul.2012  Release v0.98, no new bitstream
  named bitstreams
  detect clock pin automatically
  simplify clock calibration algorithm
  add support for statistics plots
  clock on pin J1  (icarus, carinsmore)
  clock on pin K20 (x6500, modminer, nexus)
  add ability to measure clock rate at the pin
  DCM: use closest-match frequency
  include usb_strerror() in error messages

The automatic clock frequency setting code in this release is much, much simpler and should be more reliable.

and pretty graphs:



Also, bitstream davis passes Xilinx timing at 185mhz on all three rings.  This means that getting 277MH/s/chip is "simply" a matter of having a power supply that can deliver enough current without sagging.  In the plot above you can observe the phenomenon bitfury describes, where logic in the center of the device is the first to fail due to inadequate power delivery.

This is the first bitstream that works on both the commercial boards (ztex, etc) and my own nexus6 boards (not for sale, don't ask).  So now I can finally start converting my mine over to the same code I'm asking other people to run.  Once I've finished that I'll feel confident declaring this "ready for production use".

donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Status update:

0.95 was running like a dream overnight finally converging to 240Mh/s on eligius. Unfortunately when I woke up I found this:

Code:
[ztex:0:1  ] loading job  67dd99a96f74bda852f43c5e1a87a7dc8e18fae0b2276395274639a5b186798f:94f47e834ff26a021a09b78a
H:286/214,71,0 X:240 C:170,150,160 E:0/0,0,0 T:1m   |  H:234/81,73,79 E:0/0,0,0 A:1568 R:12 T:8h2m13s Exception in thread "Thread-2" java.lang.RuntimeException: java.io.EOFException
        at com.triconemining.limp.LimpConnection.run(LimpConnection.java:53)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.EOFException
        at com.triconemining.util.VarInt.read(VarInt.java:16)
        at com.triconemining.limp.LimpConnection.run(LimpConnection.java:50)
        ... 1 more
[ztex:0:2  ] signcrypting 67dd99a96f74bda852f43c5e1a87a7dc8e18fae0b2276395274639a5b186798f:94f47e834ff26a031a09b78a


Yes, that is THE major reason why the TML is currently "not for production use".  I still need to do a walk through all the code to make sure it doesn't get "stuck" when something goes wrong.  There's actually a warning about this in the banner that prints out when you first run the TML:

Code:

   Here is a partial list of issues you should be aware of:
     - many kinds of errors (network, etc) cause the miner to get stuck
...
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
I'm going to point out the obvious here since, for some unknown reason, you and Enterpoint haven't joined forces yet.

Nonsense, they have the board development kit.  I'm still waiting for them to send me the driver code.  Bug them, not me.

a truce for whatever BS you all have a beef over.

This just makes no sense at all.
hero member
Activity: 910
Merit: 1000
Items flashing here available at btctrinkets.com
enterpoint has sold over a 100 boards (without a decent bitstream)

How did that happen?!?
I'm going to point out the obvious here since, for some unknown reason, you and Enterpoint haven't joined forces yet.  Enterpoint is a professional FPGA hardware solution provider.  You are a brilliant bitstream developer.  Together you could drive sales through the roof and give BFL some real competition.  The fact you haven't done so and instead are wasting your time with Ztex boards is extremely frustrating to myself and many others in the Enterpoint camp.

Get your shit together with Enterpoint and find a truce for whatever BS you all have a beef over.
+1 and it's over 150 boards, highest number I have is 159.
hero member
Activity: 560
Merit: 500
Stock volts. Need I say more?

hero member
Activity: 1596
Merit: 502
The quad board is not their only product.
They have a wide variety of fpga products, so it can be possible the day the delivery guy was outweighed they had another big delivery.
But I do belive they've sold much of them already.
hero member
Activity: 896
Merit: 1000
enterpoint has sold over a 100 boards (without a decent bitstream)

How did that happen?!?

Because their prices are the lowest by far: $640 for a quad LX150 board. Compare this to Ztex's $920 (qty 50+), or btcfpga's $1070...
I believe they are more likely near 500 boards in the field than 100. I have 2 myself and some people are known to have around 10 and more to come. According to the dedicated thread they are sending boards each working day and they reached a point weeks ago where the delivery guy was literally outweighed by the packages to send (the 2 boards I received where in a package that didn't weigh more than 3 kg, probably 2).

They were by far the most efficient from early design to board at doorstep (the fact that FPGA solutions are their core business shows), the price is good and the potential for 1GH/s is there. I'd be surprised if they don't reach the 1000 boards installed this summer. Their pre-order book is full until September, they only need to send 20 boards per day 5 days a week which would match the "delivery guy weight" easily.
hero member
Activity: 560
Merit: 500
Status update:

0.95 was running like a dream overnight finally converging to 240Mh/s on eligius. Unfortunately when I woke up I found this:

Code:
[ztex:0:1  ] loading job  67dd99a96f74bda852f43c5e1a87a7dc8e18fae0b2276395274639a5b186798f:94f47e834ff26a021a09b78a
H:286/214,71,0 X:240 C:170,150,160 E:0/0,0,0 T:1m   |  H:234/81,73,79 E:0/0,0,0 A:1568 R:12 T:8h2m13s Exception in thread "Thread-2" java.lang.RuntimeException: java.io.EOFException
        at com.triconemining.limp.LimpConnection.run(LimpConnection.java:53)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.EOFException
        at com.triconemining.util.VarInt.read(VarInt.java:16)
        at com.triconemining.limp.LimpConnection.run(LimpConnection.java:50)
        ... 1 more
[ztex:0:2  ] signcrypting 67dd99a96f74bda852f43c5e1a87a7dc8e18fae0b2276395274639a5b186798f:94f47e834ff26a031a09b78a

I'm gonna tweak my clocks up a notch to 245 total and let it run again. I'm quite happy with this performance and the fact no mods were required (apart from extra cooling). Although I'm tempted to try how far it can go with volt mod Smiley
hero member
Activity: 556
Merit: 500
enterpoint has sold over a 100 boards (without a decent bitstream)

How did that happen?!?
I'm going to point out the obvious here since, for some unknown reason, you and Enterpoint haven't joined forces yet.  Enterpoint is a professional FPGA hardware solution provider.  You are a brilliant bitstream developer.  Together you could drive sales through the roof and give BFL some real competition.  The fact you haven't done so and instead are wasting your time with Ztex boards is extremely frustrating to myself and many others in the Enterpoint camp.

Get your shit together with Enterpoint and find a truce for whatever BS you all have a beef over.

Lol, I know how you feel. I have a board (23 more coming) with so much potential only doing a measily 380 mh/s. With a tricone bitstream it could possibly push up to 1 gh/s. The only thing though is enterpoint still has work to do on the controller firmware to keep the chips stable and that has nothing to do with eldentryell. Also he has requested the specs he needs to make his bitstream work and yohan has emailed him the information. You're probably better off bitching in the enterpoint thread about the firmware development progress.
mrb
legendary
Activity: 1512
Merit: 1028
enterpoint has sold over a 100 boards (without a decent bitstream)

How did that happen?!?

Because their prices are the lowest by far: $640 for a quad LX150 board. Compare this to Ztex's $920 (qty 50+), or btcfpga's $1070...
rph
full member
Activity: 176
Merit: 100
230MH/s, 0% errors, 21.17MH/J

Sweet! That's at ~1.26V, so only around 8.5A (long term average) on the core supply?

-rph
hero member
Activity: 560
Merit: 500
It's been running almost 6 hours now, and it's not getting the performance I was getting with .92b:

H:143/71,0,71 X:231 C:162,140,160 E:0/0,0,0 T:1m   |  H:178/60,59,58 E:18/22,11,20 A:777 R:14 T:5h17m3s  

With eligius reporting 3h avg. of just ~180Mh/s. Lot's of invalids: [ztex:0:2  ]   invalid nonce: 0x8b170ab6

It's probably the clock calibration code.

What kind of results do you get when you set the frequencies manually and disable clock calibration with

  java -Dtriconemining.recalibrate_clock=false -jar tml.jar ztex:0


I've been running 0.95 for about an hour now as you instructed, with clocks set at 170, 150, 160 (~240Mhash) Looking good so far, no errors. Me likey!
Pages:
Jump to: