Pages:
Author

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

hero member
Activity: 725
Merit: 503
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...
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
hero member
Activity: 504
Merit: 500
anybody ever get this to work on an x6500?
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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)
legendary
Activity: 1223
Merit: 1006
This is the double compression fallacy.  The only way this works is by my servers doing part of the hashing work, in which case… what the heck is the point?

First, this isn't a compression fallacy.

Yes, that's exactly what it is.

I'm not going to write a post explaining the double compression fallacy to you.


You have the bulk of the data already (the work)

Nonces-which-are-shares are statistically random and therefore incompressible.  Every possible 32-bit integer is equally likely to be the solution to a randomly chosen piece of work.  You're trying to claim that knowing which piece of work it solves somehow effortlessly adds information.  It doesn't.

Given a nonce-to-be-transmitted, the Shannon entropy of the additional foreknowledge of the work which it solves is exactly zero bits unless you actually do the work -- subject to the assumption that SHA-256 is a one-way hash function.  So the only way this is not double compression is if you've somehow found a way to invert SHA-256 and it isn't a one-way hash function anymore.  If you have figured this out, you shouldn't be wasting your time here on the forum -- you should be coding up that inversion function, mining 99% of the bitcoins, and rolling in piles of money.

Call me when you're rolling in piles of money.

Hmm - so since there seems to be an interesting discussion going on here - I thought I'd add into it Smiley

Firstly, yep the amount of money made from this would probably be pretty small ... but that's not my point of interest Smiley

ET is using Luke-jr's game of word play correctly saying that it is a double compression fallacy

'Compressing' 2 nonces into a single one is quite simple taking the stance of having the server do the missing work that wasn't sent back - so it isn't compressing, but rather working around losing half the data.

When you hash a block header you simply roll the nonce value from 0 to ~4billion (32 bits 2^32) and from that you know which nonce value you want - which clearly EVERYONE knows ...

So e.g. putting 2 half nonces into a full nonce, then having to regenerate the missing half of each nonce (65536 hashes x two) is really something quite simple for any CPU to do - since it is 32768 time faster for the CPU to do both, than having to work out the full nonce for one of them from scratch
As long as the server's hash rate is at worst 32768 times smaller than the network hash rate sending data to it, the servers can handle that.
So if a server can hash at 20Mh/s then it can handle 650GH/s of incoming half missing nonce data.

So ... I don't see the flaw in this concept (other than if you are totally fixated on money) and the fact that it isn't 'compression' - it's simply throwing away data that can be regenerated within an allowable short amount of time.

At least someone understands what the hell I'm talking about. Thanks. Cheesy
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
I have a partially-completed but non-working driver written by ChrisP.  If they want that code as a starting point I'll send it to them.  ChrisP has not responded to my emails for more than two weeks now, so my offer to share commissions -- which was clearly and explicitly conditional on his code working -- does not apply yet, although I hasten to add that if he reappears and finishes the job I'll be happy to reinstate it.  If we wind up with some solution that is a hybrid of his code and somebody else's I'll figure out some commission-sharing arrangement based on how much work it took to finish the job.

From what I remember the reason chrisp stopped development was because the DCM was failing to lock which is an inherent hardware flaw and the current working enterpoint bitstreams either implement another clock source or a watchdog.


Unfortunately I have not been able to get ChrisP's code working.  It finds the FTDI chip and thinks it is shifting the JTAG chain, but what comes out is all 1's.  There could be a variety of reasons for this; it's not actually shifting the chain, it's not reading the output correctly, etc.

I have only remote access to the Enterpoint board (and no, I don't want one, so please don't offer to send me one), so I can't do stuff like flip DIP switches or put a voltmeter on key signals.  It's a bit like stumbling around in the dark.

Also unfortunately, the time I'm able to devote to this comes only in small, short bursts.  It may be a few weeks before I am able to try again.  Hopefully ChrisP re-emerges before then.
newbie
Activity: 54
Merit: 0
So ... I don't see the flaw in this concept (other than if you are totally fixated on money) and the fact that it isn't 'compression' - it's simply throwing away data that can be regenerated within an allowable short amount of time.

 Grin Grin
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
This is the double compression fallacy.  The only way this works is by my servers doing part of the hashing work, in which case… what the heck is the point?

First, this isn't a compression fallacy.

Yes, that's exactly what it is.

I'm not going to write a post explaining the double compression fallacy to you.


You have the bulk of the data already (the work)

Nonces-which-are-shares are statistically random and therefore incompressible.  Every possible 32-bit integer is equally likely to be the solution to a randomly chosen piece of work.  You're trying to claim that knowing which piece of work it solves somehow effortlessly adds information.  It doesn't.

Given a nonce-to-be-transmitted, the Shannon entropy of the additional foreknowledge of the work which it solves is exactly zero bits unless you actually do the work -- subject to the assumption that SHA-256 is a one-way hash function.  So the only way this is not double compression is if you've somehow found a way to invert SHA-256 and it isn't a one-way hash function anymore.  If you have figured this out, you shouldn't be wasting your time here on the forum -- you should be coding up that inversion function, mining 99% of the bitcoins, and rolling in piles of money.

Call me when you're rolling in piles of money.

Hmm - so since there seems to be an interesting discussion going on here - I thought I'd add into it Smiley

Firstly, yep the amount of money made from this would probably be pretty small ... but that's not my point of interest Smiley

ET is using Luke-jr's game of word play correctly saying that it is a double compression fallacy

'Compressing' 2 nonces into a single one is quite simple taking the stance of having the server do the missing work that wasn't sent back - so it isn't compressing, but rather working around losing half the data.

When you hash a block header you simply roll the nonce value from 0 to ~4billion (32 bits 2^32) and from that you know which nonce value you want - which clearly EVERYONE knows ...

So e.g. putting 2 half nonces into a full nonce, then having to regenerate the missing half of each nonce (65536 hashes x two) is really something quite simple for any CPU to do - since it is 32768 time faster for the CPU to do both, than having to work out the full nonce for one of them from scratch
As long as the server's hash rate is at worst 32768 times smaller than the network hash rate sending data to it, the servers can handle that.
So if a server can hash at 20Mh/s then it can handle 650GH/s of incoming half missing nonce data.

So ... I don't see the flaw in this concept (other than if you are totally fixated on money) and the fact that it isn't 'compression' - it's simply throwing away data that can be regenerated within an allowable short amount of time.
legendary
Activity: 2128
Merit: 1073
I've found a good link that will help to understand curious people why eldentyrell is unwilling to open source his Xilinx toolchain.

First, you have to really notice the world "algorihmically placed" in the title of this thread. It means that he had developed his own tool to do placing of the primitives and uses the ISE only for routing and the following stages of bitstream generation.

Second, the source form that enters the Xilinx ISE tool chain is in his case XDL, not VHDL or Verilog. XDL is the textual version of the NCD (Native Circuit Description) format used internally by the Xilinx toolchain. Try running the "xdl" tool on any .ncd file from any other open-sourced Xilinx project to understand that this format can hardly be called human-readable.

Here is the link to a very good 8-page document explaing what is XDL and why to use it:

http://www.mn.uio.no/ifi/english/research/projects/cosrecos/publications/paper/recosoc11beckhoff.pdf

I would venture to guess that the total value of the "algorithmic placer" replacement tool for the ISE toolchain greatly exceeds the BTC sums mentioned in this thread. It is quite possible that even the documentation for it (if it exists at all) would be considered extremely valuable and could be used to redevelop the actual custom placer tool for cheaper than it took to develop it originally.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Well, 700 BTC may not be adequate, but it's more than getting almost nothing from commissions.

I am really tired of responding to this, so this is the last time.  Please see The Ultimatum Game.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
This is the double compression fallacy.  The only way this works is by my servers doing part of the hashing work, in which case… what the heck is the point?

First, this isn't a compression fallacy.

Yes, that's exactly what it is.

I'm not going to write a post explaining the double compression fallacy to you.


You have the bulk of the data already (the work)

Nonces-which-are-shares are statistically random and therefore incompressible.  Every possible 32-bit integer is equally likely to be the solution to a randomly chosen piece of work.  You're trying to claim that knowing which piece of work it solves somehow effortlessly adds information.  It doesn't.

Given a nonce-to-be-transmitted, the Shannon entropy of the additional foreknowledge of the work which it solves is exactly zero bits unless you actually do the work -- subject to the assumption that SHA-256 is a one-way hash function.  So the only way this is not double compression is if you've somehow found a way to invert SHA-256 and it isn't a one-way hash function anymore.  If you have figured this out, you shouldn't be wasting your time here on the forum -- you should be coding up that inversion function, mining 99% of the bitcoins, and rolling in piles of money.

Call me when you're rolling in piles of money.
hero member
Activity: 556
Merit: 500
In psychology the more you argue with someone the more energy they are going to put to defend their position. I believe people have put lots of energy in asking ET to release his bitstream and he has said no, he's probably not releasing it just simply because he doesn't want to change his position on open sourcing it. People are irrational beings.
newbie
Activity: 54
Merit: 0
Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?
Good read: https://bitcointalksearch.org/topic/m.1253774
Excellent!  I pay price for not reading all of thread.  I will review now.

EDIT: After review, if take 5000 eligible units and increase throughput from 210 to 255 mhash/sec, will generate almost 74btc extra per day at current difficulty.  If take all extra, exceed 700btc in less than ten days.  With real commission, inverse ratio for break-even.  19 days for 50%, 38 days for 25%, and so on.

5000 units is 1250 4-chip boards.  That is acceptable estimate.
donator
Activity: 543
Merit: 500
Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?
Good read: https://bitcointalksearch.org/topic/m.1253774
newbie
Activity: 54
Merit: 0
First, none of this has anything to do with opensourcing the bitstreams or not.  Regardless of how much hardware he has personally, this wouldn't change either way.  I fail to see how this is relevant.


or c) He feels the IP has value outside just the amount of commission he might make, and he might want to leverage it for something else.

Just because MS isn't selling Windows XP anymore doesn't mean they're going to GPL the source if you cut them a cheque for a couple thousand bucks.

That's the problem though. This particular IP's purpose is to generate profit directly.  Therefore, the IP actually doesn't have any other value outside the amount of commission he would make with it unless it is sold entirely, such as through the bounties offered.  That's the point.  The only way it would have an increased value to the creator is if it is somehow generating more profit than we're led to believe.  Regardless of how someone may feel about their IP, it's worthless if in the end there is little to nothing to show for it.

You can't compare Windows XP to this bitstream.  Windows XP was successfully sold to millions at a profit already, and XP licenses are still valid.  Windows XP has turned a profit for MS, so, they have no reason to accept a "couple thousand bucks" to open source it.  The difference here is, assuming this bitstream legitimately does what we're told as advertised and nothing more, then the creator has not profited from it and will not profit from it more than the value of the up front bounties offered to simply release it in source form.

I try one more time.

Imagine Dr. Tyrell has invented new shovel design.  It can move more dirt than every other shovel and is ergonomic so user can work all day.

If he sells Stakhanov Shovel as design for $7700, that is all he makes.

If he rents shovels for percentage of improved dirt moved, he makes x dollars minus cost of production and maintenance (signcryption services).

If he hires 500 people and gives them shovels to mine own land, he makes full profits of improved output, minus cost of production and maintenance of shovels and cost of labor and land use.

Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?
legendary
Activity: 1223
Merit: 1006
Actually, I'm pretty sure that the math on this one doesn't lie.  700 BTC > All Possible commission profit.

Then must be some reason for not releasing that has nothing to do with commission.

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.

Does not have to be illegal or shady.  Could be ASIC of his own.  If I can afford ASIC run, he can, especially if he has mined many bitcoins with improved bitstreams.  Could also have access to better FPGAs with more gates that better to suit algorithmic approach.

Think if BFL mined instead of selling.

First, none of this has anything to do with opensourcing the bitstreams or not.  Regardless of how much hardware he has personally, this wouldn't change either way.  I fail to see how this is relevant.

Second, BFL does mine on unsold hardware prior to shipping to customers, and also if they didn't sell hardware they wouldn't have the money from poor pre-order fools to make any hardware to mine with themselves.



or c) He feels the IP has value outside just the amount of commission he might make, and he might want to leverage it for something else.

Just because MS isn't selling Windows XP anymore doesn't mean they're going to GPL the source if you cut them a cheque for a couple thousand bucks.

That's the problem though. This particular IP's purpose is to generate profit directly.  Therefore, the IP actually doesn't have any other value outside the amount of commission he would make with it unless it is sold entirely, such as through the bounties offered.  That's the point.  The only way it would have an increased value to the creator is if it is somehow generating more profit than we're led to believe.  Regardless of how someone may feel about their IP, it's worthless if in the end there is little to nothing to show for it.

You can't compare Windows XP to this bitstream.  Windows XP was successfully sold to millions at a profit already, and XP licenses are still valid.  Windows XP has turned a profit for MS, so, they have no reason to accept a "couple thousand bucks" to open source it.  The difference here is, assuming this bitstream legitimately does what we're told as advertised and nothing more, then the creator has not profited from it and will not profit from it more than the value of the up front bounties offered to simply release it in source form.
legendary
Activity: 1274
Merit: 1004
Actually, I'm pretty sure that the math on this one doesn't lie.  700 BTC > All Possible commission profit.

Then must be some reason for not releasing that has nothing to do with commission.

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.
or c) He feels the IP has value outside just the amount of commission he might make, and he might want to leverage it for something else.


Just because MS isn't selling Windows XP anymore doesn't mean they're going to GPL the source if you cut them a cheque for a couple thousand bucks.
newbie
Activity: 54
Merit: 0
Actually, I'm pretty sure that the math on this one doesn't lie.  700 BTC > All Possible commission profit.

Then must be some reason for not releasing that has nothing to do with commission.

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.

Does not have to be illegal or shady.  Could be ASIC of his own.  If I can afford ASIC run, he can, especially if he has mined many bitcoins with improved bitstreams.  Could also have access to better FPGAs with more gates that better to suit algorithmic approach.

Think if BFL mined instead of selling.
legendary
Activity: 1223
Merit: 1006
Actually, I'm pretty sure that the math on this one doesn't lie.  700 BTC > All Possible commission profit.

Then must be some reason for not releasing that has nothing to do with commission.

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.
Pages:
Jump to: