Bitcoin Forum
December 03, 2016, 09:41:15 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 »
  Print  
Author Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards  (Read 109471 times)
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
October 20, 2012, 02:04:05 AM
 #841

TML v1.13 has been released.

The only significant change is that I have included ChrisP's partial implementation of support for the Enterpoint proprietary USB interface.  If anybody can get this working beyond the "JTAG-stuck-at-1" point, I will resume trying to figure out the clocking issues.  But at the moment I can't even get it to talk to the FPGA, so we're still in "dealing with vendors' proprietary interfaces" land where most of you guys are far more skilled than I am.


19.Oct.2012  Release v1.13
             fix division-by-zero bug reported by TheSeven
             Add various difficulty-manipulation utilities in com.triconemining.bitcoin.work.Difficulty
             Add libFtdiNative for amd64
             Add ChrisP's code for Enterpoint proprietary USB (not working right now)

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
1480758075
Hero Member
*
Offline Offline

Posts: 1480758075

View Profile Personal Message (Offline)

Ignore
1480758075
Reply with quote  #2

1480758075
Report to moderator
1480758075
Hero Member
*
Offline Offline

Posts: 1480758075

View Profile Personal Message (Offline)

Ignore
1480758075
Reply with quote  #2

1480758075
Report to moderator
1480758075
Hero Member
*
Offline Offline

Posts: 1480758075

View Profile Personal Message (Offline)

Ignore
1480758075
Reply with quote  #2

1480758075
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
max in montreal
Hero Member
*****
Offline Offline

Activity: 504


View Profile
November 06, 2012, 04:20:09 AM
 #842

anybody ever get this to work on an x6500?
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
November 10, 2012, 10:36:14 AM
 #843

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
November 15, 2012, 09:26:46 AM
 #844

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

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
November 17, 2012, 08:07:07 AM
 #845

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
Hero Member
*****
Offline Offline

Activity: 714


Psi laju, karavani prolaze.


View Profile
November 17, 2012, 09:46:22 AM
 #846

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

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

rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
November 17, 2012, 01:35:36 PM
 #847

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

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
mining4fun11
Member
**
Offline Offline

Activity: 110


View Profile
November 19, 2012, 06:50:07 PM
 #848

Does anyone know how to get this to work on a modminer. 
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
November 20, 2012, 09:11:31 AM
 #849

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!

kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 20, 2012, 09:40:11 AM
 #850

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
November 20, 2012, 10:17:55 AM
 #851

will it melt my ztex 1.15x cluster?

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


The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
November 20, 2012, 10:56:06 AM
 #852

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
mining4fun11
Member
**
Offline Offline

Activity: 110


View Profile
November 20, 2012, 01:53:41 PM
 #853

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
Member
**
Offline Offline

Activity: 109


View Profile
November 21, 2012, 06:38:19 PM
 #854

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
**
Offline Offline

Activity: 110


View Profile
November 22, 2012, 03:53:06 AM
 #855

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
**
Offline Offline

Activity: 109


View Profile
November 22, 2012, 12:18:25 PM
 #856

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
mining4fun11
Member
**
Offline Offline

Activity: 110


View Profile
November 22, 2012, 03:33:15 PM
 #857

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.
rb2k
Member
**
Offline Offline

Activity: 109


View Profile
November 22, 2012, 04:05:49 PM
 #858

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
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
November 22, 2012, 10:57:13 PM
 #859

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

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
November 22, 2012, 10:58:15 PM
 #860

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!