That's because you guys don't do flight simulation... I don't have the desk real estate for 3 of those, though. And I'm in Europe...

You almost nailed it. I have the coding skills and I do a lot of embedded development, mostly with PICs but also H8 and the like. I never used FPGAs before and I've been waiting for an excuse for a long time now, so bitcoins might very well be it.

I have a pretty simple understanding of electronics, but I do have people So if I had to jump out of a dev board I could, and in fact would have all the expertise and industrial equipment available to me to do a full hardware implementation from scratch, but that obviously comes with an extra cost.

So, yeah, I *should* already know the answer to these questions if I had done my homework, but it's hard to keep up with everything and the bitcoin community has been the most helpful I've ever met... ever!

So before I decide to go fpga happy and shell out a few grand, any advice on Altera vs Xilinx vs whoever else? And what numbers / features should one look at in the specs when deciding what to get? LUT count is obvious, but what else?

I can't really tell from the pictures, does it have place for 2 PSUs?

Also, and more importantly, what would be the shipping cost to Portugal?

I did not look at the code but maybe you can clarify to me how this particular approach scales;

Say I use one of these http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=138&No=501 instead, what kind of performance could one expect? I'm assuming you can easily put multiple fully unrolled code paths for parallel execution.

How would one scale this to multiple FPGAs? Some communication between devices would be needed, or will there be a full TCPIP stack communitcation with bitcoin on each one?

I guess my confusion comes from my PC coding mindset. In the GPU implementation we just create the "unit" calculator and the GPU knows nothing about communicating to and from the bitcoin protocol, it just has an algorithm and a memory space to work with. In the FPGA though, you have to implement something to comunicate with bitcoind and, if using multiple devices, communicate with each one of them, right?

Sorry for the dense questions, just trying to understand this.

Assuming the 'COMMON' or 0V pins are indeed connected to ground (which in my very limited knowledge of electronics I'd assume) then wouldn't the hack to make the slave PSU power on with the master one automagically solve this? We are connecting one PWRON and one COMMON pin across the PSUs.

What OS did you use? In other words, would this work on linux?

Where are you? Any chance of shipping to Europe, and if so at what price? You wouldn't happen to be bundling a hard case?

By using the mentioned "hack" we will be connecting one "COMMON" line along with the "PS_ON". This is ground(ed), right?

Thanks for that. I actually used the green/black wire trick many times on water cooled set ups to fill the system and remove air bubbles without booting anything up. I can use that, certainly, but I don't like the idea of someday having to power down the machine remotely (has happened) and having that PSU just running and feeding a GPU, thus I search for something more permanent. I could just hack the thing up, push some clips into the connectors and all but there's enough equipment value involved to go that extra step.

Ahm, so why is the 3 day waiting period different from just shipping right away? If you wait 3 days so you can cope with a market swing during that period, who's going to protect you from a market swing the minute after you ship the record?

On a lighter note, how feasible / expensive would shipping to Europe be, if at all possible?

Didn't get anything on running it passed the "Using GLX_SGIX_pbuffer"

But to be honest I don't think the thing is honoring the sub display number or the driver is still trying for all cores. I used both "export DISPLAY=:0.0" and "fgl_glxgears -display :0.0" and both hang just the same, but if I *remove* the crippled card from the system it runs perfect. I'm guessing it is trying to access everything on bootstrapping and hangs?

No error, in fact I can list the devices on a display just fine. The thing might be running, but I see no output on the monitor, and it might very well just be an issue with the xorg.conf settings. I had to move my computer to the garage (too hot now to keep it around) and I don't really have a place to put the monitor right away. I'll retry in the next few days when I get a moment.

Would you also be able to provide the cable to power up 2 PSUs in tandem? Something like http://www.frozencpu.com/products/11742/cpa-167a/ModRight_CableRight_Dual_Power_Supply_Adapter_Cable.html?tl=g2c413s1220&id=qNzMZhNn

A little bump... if you've bid and are still interested please restate your bid, as the exchange rates have changed quite a bit. Shipping will be ~€30 for Europe (~$43). Probably close to twice that for US.


I can't get fgl_glxgears to work even on the other card with 2 good cores. I'm using a simple ubuntu server with manually installed X and drivers, so maybe I'm missing something.

Yep, it still is on the market

And it is still not connecting, or even trying to actually. I also tried with -connect instead, which keeps at least keeps popping those 'trying connection' entries in the log, but still doesn't connect.

What port is bitcoin testnet connecting to? I'll double check I can access it.

Well, it has one single

I'll let it run for a bit, see what happens.

But I'm puzzled; so the reason this works on non testnet new wallets (that don't yet have stored node addresses) is because there's a list of seeds hardcoded, which means no such list exists for testnet?

To me in Portugal. And it was pretty damn quick to arrive too

Hey,

I've compiled bitcoind from gavin's git at 04a667b0767a6c3fff8d24be784ccaec9edf712b on my mac, and while everything is working great for the real bitcoin network, testnet seems to refuse to bootstrap.

Looking at the logs it doesn't even try to connect to IRC, though I'm not using -connect nor -noirc (I am using -nolisten and -rpcport, as I have another bitcoin running).

What am I missing? Alternatively can you share the IPs for the some testnet nodes I can connect to?