Pages:
Author

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

member
Activity: 110
Merit: 10
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.
member
Activity: 110
Merit: 10
That is with 1.50a. 
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
member
Activity: 110
Merit: 10
I'm seeing about 13% rejects on my mmq.  Is this normal for this software. 
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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).
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 Smiley
member
Activity: 110
Merit: 10
And after hacking around a bit more on the Makefile, 1.50a seems to be working fine Smiley
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.
member
Activity: 109
Merit: 10
And after hacking around a bit more on the Makefile, 1.50a seems to be working fine Smiley
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
member
Activity: 110
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

Thanks.  It's working.  I will send you a tip.  Also are you able to get this to work with the x6500.
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
member
Activity: 110
Merit: 10
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?
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.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
will it melt my ztex 1.15x cluster?

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

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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
hero member
Activity: 784
Merit: 500
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 Smiley I wouldn't do it if you depend on that!
member
Activity: 110
Merit: 10
Does anyone know how to get this to work on a modminer. 
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?
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Running that Bitsream is not a good idea.....

Dunno, my current 24/7 setup is TML at 1.42V with 260mhash+.
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)
Pages:
Jump to: