stordoff
Newbie
Offline
Activity: 41
Merit: 0
|
|
June 13, 2011, 04:40:47 PM |
|
Does anyone know if code is available for the DE2 (not the DE2-115) board? I can get access to those through my university, so considering making it a summer project.
|
|
|
|
makomk
|
|
June 13, 2011, 05:14:12 PM Last edit: June 13, 2011, 09:56:57 PM by makomk |
|
Wow. Quartus II is claiming 108MHz and 78k LEs for my latest tweaks to the fully-unrolled DE2-115 code. I expect I could've hit at least 110MHz if the optimizer hadn't given up once it reached its 100MHz target. Surely this is too good to be true, especially since I haven't done anything fancy like precomputing W? Sadly I don't have a board to test this with but ModelSim seems to indicate it's not obviously broken. Anyway, it's up on github if you're feeling brave, and watch your cooling. Edit:Does anyone know if code is available for the DE2 (not the DE2-115) board? I can get access to those through my university, so considering making it a summer project.
The Cyclone II EP2C35 based one? Should be able to fit a partially-unrolled pipeline onto that in theory, though it probably wouldn't be massively fast. You'd have to port the HDL over to that board and compile a bitstream yourself, but that probably just means changing the device setting and pinout and turning down the level of loop unrolling. ( Edit 2: Apparently Fmax=110.34MHz for this design on the EP4CE115. Interesting. I think I should be able to improve on that a bit )
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
vx609e
Newbie
Offline
Activity: 29
Merit: 0
|
|
June 13, 2011, 09:49:48 PM |
|
I fully agree that ASIC is the long-term way to go, but this UART token ring thing seems to be rubbish to me. There are well-suited protocols for this, like for example I²C. There are two possibilities: - Build a PCIe mining accelerator card, with some PCIe to I²C (or whatever) bridge, possibly on a CPLD. - Slap an ARM SoC and an ethernet adapter on the board as well and make it run autonomously. Let's say each manufactured chip would yield 100 MHash/s. We daisy chain 20 per boards (a board with 20 chips on it is not a big deal) That's 2 GHash/s right there. PCB design and manufacturing would be pretty straight forward. I volunteer for that.
Good to know, as I have never dealt with this area before. Could you provide an estimate for the non-ASIC cost? (PCB design, prototyping, manufacturing and assembly, voltage regulators, clock generation, ...) Assuming a 4"x6" board 4-layer board, the PCB itself would cost about 25$ a piece in low volume (100 pieces...that's from pcbexpress.com). If there's not too much routing, we could go for a 2-layer board which would be half the price. Cut that in half if we make 1000's. Assuming there is less than 100 parts on the board, assembly of 100 boards is about 50$ per board (that's from aapcb.com). I usually assemble the first prototype(s) myself. Again, cut that in half if we make 1000's. We really need to wait how the ASIC shapes up before making wild guesses on the required additional components on the board (regulators, oscillator, interface, etc.). However, I would be really surprise if this turns out to be more than 10-20$ per board depending how "stand-alone" is the board. PCB design is free, I have all the tools.
|
|
|
|
fpgaminer (OP)
|
|
June 14, 2011, 05:19:35 AM Last edit: June 14, 2011, 05:52:40 AM by fpgaminer |
|
I made little to no modification to their code for this first commit. If you appreciate their hard work on this Open Source project, please send them your thanks and donations!
TheSeven: 14Jc8vWq1mPv7vWnP5VquZZgpLEtzW2vja teknohog: 1HkL2iLLQe3KJuNCgKPc8ViZs83NJyyQDM
fpgaminer: 1NT4RyJMqtRuDRr6zHdXdKSpmX3SR5he6zThanks to the three of you for your work to date! Plonk, plonk, plonk. Heh, thank you njloof I really appreciate that. Quick update: I've been working with makomk's modifications and they do appear to be giving the performance increase and area reduction quoted. In fact, I saw ~75K LEs when I synthesized. Power consumption was estimated at 4.7Watts. Very impressive work! I'm doing another compile now and will do a live hardware test soon, to confirm correct share submission to mining pools. EDIT: Just tested the new code on live hardware (DE2-115). Works great
|
|
|
|
NetTecture
|
|
June 14, 2011, 06:25:30 AM |
|
Assuming a 4"x6" board 4-layer board, the PCB itself would cost about 25$ a piece in low volume (100 pieces...that's from pcbexpress.com). If there's not too much routing, we could go for a 2-layer board which would be half the price. Cut that in half if we make 1000's.
Assuming there is less than 100 parts on the board, assembly of 100 boards is about 50$ per board (that's from aapcb.com). I usually assemble the first prototype(s) myself. Again, cut that in half if we make 1000's.
We really need to wait how the ASIC shapes up before making wild guesses on the required additional components on the board (regulators, oscillator, interface, etc.). However, I would be really surprise if this turns out to be more than 10-20$ per board depending how "stand-alone" is the board.
PCB design is free, I have all the tools.
Is that most efficient? As in: would a larger board not be better? Yes, it may cost more (even per mhash), but there is a not insignificant overhead to "host" the boards. Tiven the standard MSI / Sempron approach I think 5 or maybe 6 boards only could go on a motherboard. Having a higher density, especially given the low power consumption, would not be negative. Then there is the whole driver issue at hand (sadly) Lokos like I would have to move to Linux. Anyhow, I wuold be jumping on board if someone could start putting some plan together within this month (i.e. prices as you did, timeplan, nothing showing post 3 months timeframe). I would be willing to take anywhere between 3 and 10 servers full of boards, which to my knowledge would be between 15 and 50 More depends on the final numbers. This would definitly change the market back to "commercial" miners, which I think is not a too bad thing - mining via gpu would not be cost efficient at all anymore. That said, it is definitly a good thing in my eyes - right now we have way too expensive mhash.
|
|
|
|
TheSeven
|
|
June 14, 2011, 10:46:31 AM |
|
Is that most efficient? As in: would a larger board not be better? Yes, it may cost more (even per mhash), but there is a not insignificant overhead to "host" the boards. Tiven the standard MSI / Sempron approach I think 5 or maybe 6 boards only could go on a motherboard. Having a higher density, especially given the low power consumption, would not be negative. Then there is the whole driver issue at hand (sadly) Lokos like I would have to move to Linux. Why have servers at all? For a couple of dollars more, you could equip those boards with an ethernet port and a small ARM processor running linux, with a ready-to-go firmware preinstalled, which would be configured through a web interface. Or possibly a backplane with the ARM processor and ethernet, which has a couple of slots for crypto slave boards containing the ASICs.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
NetTecture
|
|
June 14, 2011, 11:04:45 AM |
|
Is that most efficient? As in: would a larger board not be better? Yes, it may cost more (even per mhash), but there is a not insignificant overhead to "host" the boards. Tiven the standard MSI / Sempron approach I think 5 or maybe 6 boards only could go on a motherboard. Having a higher density, especially given the low power consumption, would not be negative. Then there is the whole driver issue at hand (sadly) Lokos like I would have to move to Linux. Why have servers at all? For a couple of dollars more, you could equip those boards with an ethernet port and a small ARM processor running linux, with a ready-to-go firmware preinstalled, which would be configured through a web interface. Or possibly a backplane with the ARM processor and ethernet, which has a couple of slots for crypto slave boards containing the ASICs. Not sure that makes sense, though. This would mean a LOT (!) more isntances to manage, a lot more ethernet port to block. I would go backplane. if we can use something like http://www.chassis-plans.com/single-board-computer/S6806-backplane.htm it gives us 20 PciE boards. Now, I would love to make as much use as possible out of this space
|
|
|
|
FlappySocks
|
|
June 14, 2011, 11:40:36 AM |
|
Whatever the design, it needs to be cheap and ready soon. You can bet there are lots of people working on private ASIC projects, which could obsolete everything.
|
|
|
|
NetTecture
|
|
June 14, 2011, 11:50:46 AM |
|
Whatever the design, it needs to be cheap and ready soon. You can bet there are lots of people working on private ASIC projects, which could obsolete everything.
I fully agree. As I said, I would commit to quite some. 3 full boxex minimum if pcie compatble, more if not needed. Get me a timpline and a preliminary price and a form factor and Iam willing to deposit money into escrow.
|
|
|
|
|
|
FlappySocks
|
|
June 14, 2011, 12:19:41 PM |
|
Looks like they only provide the IP and/or design services. Perhaps we could get a KickStarter project up and pay them to develop it.
|
|
|
|
OrphanedGland
Member
Offline
Activity: 70
Merit: 10
|
|
June 14, 2011, 12:51:57 PM |
|
|
|
|
|
tantive
Newbie
Offline
Activity: 10
Merit: 0
|
|
June 14, 2011, 12:55:58 PM |
|
@TheSeven: maybe I am wrong, but I am currently not sure if pyfpgaminer is still having some issues.
Currently I have two fpga board, running in different physical locations. Both boards are running different bitfiles.
If I now compare the outputs of pyfpgaminer, then on both consoles I see around 10% rejected shares. If I match the consoles timewise, then the rejects happen at the same points in time.
Do you have any idea if that could be related to specific api calls or something within the communication with the pool?
A)
Found share: eligius:dd51c0630a1638ba8e819b38aa18183b7d4e8d98d5260805d82f3ba9b3fdcbf8:bb9e77d84df7598d1a1d932f:7a031f22 eligius rejected share 7a031f22 Mining: eligius:f219c175c6f49f8ec2cf0b302307f4f439650c7886b7516ff06656ae84831717:dd20a1094df759a91a1d932f Mining: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f Found share: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f:6cfa9395 eligius rejected share 6cfa9395
B) Found share: eligius:3f8347933e5369be01edc6f05284cdefce58f727e97ef6c9334bc8da642a4186:c87f6b0f4df759641a1d932f:0bb3d26f eligius rejected share 0bb3d26f Mining: eligius:0c6933c15b68a5a1480f60382eaa95058eb8ddc3abf2629332c2bbbf05571b68:e3ea48fe4df7597f1a1d932f Mining: eligius:956dfec46f309dfe46db73459267fd2ac3a7b30d54b4ea1e6b437c879a2ee739:84ebf8984df7599a1a1d932f Mining: eligius:6a27c65613e41864db70feefdb8db812aecc86a6dedb6104b10f06acb20d7f2b:213e86ab4df759b71a1d932f Mining: eligius:434201cd46a5972605ee6a5f2fa4baa12f68b73871b164b82597f3a817258bb2:2dd2aca84df759d21a1d932f Mining: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f Found share: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f:2b11428c eligius rejected share 2b11428c
|
|
|
|
TheSeven
|
|
June 14, 2011, 01:34:16 PM |
|
@TheSeven: maybe I am wrong, but I am currently not sure if pyfpgaminer is still having some issues.
Currently I have two fpga board, running in different physical locations. Both boards are running different bitfiles.
If I now compare the outputs of pyfpgaminer, then on both consoles I see around 10% rejected shares. If I match the consoles timewise, then the rejects happen at the same points in time.
Do you have any idea if that could be related to specific api calls or something within the communication with the pool?
A)
Found share: eligius:dd51c0630a1638ba8e819b38aa18183b7d4e8d98d5260805d82f3ba9b3fdcbf8:bb9e77d84df7598d1a1d932f:7a031f22 eligius rejected share 7a031f22 Mining: eligius:f219c175c6f49f8ec2cf0b302307f4f439650c7886b7516ff06656ae84831717:dd20a1094df759a91a1d932f Mining: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f Found share: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f:6cfa9395 eligius rejected share 6cfa9395
B) Found share: eligius:3f8347933e5369be01edc6f05284cdefce58f727e97ef6c9334bc8da642a4186:c87f6b0f4df759641a1d932f:0bb3d26f eligius rejected share 0bb3d26f Mining: eligius:0c6933c15b68a5a1480f60382eaa95058eb8ddc3abf2629332c2bbbf05571b68:e3ea48fe4df7597f1a1d932f Mining: eligius:956dfec46f309dfe46db73459267fd2ac3a7b30d54b4ea1e6b437c879a2ee739:84ebf8984df7599a1a1d932f Mining: eligius:6a27c65613e41864db70feefdb8db812aecc86a6dedb6104b10f06acb20d7f2b:213e86ab4df759b71a1d932f Mining: eligius:434201cd46a5972605ee6a5f2fa4baa12f68b73871b164b82597f3a817258bb2:2dd2aca84df759d21a1d932f Mining: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f Found share: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f:2b11428c eligius rejected share 2b11428c
It's running fine over here with around 2% stales at continuum. Eligius is known to have very sluggish long polling, which means that it takes up to a minute until it notifies the miner that there is a new block. This could possibly explain a higher stale share rate, but 10% is a damn lot. Assuming your miner runs at 100MH/s, it will start working on a new job every ~30 seconds. At the default settings it can buffer up to four jobs in the worst case (1 being worked on, 2 in the queue, 1 being fetched, waiting to be put into the queue), which would keep it busy for two minutes. That would be around 20% stales in the worst case, so it seems like long polling doesn't work at all for you. Are you getting lines like "Long polling: eligius indicates that a new block was found" occasionally (every 10 minutes on average)? I'm running mine with 7 configured pools, and it seems like some of them (however not the primary two ones) drop long polling after like a day. The long polling thread can't possibly die (while True: try: ... except: pass), so there are two possible root causes for this: 1. Something on the pool side stops answering long polling requests (this was my suspicion, that some pools keep banning me for having long polling sessions but not sending any shares, because I only use them as backups if the primary ones go down) 2. Something in the python http client module I'm using locks up the long polling thread for the pool, even though I've specified a timeout of 2 minutes. I'll have a closer look what's going on. To mitigate the problem in the meantime, you can try setting "buffer": 1 and "fpgajobinterval": 10, which should bring the stales down to <5% even without long polling, but causes a higher pool server load.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
Rodyland
|
|
June 15, 2011, 03:13:19 AM |
|
Why have servers at all? For a couple of dollars more, you could equip those boards with an ethernet port and a small ARM processor running linux, with a ready-to-go firmware preinstalled, which would be configured through a web interface. Or possibly a backplane with the ARM processor and ethernet, which has a couple of slots for crypto slave boards containing the ASICs.
I like this idea, however maybe it's a case of walking before you run? Surely the flexibility of PCIe makes it useful in may cases, and adapting that to an all-in-one arm/linux unit is a small (and logical) next step. I know I have two computers with spare PCIe slots that I'd use to start with, test it out, make sure it all works well. Unless the arm/linux all-in-one miner is cheaper (by some measure)... I think that not everyone who would consider buying an ASIC miner will want to have a dedicated machine for it - just like today not everyone has a dedicated GPU mining rig.
|
Beware the weak hands! 1NcL6Mjm4qeiYYi2rpoCtQopPrH4PyKfUC GPG ID: E3AA41E3
|
|
|
inh
|
|
June 15, 2011, 07:44:02 AM |
|
Those of you with the xc6slx150's, what board are you using, or is it a custom design? I've yet to find anything (somewhat affordable) with that model on it..
|
|
|
|
TheSeven
|
|
June 15, 2011, 11:28:04 AM Last edit: June 15, 2011, 06:09:11 PM by TheSeven |
|
Why have servers at all? For a couple of dollars more, you could equip those boards with an ethernet port and a small ARM processor running linux, with a ready-to-go firmware preinstalled, which would be configured through a web interface. Or possibly a backplane with the ARM processor and ethernet, which has a couple of slots for crypto slave boards containing the ASICs.
I like this idea, however maybe it's a case of walking before you run? Surely the flexibility of PCIe makes it useful in may cases, and adapting that to an all-in-one arm/linux unit is a small (and logical) next step. I know I have two computers with spare PCIe slots that I'd use to start with, test it out, make sure it all works well. Unless the arm/linux all-in-one miner is cheaper (by some measure)... I think that not everyone who would consider buying an ASIC miner will want to have a dedicated machine for it - just like today not everyone has a dedicated GPU mining rig. I'd estimate the cost of the all-in-one standalone solution at about the same as a PCIe card (PCIe is a fast, but completely overkill and complicated interface, which just doesn't belong here). If you consider the price of the PC mainboard / CPU the standalone solution will definitely be cheaper. The ASIC card would be dedicated anyway. So why occupy a PC with it, if you can have the same functionality for the same price without the need for a PC? Yeah, you might save an ethernet switch port
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
makomk
|
|
June 15, 2011, 06:03:07 PM Last edit: June 15, 2011, 06:14:12 PM by makomk |
|
One obvious thing to bear in mind is that, at some point, the pools will inevitably all increase the difficulty of each share in order to reduce the work required to check all the submitted shares. So any ASIC-based mining system needs to be capable of checking hashes against difficulty levels above the minimum, either in the ASIC itself or in the processor controlling it. It looks like BTC Guild is actually making this change right now - there's a notice on their website saying they're doubling the difficulty per share. (This also requires changes to the software controlling FPGA miners.)
Edit: The other is that there's a good chance pools will eventually move to making miners compute midstates locally, again to reduce their resource usage. That's almost certainly best handled on a controller CPU rather than the main hash-computation hardware. What's more, since the rate of midstate computation is roughly proportional to the number of gigahashes/sec, mining ASICs would probably mean both of these happen sooner than they otherwise would.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
TheSeven
|
|
June 15, 2011, 06:18:58 PM |
|
One obvious thing to bear in mind is that, at some point, the pools will inevitably all increase the difficulty of each share in order to reduce the work required to check all the submitted shares. So any ASIC-based mining system needs to be capable of checking hashes against difficulty levels above the minimum, either in the ASIC itself or in the processor controlling it. It looks like BTC Guild is actually making this change right now - there's a notice on their website saying they're doubling the difficulty per share. (This also requires changes to the software controlling FPGA miners.)
Edit: The other is that there's a good chance pools will eventually move to making miners compute midstates locally, again to reduce their resource usage. That's almost certainly best handled on a controller CPU rather than the main hash-computation hardware. What's more, since the rate of midstate computation is roughly proportional to the number of gigahashes/sec, mining ASICs would probably mean both of these happen sooner than they otherwise would.
Both of these can easily be handled on the controller CPU up to an FPGA speed of several gigahashes, so this is just a firmware matter and not relevant for the actual ASIC. Oh, and yes, my miner ignores the requested difficulty. This just means that it keeps sending difficulty 1 shares, which means that it refuses to reduce the server load and ends up with roughly half of the shares being rejected, but will work perfectly fine apart from that. While it should of course be fixed, this issue isn't critical.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
|