Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards - page 35. (Read 182443 times)

You see this if the USB connection is interrupted. Check the USB cables and if possible, try out another port of the hub.

If it happens, you just need to rescan the bus (command "r").

The hex spacers are 5,5 cm, but you have to measure your heatsinks, bought at the most assorted screw shop in town... When it comes to temperature I actually "underclock" my chips. The way to do this is remove them from the cold air stream at boot up so they clock down to about 208/212 and then I place them over the air inlet on the edge of the window board. I can barely feel that they are warm, even on the bottom if the first FPGA. That way I know they will last as long as they can. The trick here is to have window board ventilators that are drawn by the evacuation air pump of the building, cooling without noise!

FYI, the brick from ztex get's a little too hot with 5 boards, atleast if you want it to last 10 years. I would buy a 80 watt instead. The DC splitter is awesome though!

EDIT: One last tip... the d-link usb router with 7 connections actually run 5 ports fine without external power, great to reduce power cable salad!

LOL, that's great!

That's a serious man cave, albeit a rather hot man cave

Holy shit dude. Seriously.

Has anybody seen this?  Was running steadily for a few days until this popped up:


It kept running like this until I noticed a slight drop in hash rate.  Restarted the java process and now everything is fine.

@ Rupy

That's a very nice rig you have there, Sir ! I like to see what others do with their boards. Cool

Nice setup rupy.  What kind of temp/Mhz are you getting with the passive heatsink?

The new Artix-7 28nm chip from Xilinx is for sure one of the most interesting new FPGA for mining. Unfortunatley this chip is not yet available, and what is even more worse there is no official announcement when it will get available. When the production of this chip starts it could also take a longer time until the chips are really available on the market for attractive costs, because large companies with high volume are already waiting for this type of chip to assemble their boards.

This week is the Embedded World tradeshow 2012. Maybe I can get some more information about the availability at the trade-show, but I guess we have to wait at least 6 month until a 28nm FPGA miner will be available. Spartan-6 is already available now and you can use the time (with a 50BTC blockreward) until the end of this year to compensate your investment in FPGA. I guess 28nm FPGA miner will start in the time area of 25BTC blockreward. So it will take much longer until you have your return of investment. Beside all of this the 'risk' grows that someday, someone announce a SASIC or even an ASIC.   
 

This looks like your MacOS is having a problem wit the re-numeration of the FX2 devices. If you would send the output I could say more.

Still a few niggles - similar to the 'USB issues' thread someone on the Ztex forums running Windows 7 64-bit is having - but I'm mining now

First error rate over 0.00% was when it hit 212 MHz - area around heatsink being around 41˚C according to IR thermometer. It's back to 208 MHz now and zero error rate.

As the picture shows, this is a test board with hardly optimal cooling so I'd be interested to see how my next boards perform with proper airflow.

Incidentally, I'm using the 64 bit Java USB libraries, still can't build the BTCMiner jar from scratch (missing symbol in the code), and my initial programming efforts (using the 15d3a.ihx firmware) seemed to fail - the process started, then claimed 'no ZTEX devices present' and further programming efforts resulted in 'no device found'.

Then, when disconnecting the USB, and reconnecting, my Mac tells me a 'Ztex FPGA device for Bitcoin mining' unit has been connected to the USB bus (I've got Growl set up to notify me of all hardware changes). Nice touch, so the programming may have worked after all...

So I kicked off a miner job using the pre-packaged Jar and it's merrily mining away. Looks like 208 MHz is the limit on the bodged cooling system I'm using, but subsequent boards will have much superior cooling - not just with the 'tunnel' concept but also with thermal contact between the heatsink (whatever I choose to use) and the FPGA.

Less than 10 W power consumption. W00t.

At least here in Hong Kong you get this stuff in electronic stores, somewhere near screws and nuts.

http://www.ebay.com/itm/50mm-PCB-Spacer-Hex-Stand-Off-Pillar-Male-Female-x25-/130626750145?_trksid=p5197.m7&_trkparms=algo%3DLVI%26itu%3DUCI%26otn%3D2%26po%3DLVI%26ps%3D63%26clkid%3D6625141050556940213

My point was exactly this. There is no way people using expensive 45nm parts will match BFL power hungry but cheap 65nm high performance parts like BFL.

UPDATE: Snow Leopard complete from-scratch SDK compile works with FPC 2.4.0.

Will be mining shortly

Yeah the prior person likely mispoke.  Some higher performance is possible.  ztex has boards running at 212 MH/s.  Still nobody is going to get 400 MH/s out of a Spartan so there will be no massive performance boost where a board costing roughly the same gets 25% or 33% or 50% higher performance.  The Spartan-6 is pretty well analyzed how so it is in the fine tuning.  A couple MH/s here and there.  Maybe someone gets a board going @ 220 MH/s which would be a nice 10% "free" compared to existing bitstreams but significantly higher performance is going to require a new class of chips.

There is no other 45nm chip which delivers the LUTs/$ that Spartan-6 does (without special "sweetheart" pricing) so that means waiting for the Artix-7 28nm chips to become available and at reasonable cost.  The largest Artix-7 chips likely can (eventually with a lot of bitstream analysis) achieve 500MH/s+ so a pair could provide the first GH/s board.  Still who know how long it will be (Q1-2013 ?) before Artix-7 provides better MH/$ than Spartan-6 does.

Any object pascal experts in the house? I've managed to bulldoze my way through all the roadblocks getting the SDK compiled cleanly on Mac OS X ice kitteh (aka 10.6) - it's taken bloody ages because of conflicts between USB library bitness, Java library bitness, and having to literally compile every dependency, none of which are versioned clearly, from scratch.

Part of the blame goes to Apple for having a schizophrenic Java implementation that 'cleverly' decides whether to run 32-bit or 64-bit depending on what you're trying to run. And having re-written Stefan's usblibJava Makefile to actually run on Snow in proper 64 bit mode, at last I had all the Java components compiled and working.

Most of the blame goes to me for not being as good as I think I am

I'm down to the last problem. I can't - for the life of me - get my head round BMP. The problem is simple - an include directive in the macro processor instantiates (recursively) a Macro buffer object which is added to the list of buffers in the object itself. The Macro buffer class is derived from the Text buffer class, and the latest incarnation of the Free Pascal Compiler won't allow a derived class to be passed as parameter to a method expecting the parent class, which is exactly what the code is trying to do.

So we've got object pascal, and an inherited class recursively calling its parent to include its contents.  OK, this isn't a simple problem at all...

I've rewritten the code to take the macro off the derived class, typecast the derived class as its parent and send *that* in the inherited constructor call, adding the macro stuff to the returned instance. Hey presto, it compiles.

However... it only builds a small proportion of the IHXs in the examples section.


What frustrates the hell out of me is that the basic code - UCEcho - compiles and builds a nice Jar file which actually *executes* and runs on my Mac and my FPGA. The USB libraries work, UCEcho tells me the device ID of my nice test board, etc. Hence *most* of the code is OK.

But many of the examples will not build, and neither will the BTCMiner firmware. All of them bomb out leaving a blah.tmp.c file of 64000 bytes (this is Snow Leopard, so may be exactly 64k - Apple confused us all with kilo / kibi and all that BS a while back) and an error of 'failure writing to blah.tmp.c'. No more verbosity can be obtained from the BMP macro processor, and there are virtually NO comments in the code.

Now I haven't been a professional coder for a LONG LONG time but this fucking infuriates me. It's a meta-meta-self-referential fucking parsing machine written in non-type-safe old Pascal and there's no commentary or verbose error messages. I'm trying my hardest here but I have the feeling that the code originally worked only because of some unintentional feature in a specific version of the free pascal compiler... and hence why binaries are included for Linux and Windows. That could be unfair, but anything recursive really needs proper commenting IMO, otherwise it's impossible to follow. The human brain has a stack of 7 items and you're doing well if you can use them all (top coders can, few others train their short term memories to that level)...

I've obviously tried to compile the SDK on Linux and it works immediately using the BMP binary included. Equally I've built the entire SDK from scratch using Ubuntu 11.04 - and it all works. Ubuntu Natty installs FPC 2.4.0...

So that's my final sticking point. It seems to be 100% due to the 'include' issue... which I've had to change. Equally, the entire functioning of the Pascal app may have been scrambled due to the latest version of FPC... comparing the actual bytecode IHX files produced by the Linux version and the OS X versions on the simple UCEcho code (which *does* work on both platforms), there are a bunch of differences and a few extra lines on the OS X side. This could be due to a newer / different version of the SDCC which could lead to faster / slower / non-functional code.

I'm hoping that the SDCC is backward compatible and produces functional code. Equally, now I've nailed Java down so it works properly (unsurprisingly enough, Java and Pascal are not on my CV but C, C++, unix and new scripting languages should suffice to pick anything up), I'm hoping that it's only a question of getting BMP working *properly*. I'm trying to compare output but the Linux builds don't leave the temp files.

I'm going to keep hammering away at this but would appreciate any assistance... for the time being, I'll see if I can remove FPC 2.6.0 from my Mac and install 2.4.0 instead... if this solves the problem then at least I'm up and running, but it's unsatisfactory as it means my main development box becomes instantly fragile - one 'port upgrade all' and everything's fecked...


ETA - Stefan - you beat me to it. The reason I asked about versions is because I thought you'd know and it'd speed up the process. I've solved the Java bindings of libusb for Snow Leopard and it requires a totally different Makefile than the one you supply. Yours assumes that Fink (an old package management system for earlier versions of Mac OS X, superseded largely by MacPorts these days) is installed, hence the references to /sw/lib etc. which give it away. Equally, there are two libusb implementations and the obsolete 'legacy' one is what is required (0.1.3 works - the current 1.0.8 does not).

The SDCC works without problems. BMP does not compile on 2.6.0, the latest version of Free Pascal. Try it. However it works on 2.4.0 as per my latest test on Linux, so I'm going with that for the time being. Apologies for the frustration but life moves pretty fast, as Ferris Bueller said, and FPC 2.2 is ancient, and Mac OS X moves *very* quickly and is perfectly happy to dump backward compatibility...

No offence intended for any of the ranting above, BTW. I don't want to 'just' run the miner pre-packaged... I want to have an SDK that I can compile from scratch whenever I want, and try out some of the examples in your SDK. I'm not your typical Mac user...

Doesn't eldentyrell three ring structure improve the performance or at least it will when the clock rate improves?
https://bitcointalk.org/index.php?topic=49971.0;all


marked

And where did you get them?

rupy how long are those hex spacers between the boards?

ztex is more expensive but the MH/w is higher and thus the chips can be completely silent like my solution above!