Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 8.

mining4fun11

member

Activity: 110

Merit: 10

Quote from: eldentyrell on November 22, 2012, 09:49:19 PM

Quote from: mining4fun11 on November 22, 2012, 09:14:03 PM

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.

It seems to happen frequently when there is a block change.

mining4fun11

member

Activity: 110

Merit: 10

That is with 1.50a.

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: mining4fun11 on November 22, 2012, 09:14:03 PM

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.

mining4fun11

member

Activity: 110

Merit: 10

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

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: rb2k on November 21, 2012, 01:38:19 PM

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.

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: mining4fun11 on November 22, 2012, 10:33:15 AM

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

Described here:

https://bitcointalksearch.org/topic/m.1347183

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

rb2k

member

Activity: 109

Merit: 10

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

mining4fun11

member

Activity: 110

Merit: 10

Quote from: rb2k on November 22, 2012, 07:18:25 AM

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

member

Activity: 109

Merit: 10

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

member

Activity: 110

Merit: 10

Quote from: rb2k on November 21, 2012, 01:38:19 PM

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

member

Activity: 109

Merit: 10

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

member

Activity: 110

Merit: 10

Quote from: kano on November 20, 2012, 04:40:11 AM

Quote from: mining4fun11 on November 19, 2012, 01:50:07 PM

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?

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

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 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.

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: rupy on November 15, 2012, 04:26:46 AM

will it melt my ztex 1.15x cluster?

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

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: mining4fun11 on November 19, 2012, 01:50:07 PM

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

BR0KK

hero member

Activity: 784

Merit: 500

Quote from: kakobrekla on November 17, 2012, 04:46:22 AM

Quote from: BR0KK on November 17, 2012, 03:07:07 AM

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!

mining4fun11

member

Activity: 110

Merit: 10

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

rupy

hero member

Activity: 725

Merit: 503

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

kakobrekla

hero member

Activity: 714

Merit: 500

Psi laju, karavani prolaze.

Quote from: BR0KK on November 17, 2012, 03:07:07 AM

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

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

BR0KK

hero member

Activity: 784

Merit: 500

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)

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