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

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

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

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

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.

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.

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.

Yes, that's exactly what it is.

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



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.

And your hard drive's firmware?

Well, 700 BTC may not be adequate, but it's more than getting almost nothing from commissions.

First, this isn't a compression fallacy.

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

Good read: https://bitcointalksearch.org/topic/m.1253774

Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?

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.