Bitcoin Forum
December 12, 2017, 12:49:42 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 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 52 53 [54] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 ... 118 »
1061  Bitcoin / Hardware / Re: Cairnsmore2 - What would you like? on: May 21, 2012, 03:32:23 AM
My advice to you, yohan:

Size each unit so that its fully-loaded configuration is about 960W. This will allow users to put exactly 2 of these units per 120V-20A circuit, or 4 per 240V-20A circuit, or 9 per 208V-30A 3-phase circuit (while not exceeded 80% of its maximum current rating). Rationale: in datacenter environments, users pay a fixed monthly price per circuit. A circuit not used at its maximum capacity (or a config not fully loaded to not over-consume) is wasted money. BFL failed to follow this advice of mine when designing their 1250W mini rig.

This so much. Ye typical DC gives you two 120v 20a circuits per rack and you have to pay for more at prices that are insane (but still cheaper than residential and small business electrical prices), and from what I've seen they max out at four 120v circuits at a rack. So, if all we have is 80a of 120v, we have to make the most of it as much as possible.

Given 1 units per 10a, each unit is, say, 4u big, a 42u rack will hold 8 of these units if we put 1u space between each one (which I've been told is normal for high density units so they don't cook each other) (= 5u), 8 * 10 = 80a, so we should be fine in an average DC, plus we have 2U to spare.
1062  Bitcoin / Hardware / Re: Cairnsmore2 - What would you like? on: May 21, 2012, 01:39:53 AM
We are looking to make this rack stand alone and yes it is up against Butterfly's larger products. We would like to make this run free of a host PC. This is very much a big system concept. I hope we do a better product that the competitors but time will tell on that point. It's very unlikely we will do a PCIe backplane for this although we are looking at these for our general HPC products. The bought in industrial backplanes are usually very expensive so it's unlikely we would but that in. However we can use one of our standard ones that we have designed or even a derivative of one of them. The cost is quite reasonable doing it this way.

I would forget any secondary value on any sort of mining kit. If you are banking on that your equations will be wrong. FPGA families have replacements on average every 2 years and the old family will have limited value even still as chips never mind in a system that has either to be reused or silicon recovered. GPUs are even worse for this. Try selling a 2-3 year old GPU. It might have cost 500 but in 2/3 years you can buy a brand new board of equivalent performance usually for less than 100. Second hand maybe it goes for 30. I for one would not want to buy a ex-mining GPU given the stress put on them but of course most people don't mention that on Ebay.

The only thing you need to focus on is total cost of ownership per MH without lowering the product quality like BFL has. A 4U rig with boards that can be installed after purchase would get a lot of people on board: however, 4U high density implies 2000w redundant 208/240v-only PSUs, and a lot of people in the US and a lot of DCs in the US simply do not have access to that.

So, maybe a 2U rig with half-height boards in a custom case that does 1200w max? As long as the density is as high as possible, you will have customers.

Plus, if you make this a generic rig and sell different sorts of boards for this, you essentially have an FPGA blade server. You could sell mining boards along with non-mining boards that your non-mining customers buy, and non-mining customers could very well buy mining oriented boards to combine them with non-mining boards to handle whatever they need.

Mining FPGAs, as far as I can tell, are largely just FPGA designs with high amp VRMs and no external memory chips and no high speed IO wired in. If you just need computation power without local memory or mass IO, mining boards really would be useful to you.

Centralizing all your FPGA products into a single FPGA-blade design would lower the cost for all customers theoretically.
1063  Bitcoin / Hardware / Re: Cairnsmore2 - What would you like? on: May 20, 2012, 04:23:34 PM
We are not likely to use PCIe in this way but it is a possibility for a quick picture have a look at http://www.schroff.co.uk/internet/html_e/index.html. So what we are taling about is a rack with card guides and a backplane at the back of the rack. The cards slide in and connect to the backplane.

The backplane standard could be an industry standard or just something we do to suit the purpose. The main thing is that the metal work and supporting guides are standard things. With a full height 19" rack we might be looking at fitting up to 4-8 sub racks depending on height we adopt on the sub-rack and what we have in power supplies. So we might be able to do an entire rack with 0.5-1 TH/s if I can add up correctly. Then it is just a case of adding racks. In data centres you might find hundreds of these sorts of racks.

I think those URLs are not the URLs you meant.
1064  Bitcoin / Hardware / Re: Cairnsmore2 - What would you like? on: May 20, 2012, 04:02:51 PM
Lets start by clarifying that it won't be a single big board. Those are actually expensive to make and there is no logic in this design that needs that approach. The architecture is more of a controller card with processing cards linked by a backplane that wires it all together.The backplane should let us have 12 working boards maybe up to 19 in one run depending on design decisions made.

Similarly PCIe is a bit of overkill for this one internally but could be used to link a rack to a PC or several levels of rack. We might do a PCIe card but that is a different project.

28nm at the moment may not be viable especially Artix that is probably 6 months away. 28nm may also be expensive initially. With what we are doing on bitstreams, and partner offerings, might mean FPGA type might be relatively irrelevant. It's more about the system cost than anything. 45nm may still be the best option today but that is one of the things that we are looking at.

Voltage that is used for whatever FPGA we use is being looked at. We might put in a VRM but that is probably more complicated than is necessary and has it's own cost. There are other ways to do this.

Historically fans have been a reliability thing and we might put in monitoring or PWM but these features do have a cost themselves both in materials and electricity. That needs to considered given the fans we are currently using on Cairnsmore1 have 100K+ Hrs lifetime (11-12+ years) and have a 6 year warranty. The floating bearings that have come in the last few years are a lot to do with this reliability and alternative approach might be a planned fan replacement maintainence schedule.

A fan tray may be the way we do cooling for this design and that would have whatever fan headers are needed. We have some other ideas here as well and more on those when we have thought them through as little better to see if they are viable.

Power wise this will take power from the backplane and there won't be a choice there. The processing card isn't a replacement for Cairnsmore1 but for the bigger rack market. Different backplanes are a possibility including a mini setup maybe with a cut down number of slots but that is for later after we get the big solution out in the wild.

Yohan


Using PCI-E connectors for the backplane connector (for connector only, obviously not electrically) isn't a bad idea. But how do you plan on putting all those boards in one box and not secure them somehow so they can't be accidentally disconnected inside of the case?
1065  Bitcoin / Hardware / Re: Cairnsmore2 - What would you like? on: May 20, 2012, 12:38:35 PM
Ok I will start this one off by saying that we are looking at a range of FPGA technologies to base the product on not that any of you might think we would start putting GPUs in our products although you never know. Some of our decisions will be based on how we do this week with more fully loading the Cairnsmore1.

We are probably thinking of 19" rack as a basis for this product and we already have some backplane designs that we did previously that might be useful either directly or in an adapted form. This also fits well with power supply availability and so on. This would also allow a modular purchase of a system that would be easy to upgrade and add to as time goes on.

One of our aims will is to be a very competitive FPGA solution in the market for large scale mining.

We have an initial individual card target of 4-5 GH/s+.

We are looking at our cooling technology and we are testing a new idea this week in a different product that might get adopted into Cairnsmore2.

Timeline - we are likely to limited by FPGA lead time which is typically 6-8 weeks so August-September is likely to be the initial availability of this system.

What we would like to hear from you guys is what you would like in interfaces? USB?, Ethernet - 100/1G/10G?, Cable PCIe?

And any particular features you might think we need to include?

Yohan

Well, imo, all future boards from any manufacturer of any kind needs two functions: a fan controller and enough fan headers so that it will ramp fan speed to keep constant chip temp to prevent both fan failure (running fans at 100% load is generally bad, even industrial fans often fail after 2 years) and chip failure (due to thermal cycling).... and the other function is software programmable VRM so FGPAs can be underclocked+undervolted on demand so people can keep mining as the difficulty rises thus extending the life of the hardware for another 2-3 years.

The only real request I have beyond those two mandatory features is 28nm on some mining industry agreed upon FPGA (it seems everyone is leaning towards the largest artix 7). Continued 45nm usage seems to be dead, it just isn't cost effective enough.
1066  Economy / Securities / Re: Starting a new FPGA mining farm/contract! Cognitive on [GLBSE] on: May 20, 2012, 08:48:54 AM
Motion Raised! Opposing what the motion page reads, and enforcing what the contract states: 70% of shareholders must vote "yes" for the motion to pass.

https://glbse.com/vote/view/24

If this motion passes, capital will be raised to purchase five Quad XC6SLX150 Boards, which are featured here: https://bitcointalk.org/index.php?topic=78239.0
1400 shares will be issued at 0.6BTC each. Remaining funds from this capital will be invested in other GLBSE companies/bonds, which will ultimately increase Cognitive's earnings. This will more than double Cognitive's current hashrate. The operator will maintain the contractually granted 10% of the company and will receive 140 shares.

Remember Cognitive is on the DMC bond trade list. 1 DMC for 1 Cognitive.
1067  Economy / Securities / Re: [GLBSE] Diablo Mining Company (DMC) on: May 20, 2012, 06:23:10 AM
By request I've added a new bond swap: JLP-BMD
1068  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (LP, BFI_INT, async nw, multipool, 79xx GCN) on: May 20, 2012, 06:09:40 AM
What's with the double spaced lines of output in this new version?  I personally don't like it.

Sounds like your terminal isn't quite wide enough.

The default size?  Yah no. 

DM's console code is _very_ dumb. If output is double spaced or otherwise garbled, make your terminal wider until it stops.
1069  Economy / Securities / Re: [GLBSE] Diablo Mining Company (DMC) on: May 19, 2012, 07:10:08 PM
We now have an official CoinConnect group: http://www.coinconnect.org/groups/profile/57824/diablo-mining-company
1070  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (LP, BFI_INT, async nw, multipool, 79xx GCN) on: May 19, 2012, 06:54:49 PM
This may be unrelated to typhoon's problem, but the latest version of diablominer fails to submit to and/or connect to the mining pool I've been using.

I'm running on 2011 iMacs, running OS X 10.7.4, with AMD Radeon HD 6750M (512 MB of RAM) and Apple OpenCL 1.1 (Apr 9 2012 19:41:45).

The command line arguments I'm using include:

./DiabloMiner-OSX.sh -w 64 -v 2 -na

The May 2012 version outputs the following:

Code:
[5/18/12 10:19:36 AM] Started  
[5/18/12 10:19:36 AM] Connecting to: http://mining.eligius.st:8337/    
[5/18/12 10:19:36 AM] Using Apple OpenCL 1.1 (Apr  9 2012 19:41:45)    
[5/18/12 10:19:37 AM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 10:29:40 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:31:59 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:38:21 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
mhash: 61.0/57.2 | accept: 0 | reject: 0 | hw error: 0

The March 2012 version outputs the following:

Code:
[5/18/12 2:09:31 PM] Started                                                
[5/18/12 2:09:31 PM] Connecting to: http://mining.eligius.st:8337/          
[5/18/12 2:09:31 PM] Using Apple OpenCL 1.1 (Apr  9 2012 19:41:45)          
[5/18/12 2:09:32 PM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 2:09:53 PM] mining.eligius.st accepted block 1 from ATI Radeon HD 6750M (#1)
[5/18/12 2:13:39 PM] mining.eligius.st accepted block 2 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:23 PM] mining.eligius.st accepted block 3 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:36 PM] mining.eligius.st accepted block 4 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:54 PM] mining.eligius.st accepted block 5 from ATI Radeon HD 6750M (#1)
mhash: 58.9/59.3 | accept: 5 | reject: 0 | hw error: 0

Are there any options I can use to give more verbose messages?

On an unrelated note, I've recently noticed this model iMac go down to ~50-60 mhash/s from a previously consistent ~70 mhash/s. Could this be related to May's change(s) or the latest Lion update from Apple?

Try a different pool. I have not changed anything that involves pools at all as far as I know. This has been largely the removal of code, not the changing of it.

As for OSX, its probably a Lion update. Quite a few Mac users have bitched that every time OSX puts a new update out, OpenCL apps get slower.

Unfortunately, I'm seeing the exact same problem on four different iMacs (all of the same model, OS version, etc.) regardless of whether the firewall is on/off. The only difference between it working and not is whether I run the March or May version.

Although I don't know much about the getwork protocol, eventually the March diablominer receives a response from the pool like the following (which I understand to mean that the work was accepted):
Code:
HTTP/1.1 200 OK
Content-Length: 40
X-Roll-NTime: expire=120
X-Long-Polling: /LP
Server: Eloipool
Date: Sat, 19 May 2012 17:15:11 GMT
Content-Type: application/json

{"result": true, "id": 1, "error": null}

As the result of sending a non-empty "params":[] value.

Whereas the May diablominer only receives new blocks after POSTing the following
Code:
{"method":"getwork","params":[],"id":1}

I sniffed the May diablominer with wireshark for twenty minutes and never saw a non-empty "params" value sent. The old one sends one every minute to few minutes.

I'm not sure how else to troubleshoot this. Have any of the command line options changed (--url being the only other one I use that I didn't already mention)?

I suppose I could try another pool, but the only variable here seems to be the newer version.

eligius uses its own pool software that no other pool uses. Its very well possible that it isn't interacting well with a newer version of Jackson... but I upgraded that back in January. I wonder whats going on, it doesn't make sense.
1071  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (LP, BFI_INT, async nw, multipool, 79xx GCN) on: May 19, 2012, 06:50:24 PM
What's with the double spaced lines of output in this new version?  I personally don't like it.

Sounds like your terminal isn't quite wide enough.
1072  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 19, 2012, 06:35:50 AM
Not sure if people caught this earlier, but if a Spartan 6 maxes out at 1 amp each (assuming ~250 mhash per Spartan 6 with the most optimized bitstream possible), you could power 28 Spartan 6s off a single EPS12 plug (28 amps == 336 watts), which would really reduce the wiring mess inside of such a flat case.

I wouldn't be against someone selling a 16-24 FPGA board that fits in a 1U case (slightly custom or not) with 6 or so 10krpm 40mm fans in the front and comes with a chopped down 1U PSU inside of it that just has the EPS12 plug and no other wiring and autostarts without ATX green wire signal.
1073  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 19, 2012, 06:11:42 AM
If you were interested in say mounting in a 3U rack a bolt-on mechanical board edge could be made to make the board the right width. A wider or longer variant of Cairnsmore1 would also be possible. That's only a few minutes of design time. It's then more a manufacturing thing where it splits the volume and we buy in 2 PCBs rather than 1. However if there is a serious requirement for this and enough orders say 25+ units we could do it for a small increase in cost. Other than the PCB all the other components can stay the same and we get the volume pricing advantages of that. Worst case (small numbers) the pricing delta might be about GBP 25 / US $40 per board. If that is of serious interest to anyone it is worth contacting us. It's something we can do without a serious effect on the current batch build. The current heatsinks should work well in a rack config if suitable runner spacing is used as we considered side blow when we choose them as much as the downward standard configuration.

Well, I imagine a lot of people would be interested in an ATX/EATX sized board had 16 or more FPGAs that came with copper 1U heatsinks so they could drop it into cheap 1U cases. Except I think it'd require a redesign, you couldn't just fab 4 of your quad boards on one giant board and have it still fit in the ATX/EATX specs.

I'm just putting the idea out there, because there clearly is a market for things like the BFL MiniRig and I don't think the MiniRig is the right answer to the solution.
1074  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 18, 2012, 11:28:57 PM
people want to buy BFL finished products not hack together an ugly solution.

I'm just trying to help Enterpoint produce a product that people will want. Something that drops right into a generic 1U case would be a pretty valuable product... I imagine even non-mining FPGA customers would be interested in it.

While a case maybe be nice for those that want it I have no problems with an open air solution in fact I prefer that option not only does it save me money on something I don't want/need to have my boards will run cooler due to the lack of a case. Plus could be a nice business to someone like yourself that wants case get some made and if most people are thinking like you then they can buy them from you.

Cases double as air channels, really. The way most of these FPGAs are built are not meant for straight through airflow, which is kind of silly. Typical "fan down" heatsinks are fail, too much turbulence to be effective cooling.

Don't know why your even bother mentioning the BFL labs as a good idea then they use a similar design, I've seen more than a few my BFL is throttling posts on here.

I didnt mention BFL's cooling as a good idea. I mentioned their use of a SATA plug for the USB connection on their Minirigs. That actually IS a good idea. You can get enterprise SATA locking connectors that won't wiggle loose during transit.

So which is it then BFL is great because it has got case or it sucks because the cooling is no good in that case. I for one am failing to see the point your trying to make here putting these boards in a case is going to lead to the same cooling problems as with the BFL.

I don't understand your point. BFL came up with a good idea to do interconnections inside of their MiniRig. This has nothing to do with cooling. BFL does not use straight through cooling in their MiniRig either, which is a complete engineering design failure.

Putting boards in a case does not cause cooling problems as the case acts as a channel. Please do not spread FUD, and look how enterprise computers are typically designed.
1075  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (LP, BFI_INT, async nw, multipool, 79xx GCN) on: May 18, 2012, 11:24:13 PM
Just reporting in that after I upgraded to the latest DiabloMiner, on both my Windows and Linux machines the miner starts as usual.. adding the devices and then hashing away.. However, shares are never submitted.  I walked away for a while and saw that in fact no shares had been submitted to eligius.  For proof check out: http://eligius.st/~artefact2/7/1AXiiwR4aYktPKMBMsZaP1untDgN9T8FfX

Edit: Found an older DiabloMiner and reverted (it does not include the 2 latest commits), back to mining.

I cannot reproduce that bug. BTW, I've dropped OpenCL 1.0 support, so if you're on SDK 2.1... don't do that. DM is supposed to detect if you're on 1.0 and refuse to use those devices, too. Well, assuming I coded that test right.

I am on Catalyst 12.4 and the SDK that is included with the drivers.  Radeon 5870s/5850s in both boxes (CentOS/Windows 7).  If there is anything I can do to help you possibly pinpoint the problem I am all ears.  Basically diablominer adds the OpenCL devices then starts hashing away at only god knows what.. and never submits shares, all whilst hashing at full speed and making my GPUs waste energy.

The hash meter has a number above zero, right? I'm wondering if Windows has a driver bug that Linux doesn't, because I'm on Linux /w Catalyst 12.4 using the runtime that comes with the drivers, and I can't reproduce it.

Yes the hashrate is at full speed, causing 100% gpu usage on all gpus.  This happens on 2 separate systems, both with catalyst 12.4 and the included sdk.  One system is windows and one is linux (CentOS).

Thats extra weird. I'm going to have to think about this one for a bit. It doesn't make sense you have the bug and I don't... I wonder if its hardware related, because I'm on a 7970, not a 58xx.

This may be unrelated to typhoon's problem, but the latest version of diablominer fails to submit to and/or connect to the mining pool I've been using.

I'm running on 2011 iMacs, running OS X 10.7.4, with AMD Radeon HD 6750M (512 MB of RAM) and Apple OpenCL 1.1 (Apr 9 2012 19:41:45).

The command line arguments I'm using include:

./DiabloMiner-OSX.sh -w 64 -v 2 -na

The May 2012 version outputs the following:

Code:
[5/18/12 10:19:36 AM] Started  
[5/18/12 10:19:36 AM] Connecting to: http://mining.eligius.st:8337/    
[5/18/12 10:19:36 AM] Using Apple OpenCL 1.1 (Apr  9 2012 19:41:45)    
[5/18/12 10:19:37 AM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 10:29:40 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:31:59 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:38:21 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
mhash: 61.0/57.2 | accept: 0 | reject: 0 | hw error: 0

The March 2012 version outputs the following:

Code:
[5/18/12 2:09:31 PM] Started                                                
[5/18/12 2:09:31 PM] Connecting to: http://mining.eligius.st:8337/          
[5/18/12 2:09:31 PM] Using Apple OpenCL 1.1 (Apr  9 2012 19:41:45)          
[5/18/12 2:09:32 PM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 2:09:53 PM] mining.eligius.st accepted block 1 from ATI Radeon HD 6750M (#1)
[5/18/12 2:13:39 PM] mining.eligius.st accepted block 2 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:23 PM] mining.eligius.st accepted block 3 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:36 PM] mining.eligius.st accepted block 4 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:54 PM] mining.eligius.st accepted block 5 from ATI Radeon HD 6750M (#1)
mhash: 58.9/59.3 | accept: 5 | reject: 0 | hw error: 0

Are there any options I can use to give more verbose messages?

On an unrelated note, I've recently noticed this model iMac go down to ~50-60 mhash/s from a previously consistent ~70 mhash/s. Could this be related to May's change(s) or the latest Lion update from Apple?

Try a different pool. I have not changed anything that involves pools at all as far as I know. This has been largely the removal of code, not the changing of it.

As for OSX, its probably a Lion update. Quite a few Mac users have bitched that every time OSX puts a new update out, OpenCL apps get slower.
1076  Bitcoin / Bitcoin Discussion / Re: [Emergency ANN] Bitcoinica site is taken offline for security investigation on: May 18, 2012, 08:59:17 PM
I'll be sure to let you guys know when I get the $300,000 or so I had in long positions before I use it to buy on MtGox.

But if the BTC price were to drop to say $0.50 or rise to say $50 before the Bitcoinica positions were closed and the accounts settled with the clients  then the real fun begins.

And people wonder why I called Bitcoinica a bucket shop.
1077  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 18, 2012, 08:32:11 PM
people want to buy BFL finished products not hack together an ugly solution.

I'm just trying to help Enterpoint produce a product that people will want. Something that drops right into a generic 1U case would be a pretty valuable product... I imagine even non-mining FPGA customers would be interested in it.

While a case maybe be nice for those that want it I have no problems with an open air solution in fact I prefer that option not only does it save me money on something I don't want/need to have my boards will run cooler due to the lack of a case. Plus could be a nice business to someone like yourself that wants case get some made and if most people are thinking like you then they can buy them from you.

Cases double as air channels, really. The way most of these FPGAs are built are not meant for straight through airflow, which is kind of silly. Typical "fan down" heatsinks are fail, too much turbulence to be effective cooling.

Don't know why your even bother mentioning the BFL labs as a good idea then they use a similar design, I've seen more than a few my BFL is throttling posts on here.

I didnt mention BFL's cooling as a good idea. I mentioned their use of a SATA plug for the USB connection on their Minirigs. That actually IS a good idea. You can get enterprise SATA locking connectors that won't wiggle loose during transit.
1078  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 18, 2012, 08:07:56 PM
people want to buy BFL finished products not hack together an ugly solution.

I'm just trying to help Enterpoint produce a product that people will want. Something that drops right into a generic 1U case would be a pretty valuable product... I imagine even non-mining FPGA customers would be interested in it.

While a case maybe be nice for those that want it I have no problems with an open air solution in fact I prefer that option not only does it save me money on something I don't want/need to have my boards will run cooler due to the lack of a case. Plus could be a nice business to someone like yourself that wants case get some made and if most people are thinking like you then they can buy them from you.

Cases double as air channels, really. The way most of these FPGAs are built are not meant for straight through airflow, which is kind of silly. Typical "fan down" heatsinks are fail, too much turbulence to be effective cooling.
1079  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 18, 2012, 07:43:26 PM
It makes more sense, but it makes less economical sense. In the long run, I only care about cost per FPGA, and a 16x board should cost less than four 4x boards or eight 2x boards or whatever.

I agree completely, but only under the circumstance that the "better" option is available immediately (or available at a MUCH better cost/performance ratio)

If I have funds to buy say 8U filled with Cairnsmore1 right now (32 boards) and they are available in the next 30days, yet it would be 2-3 months before even the possibility of a higher density better solution, I'd rather be mining for that 2-3 months on the slightly less optimal Cairnsmore1 option, and re-evaluate when the available options change.

Also considering the smaller boards let me grow in a more fluid fashion, I can increase my hashing power in a fairly aggressive curve.

IE: 32 boards at 4x FPGA each, lets just for round math assume 800MHash even per board. So 25.6Ghash from that cluster, that lets me mine around 475BTC per month at current difficulties. That 475 can be re-invested in roughly 2 more boards (At the inflated "full" price). those 2 new boards generate about 30BTC a month, So month 2 I have 505BTC, buy 2 more boards, then I have 60 spare next month (plus the 30 from previous month) buy 2 more, now I Have 90 spare, plus the 90 from the previous 2 months, now that's 180 on top of the base 475, which buys me 3 boards. and so on. Typical exponential growth curve, allowing me to add quite a bit more hashing power in the timeframe it would take just waiting for the new boards to possibly come out.

I realize my math above may be skewed or off (it's all off the top of my head) But I've also done forecasts based on this (with real numbers in extensive spreadsheets). Looking at smaller boards versus larger boards with slightly higher performance/$ ratio, and the smaller boards won out in longterm ROI. (because they grew faster due to the fluid expansion). Especially when the larger option wouldn't be available initially for some time.

This is of course offset if the higher end board is much lower cost per MHash but I would be surprised if doing a much larger board dropped more than 10-15% off the price per chip. (just personal opinion though lol so take with a grain of salt) Smiley

Your numbers are probably in the right ballpark. Problem is, people want to buy BFL finished products not hack together an ugly solution.

I'm just trying to help Enterpoint produce a product that people will want. Something that drops right into a generic 1U case would be a pretty valuable product... I imagine even non-mining FPGA customers would be interested in it.
1080  Bitcoin / Hardware / Re: Quad XC6SLX150 Board - Initial Price 400/$640/520 on: May 18, 2012, 06:14:41 PM
Impossible to calculate because you're talking nonsense. What rack mountable case is going to fit 24 inches of cards? And don't say "just make a 8 FPGA 24 inch card" or something. The reason I specifically picked PCI-sized boards is because it is cheaper to produce PCI-sized boards due to the entire industry based around making them.

So, sure, lets use rainbows and unicorns and say you can fit 24 inch cards in cases that are somewhere around 23 to 31 inches deep inside without modifying the case (removing unused drive bays COSTS MONEY, changing the case design at all COSTS MONEY). And each one of those cards costs about, oh, $1220 to produce, and you can fit 7 cards in there, so thats $8540 for 56 FPGAs, plus who knows what for some controller board (lets say $100) because you just really really want one instead of just using SATA plugs like BFL did for the minirig.

per 56 FPGA/4U: $8540 for 7 56 FPGA boards, $100 for a board that does nothing but route serial connections, $70 for a Norco 4U case that fits EEB and has 2 80mm fans (and we need more than that so theres even more money wasted), and $160 for a NZXT Hale 90 750.
total cost per 4U:$8870 or $158 per FPGA.
if something goes wrong: You lose 8 FPGAs minimum, 58 maximum.

So not only do I get more density per 4U, my solution comes in cheaper.

I'm not sure where you're getting the 24" card thing from?

I'm not trying to be an ass, I just think we're perhaps arguing 2 different points. You seem to be arguing the "best case optimal high density mining" solution, and I'm talking about "How can I best mount the cairnsmore1 cards in a rack". Smiley

I'm planning on mounting them similar to this:
https://bitcointalk.org/index.php?topic=70611.msg844733#msg844733
(that's my current icarus setup)

But using a 4U actual rackmount case rather than a wooden 3U case.

Mounted vertically the cards will need about 2" wide, a rackmount case is about 17" wide on the outside (so at least 16" - 16.5" of usable inside room side to side) and about 14" deep for the motherboard compartment (12" - 13" for the actual motherboard plate). These cards are like 6" - 7" deep so I can stack 8 of them side by side, 2 deep in the same arrangement I have in that photo. Filling the back of the case (like I said redirect the powersupply to the front of the case in place of the 5.25" drive bays).

This gives me room for 16x cairnsmore1 cards in a 4U rackmount case, with tech available right now (not a hypothetical future product). so a total of 16 FPGAs per Unit of rack space.

I'm not talking about an "optimal end solution for best case high density bitcoin mining" that's obviously going to require some higher density special purpose hardware, like the Merrick3 adjusted for higher power density, and put into a standard PCIe motherboard. OR the Merrick1 modified for a few less chips (maybe half, like 50 chips) and higher power density. I agree completely, a 100% custom 1U case with a custom board (or boards) holding a lot of chips will result in the best density. But that product doesn't exist, and won't exist for at least a few months (and that's if someone starts working on it right now).

The cairnsmore1 will be available in a couple weeks, so I'm talking about the best way to mount THOSE boards in a rackmount enclosure.

Also to note, I'm not talking about custom cases. I'm talking about an off the shelf case, which has removable drive cages already, you just unscrew it and remove it. Problem solved. Sure you need some custom brackets/clips to mount things, not a problem. That's what a 3D printer is for Wink

Also yeah I planned on using the HALE90 as well in my build.

Does that make a little more sense? Smiley

It makes more sense, but it makes less economical sense. In the long run, I only care about cost per FPGA, and a 16x board should cost less than four 4x boards or eight 2x boards or whatever.
Pages: « 1 ... 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 52 53 [54] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 ... 118 »
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!