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

For it to work on existing hardware, the specs for the pinouts and things have to be sent to ET since they all are different. He will then modify the design to fit each hardware platform and run on it. It would probably be best to contact Enterpoint and see whether they have plans to submit their designs to ET for consideration.

well, there are definitely some interesting issues to consider.  I for one will be happily running this bitstream on 30+ enterpoint boards...  I would quite imagine making the server as secure and stable as possible would be priority one. I know I would not spend too much time flopping bitstreams on that many units. If the servers are stable I'll be there if not then no biggie, load the next best bitstream and move on with my life....


I ask again, any word on running this on Enterpoint hardware?

Fascinating background on pool performance actually.  Thanks.


That's not sarcasm.  This is sarcasm 

A short poem by EldenTyrell:

Everybody should work for free
Except for me

Sorry, couldn't help throwing in a little sarcasm ... I'd think he expects mining software to be updated for free to support this new requirement ...

I'd also add that I can't see that happening with some of them at least.
Seriously? Update the bitstream if the servers don't respond? Wow I can see all sorts of problems with that
Then deciding to switch the bitstream back ...
though I guess if enough time and effort was spent predicting and dealing with possible issues ... ...

Those who use what I'm sure anyone will agree is probably the most advanced miner (cgminer) resolve server failure easily.
They have multiple pools.

In this case you can't do that the way it works at the moment, since, the failover occurs even during normal mining (unless you tell it to not do that and lose work) since servers aren't always 100% perfect ... for anyone ... ... ...

I'm only hashing at 1.9GH/s at the moment, but of the 50k getworks on my 2 rigs (running 4.5 days) 1.5k were to the backup pools.
Shares, of course, are lower but even there, of the 179k shares, 200 of them were the backup pools (so only 0.1%)
However, my internet has been 100% stable over the past week (it usually is anyway) and the main pool has been 100% stable also.

When the stability level drops, cgminer does it's best using all the pools as much as possible (and often at the same time) to keep the devices hashing at full speed.

This is, of course, talking about a solution that is definitely not elegant but certainly does rely on being able to define a clear line between your servers working 100% and not working 100% (which I'd wonder how clear that line would be and how easy it would be to detect without losing a lot of work)

When you submit free patches to all the major mining software packages to support automatic failover to backup bitstreams I will agree with you.

As of today, such a bitstream change would have to be manually handled.  The time to detect the failure and changeover could easily cause miners to lose money in comparison to not using your system at all.  So incentives are not aligned.  Your customers can lose money.  You only risk not collecting commissions.

awesome updates, m8. Has anyone submitted the neccesary enterpoint info and/or sent you a unit to test your bitstream on theirs?

If not, any plans to work on an enterpoint stream?

Update: I am (still) dotting I's an crossing T's.  But getting very close.

The first bitstream posted will be for ztex boards using a jtag cable (not the Cypress USB thing).  Any jtag cable supported by urjtag will work.  It will also be only a 230MH/s design: if I set the clock period to 155mhz I can actually get the builds to finish in a reasonable amount of time, so that's what I've been doing for the last day or two.  I'll set the commission to 0.01% to compensate.

(Edit, 17-Jun, jtag cable will not be required for ztex boards)

This concern is valid.  The ztek boards do not supply enough power. This is why I have been encouraging designers to budget for more than 8A.




This is misleading; you are fretting about device damage but basing your calculations on the error-free-operation parameters instead of the device-damage parameters.

Xilinx guarantees their chips can tolerate operating junction temperatures up to 125°C (see page 2 of DS162) without damage, for all temperature grades (they're manufactured identically, then sorted by testing).  Using your thermal constants, this means that a CSG484 can handle 26A of current (!) and an FGG484 can handle 20A of current without being damaged (though, of course, the error rate will be 100%).  Anyways, that's plenty of current, even for bitfury.

For each temperature grade Xilinx publishes another, lower, limit above which they will not guarantee perfectly error-free operation (85°C for the C-grade devices).  People using FPGAs for bitcoin mining are already far beyond the "guaranteed perfectly error-free" region on other axes like clock frequency.

According to Austin Lessea (of comp.arch.fpga fame; a Principal Engineer at Xilinx) "the device is incredibly robust as far as junction temperature is concerned, and it would have to be at 125C and hotter for a long period to cause damage."



The 8A power supply on your board will go into overcurrent or thermal shutdown long before the FPGA is able to damage itself by self-heating.

To avert any possible FUD I'll put my money where my mouth is: 100 BTC bounty to anybody who sends me source code for a bitstream that causes permanent heat damage to my ztek board, with heatsink installed and fan running.  No unusual I/O pin usage allowed, and the design has to pass Xilinx DRC.  If you think there's a risk step right up and claim the bounty!

Edit: created a separate thread for the bounty.

I'm not sure I follow here, but each of the three rings is completely independent of the other two.  That's why I'm able to give each one its own separately-adjustible clock.  They don't talk to each other at all.  Each one gets its own piece of work.

Busted!

No.  If my server is down you don't hash with the TML.  You go back to your old bitstream.  You lose a small amount of income and I lose all of my income.  Sounds to me like my incentives are pretty well-aligned.

This is correct.

One reason I used TCP was compatibility with Tor.  You can't do UDP over Tor (except DNS which is a special case).

You might find that a bit difficult to do without the private key.

What makes you think I meant (only) you? (and only this thread?)

Some people accused him of greed, some said that the community should (must) get it for free because bitcoin is "free".
Some even think that they know better ways to protect his IP or compensate him for his work.
Seriously, you can't expect something for free that you use to make (more) money with.

And finally - actually it's free (or will be) - the only catch is the 20% that he collects from the additional performance...
There is no payment upfront needed - everyone can simply try it - and in case they are not satisfied switch back to their regular bitstream. Nobody is forced to use Elden's bitstream. Don't like it? Don't use it!
(I am positive that there will be an alternative sooner or later)

I was watching Elden's work from the very start and was very curious to see what he is going to do regarding protection / compensating himself for his work. And the concept he brought up is (from my point of view) very fair. Life is full of risks, if the power grid or the network connection is down for 12h - who will compensate you for your mining loss ? the electric company / the provider ?

Bitcoin mining seems to be the new gold rush. It's a capitalistic system which rewards early adopters which are willing to risk time, money and effort. (Sounds pretty much like most "businesses"...)

I admire people that create or work on open source software or hardware and make it available to the public.
But it's important to see also the other guys with commercial interests that bring things forward, create competition and innovations.

Anyway - only my point of view, if anyone feels offended - she/he shouldn't.

Phil

I really wonder what it is you perceive as being harsh criticism.

Mining on CPU or GPU was a hobby activity.  I've got this gear for other purposes, so why not harvest a few bitcoins as well?

Buying purpose built FPGAs is a business.  What I posted was my analysis of the business proposition ET made.  It's a non-starter for me for the reasons I shared.  I posted in the hope of learning where my analysis was incorrect, or possibly influencing ET to choose a compensation model that I could participate in.  So far, no luck on either, but it appears that he hasn't read, or digested my feedback yet, so I will hold back on my input on what might make a workable model.

I also wonder what was so vexing to you that it lead to your only substantial post ever on this board.

Not particularly since it is BFL involved in the question but you never know until you ask, who knows they just might break past habits for once...

Did you expect a clear answer?

Where have you developed this fpga?
Maybe Logisim?
Also, are you willing to share the scheme of the fpga design?

On the watts or mh/s?