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

[eldentyrell]

TML 1.50 has been released.

This release includes a new bitstream, maclane, which has no nonce limit.

The free-as-in-beer (no commission) pre-maclane bitstreams expire 60 days after they are released.  The expiration is hardwired into the bitstream: the hasher will deliberately corrupt any job with an "ntime" more than 60 days after the publish date of the bitstream.  It is not implemented in the signcryption servers and cannot be "undone" on the signcryption servers.  This was deliberate.

The maclane bitstream does not have an ntime limit.  Future bitstreams will not have ntime limits.

[1714509401]

1714509401

[1714509401]

1714509401

[1714509401]

1714509401

[1714509401]

1714509401

[1714509401]

1714509401

[rupy]

When will i be able to use that on my Ztex Cluster ?

I'm not sure whether it is reasonable to use the tricone bitstream on ZTEX FPGA board. Here here my considerations.

1. I made some more exact current measurements with the ZTEX bitstream. At 212 MHz the core current is approximately 6.7 A, i.e. the frequency limit with this bitstream is about 250 MHz on ZTEX FPGA boards (with 8A core voltage regulator).

2. According to eldentyrrel the tricone bitstream is about 13% less efficient. This bitstream  would have to be limited to 217 MH/s on the ZTEX FPGA boards.

3. At 12V input voltage it is probably possible to override the max. current of AOZ1025DI by 0.5A   (this would require some long term tests at 9.5A). But IMHO its not worth it: At 8.5A the tricone bitstream should deliver about 233 MH/s. The price for additional 17 MH/s (21*0.8, 20% goes to eldentyrrel) is  approx. 2.5W more power on the wall and a reduced reliability.

4. I'm concerned about the reliability (due to the 2-year warranty):

4.1. At 8A the power dissipation of the FPGA is about 10W. The thin CGS484  packages have a junction-case thermal resistance of 2.2 K/W. Plus 0.3 K/W for the thermal grease this results in  junction temperature of 70.5°C, if the bottom of the heat sink is 45°C warm. This should be still o.k. but there is not much margin for improper installed heat sinks or so. And  many users had problems with this because the plastic packages are not very flat.

For comparison: The thermal resistance of the thick FGG484 packages which are used for most other LX150 FPGA boards is 3.7 K/W. Plus 0.3 K/w for the thermal grease
leads to a junction temperature of 85°C at 8A,  96°C at 10A, and 106°C at 12A

4.2. There is no on-die temperature sensor. If the heat sink is not installed perfectly the core temperature reaches critical levels and there is no chance to recognize this. The indirect overheat protection by error measurement (as implemented in BTCMiner) does not work if the frequency is limited.

I'm sorry but due to the 2 year warranty and from my experience its seems to be too critical for me to support the eldentyrrel bitstream actively. (Of course, everyone can do this on ones own risk.)

Ok, so where are we on this. Can I use this for free now and will it melt my ztex 1.15x cluster?

And will the PS from ztex be sufficient for 5 X 1.15x: http://shop.ztex.de/product_info.php?products_id=71

I'm not concerned with heat as I have cold air from outside blowing on big heatsinks...

[BR0KK]

Currently its for free but some day he will switch on the system so that he makes some money with it.

Running that Bitsream is not a good idea..... As You can read in the Quote the Boards of Ztex do not have enough Amps to run it properly!
Also it could damage your boards permanently (Heat)

[kakobrekla]

Running that Bitsream is not a good idea.....

Dunno, my current 24/7 setup is TML at 1.42V with 260mhash+.

[rupy]

but did you voltmod all your chips? what would the MH/s be if you run it without voltmod?

[mining4fun11]

Does anyone know how to get this to work on a modminer. 

[BR0KK]

Running that Bitsream is not a good idea.....

Dunno, my current 24/7 setup is TML at 1.42V with 260mhash+.

He did and thats voiding warranties I wouldn't do it if you depend on that!

[kano]

Does anyone know how to get this to work on a modminer. 

Depending on how old your MMQ is - you may need to put in a TML firmware:
http://wiki.btcfpga.com/index.php?title=Firmware

[eldentyrell]

will it melt my ztex 1.15x cluster?

If this were anything other than pure FUD, someone would have claimed the bounty by now.

[eldentyrell]

I've posted 1.50a; this changes only the software (no new bitstream) and has three main features:

  1. Fixes a rare but serious bug that can cause a lot of stales
  2. Maintains a single pool of signcrypted work (which means work loads faster, which means fewer stales)
  3. Eliminates "false negatives" when detecting errors, which helps the clock converge faster

I've marked this as 1.50a instead of 1.51 since it hasn't received the amount of testing I normally do before a release, but the garbage collection bug was important enough that I wanted to get this out there.  I am running 1.50a on my own cluster.

  http://www.tricone-mining.com/tml/tml-1.50a.jar

. . . . . . . . . . . . . . . . . . . . . . . . .
Details:

1. Google MapMaker is a nifty library, and the fact that you can make it act like a WeakHashMap simply by calling weakKeys() is really neat.  Except that's not how it works.  The semantics for Google MapMaker aren't the same as the semantics for WeakHashMap.  In fairness to the people who wrote it this is in the documentation, but it's subtle and dangerous enough that I would have put it in big red bold <blink> text: when you call weakKeys() on a map, it changes its semantics from using .equal()-based equality (like WeakHashMap) to using pointer equality.  Unfortunately if you're using the map to do interning this is exactly what you don't want.

So the bottom line is that due to MapMaker not working the way I thought it did, under certain circumstances the TML can wind up with multiple heap objects for the same BlockID floating around.  This meant that when a new block was detected (usually due to long poll), only the WorkJobs associated with one of these BlockID objects would get revoked.  What made this so hard to track down is that whether or not it happens is totally nondeterministic, based on the vagaries of garbage collection.  On the machine that runs my cluster I've never been able to get it to happen; I guess it just has "lucky" heap settings.

2. Maclane and all subsequent bitstreams still encrypt nonces the way earlier bitstreams did using a two-way handshake, but the signcryption of the work no longer involves a two-way handshake; this means that in a large cluster any signcrypted job can be loaded onto any ring -- it is no longer necessary to maintain separate pools of signcrypted jobs for each ring of each chip.  The 1.50 software does not take advantage of this; in 1.50a there's one big pool of signcrypted work.

3. Prior to 1.50a the software simply flipped a "flag" saying "I recently loaded new work; ignore any errors since they might be the result of partially-loaded work".  This flag would stay set for quite a long time (sometimes up to 3-4 seconds) leading the software to disregard a lot of errors.  Starting with 1.50a the "output pointer" is checked immediately before starting to load new work and immediately after loading the last word of the new work, so the time window during which false negatives might occur is now extremely small -- basically however long it takes to do one read operation.

[mining4fun11]

Does anyone know how to get this to work on a modminer. 

Depending on how old your MMQ is - you may need to put in a TML firmware:
http://wiki.btcfpga.com/index.php?title=Firmware

I have the updated firmware but not the new mmq jar file.  I tried using the new jar file and it doesn't show any mmq support or am I doing something wrong?

[rb2k]

Ok, I spent a little bit of time and got 1.50 to recognize the board: http://blog.marc-seeger.de/tml-1.50-mmq.jar

If you feel this helped and you want to donate some bitcoinage in my direction: 1Lf7nLUbRxqjsV1GmkpDx46MTDAPMeffBf
Thanks!

p.s. I have no idea how copyright works for this. Seeing as it was well known that the modded version was available for download, I assume this is ok?
I sent an email to @eldentyrell. If this is not ok I'll take it down

[mining4fun11]

Ok, I spent a little bit of time and got 1.50 to recognize the board: http://blog.marc-seeger.de/tml-1.50-mmq.jar

If you feel this helped and you want to donate some bitcoinage in my direction: 1Lf7nLUbRxqjsV1GmkpDx46MTDAPMeffBf
Thanks!

p.s. I have no idea how copyright works for this. Seeing as it was well known that the modded version was available for download, I assume this is ok?
I sent an email to @eldentyrell. If this is not ok I'll take it down

Thanks.  It's working.  I will send you a tip.  Also are you able to get this to work with the x6500.

[rb2k]

And after hacking around a bit more on the Makefile, 1.50a seems to be working fine
http://blog.marc-seeger.de/tml-1.50a-mmq.jar

I tried my luck with the x6500, but it seems that there has been quite a bit of work between 1.12 and 1.50a, so it sadly isn't as straight forward as with the MMQ

[mining4fun11]

And after hacking around a bit more on the Makefile, 1.50a seems to be working fine
http://blog.marc-seeger.de/tml-1.50a-mmq.jar

I tried my luck with the x6500, but it seems that there has been quite a bit of work between 1.12 and 1.50a, so it sadly isn't as straight forward as with the MMQ

Whats the difference between the 1.50 and the 1.50a.  Thanks.

[rb2k]

A bit of sourcecode refactoring in how packages of "work" is handled.
For the x6500, the changes were somewhere in between 1.12 and 1.50a.

I think it would actually be possible to adapt the x6500 drivers  for 1.50a, but I don't have one and seeing as it would probably take hours, I don't see myself investing the time

[eldentyrell]

Whats the difference between the 1.50 and the 1.50a.  Thanks.

Described here:

  https://bitcointalk.org/index.php?topic=49971.msg1347183#msg1347183

Lots fewer stales for some users, slightly more accurate clocking for all users (maybe an extra 1-3mhz).

[eldentyrell]

p.s. I have no idea how copyright works for this. Seeing as it was well known that the modded version was available for download, I assume this is ok?
I sent an email to @eldentyrell. If this is not ok I'll take it down

It appears that part of tml-1.50-mmq.jar was written by TheSeven.  I have emailed him to try to sort out the licensing situation.  Ideally I would like to include this with tml-1.51 and later by default.

[mining4fun11]

I'm seeing about 13% rejects on my mmq.  Is this normal for this software. 

[eldentyrell]

I'm seeing about 13% rejects on my mmq.  Is this normal for this software. 

Make sure you're using 1.50a not 1.50.