Pages:
Author

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

hero member
Activity: 518
Merit: 500
Im aware of BFL, forgot to mention that I live in Europe.

Reasons,

1.Insane prices to ship from US and pay toll and taxes.
2. And Ztex offers better guarantees and discounts.

Thats why im asking Smiley

Regards
Robin
Well I think somebody will end up being a EU reseller with manageable prices and no import duty etc.

But ZTEX offers 2 year warranty while BFL only 6 months Huh
newbie
Activity: 17
Merit: 0
Im aware of BFL, forgot to mention that I live in Europe.

Reasons,

1.Insane prices to ship from US and pay toll and taxes.
2. And Ztex offers better guarantees and discounts.

Thats why im asking Smiley

Regards
Robin
hero member
Activity: 725
Merit: 503
hero member
Activity: 518
Merit: 500
Maybe not the right thread to post in, but is anyone know if ztex(stefan) is working/planning to release on a new board with higher hashspeed? And maybe an eventual date?

Regards
Robin

I suggest going to look at the BFL product.

I think people using Spartan 6 will not get any higher hashrate from now and it looks like 180 - 200 MHash/s is the cap.

newbie
Activity: 17
Merit: 0
Maybe not the right thread to post in, but is anyone know if ztex(stefan) is working/planning to release on a new board with higher hashspeed? And maybe an eventual date?

Regards
Robin
hero member
Activity: 725
Merit: 503
Quick cluster tutorial:

java -cp ZtexBTCMiner-120221.jar BTCMiner -f ztex_ufm1_15d3a.ihx -m p
java -cp ZtexBTCMiner-120221.jar BTCMiner -host XXXX -u XXXX -p XXXX -m c

Done!
donator
Activity: 367
Merit: 250
ZTEX FPGA Boards
Compilation of the SDK for MacOS is known to work. Several customers did it. But don't ask me about the MacOS version or names of development packages or so.

For compiling the Java bindings of libusb you need to use the "Makefile.macosx" in the libusbJava-src directory. Dependencies are libusb, the java development kit (jdk) and certain OS headers (for type  definitions.)

Compilation of bmp works without modifications. It is tested at least it at with Freepascal versions 1.0, 2.0 and 2.2. There are no other requirements.

As written earlier (https://bitcointalksearch.org/topic/m.752052)  you just need to copy the library to the working directory of your BTCMiner, i.e. compilation of bmp is not required.

AFAIR one customer created some MacOS packages of the SDK and published them somewhere (ask google).


...
One polite request Stefan - could you list the actual versions of the APIs / SDKs / libraries that your SDK depends on?
...
donator
Activity: 305
Merit: 250
Oh, my bad. I know you're running a mix of 1.15d and 1.15x and thought the one on the right is a 1.15x. I guess part of the board just got cut off in the picture.
brand new
Activity: 0
Merit: 250
Angry

Right then - looks like the compilation problems for the macro processor code are as I suspected - my environment / tools.

The Free Pascal Compiler had a major 2.6.0 release on the first of January this year. There were numerous language changes, of which I've speed-read through, and my bug-detection software immediately made one sentence stand out in flashing lights: 'passing derived classes to var- and out-parameters'...

Unfortunately the behaviour changes mean that Stefan's code won't compile under 2.6.0. Even more unfortunately, the 'Remedy' suggested is 'Rewrite the affected code so it (sic) that all var/out-parameters and the class types passed to them match exactly'...

http://wiki.freepascal.org/User_Changes_2.6.0#Passing_derived_classes_to_var-_and_out-parameters

Oh well. Looks like I'm learning Pascal today. It sounds trivial (i.e. simply change the type of the var-parameter in the class) but the affected code *looks* like a recursive routine where a class repeatedly creates new instances of itself and adds them to itself. Changing the var-parameter class would break external non-recursive calls. Not having formally studied Computer Science, the one technique that still makes me have to think a bit is damn recursion... of course, if the method concerned is only ever called within the class itself then I could try to overload the constructor to allow two parameter types... it'd work in most OO languages I know, but if you say 'Pascal' to me then I immediately think of my sister (who is named Pascale, the bloke's version would be a bit odd) Cheesy

I suppose I could install a legacy compiler, but if the ZTEX SDK is to run on Mac OS X, then I reckon it should use the latest tools inc. what comes with Mac OS X. Only my opinion. Should have it built along with an OS X-specific README and alternative Makefiles, plus that bmp.pas source, some time today.

Please note - I'm doing this as an enthusiastic old hacker... not a professional code monkey, and not as a ZTEX affiliate, employee or whatever. Hence I'll be submitting the changes to Stefan first before sending changes to anyone else. It may be GPL and I may have the right to alter the code, but as I pointed out, the last time I had any exposure to Pascal was 25 years ago or so, and Stefan may have a better way to make the changes; indeed he may see my interference as unwelcome or as 'botching' his code.

Stefan - you definitely need a dependency version listing in your Wiki Wink
legendary
Activity: 1022
Merit: 1000
BitMinter
Nice custom setup!  It looks like for the 1.15x you have ditched the stock heatsink.  Are those aluminum heatsinks?  I am thinking copper won't make much of a difference since the key bottleneck is the transfer from the FPGA to the heatsink.

This are 1.15d boards ! The heatsinks come with them but you can't really go bigger because the heatsink would collide with some parts on the board. 1.15x leaves you more room for modifications.
brand new
Activity: 0
Merit: 250
Well, I have to give it to you.  If you're willing to code support for ztex on a Hackintosh, you are a better man than I am.  I also run VMware.  I notice the workstation version runs much better with win7 as a host than Ubuntu.  Believe it or not, I ran a Win2k8 server as a VM inside Win7 (don't ask me why) running a web/SQL server.  No issues for 5 straight months.

Regardless, good luck with your endeavor.  I see you have a nice setup with the 1.15d although I have to say I like how compact the 1.15x is (big where it counts=heatsink  Grin)
Cheers Smiley

The board is very much a Test Unit as per the child-like writing on the piece of MDF Cheesy

I like the additional length and 'wind tunnel' feature of the 1.15d / Exp. Board 1.3 combo - and not just because I can bolt in a big SDHC card to run rainbow table apps etc. Purely focusing on BTC mining right now, I've run into big thermal problems with a 9 GHash GPU-based frame rig contraption (pics on the other thread here, won't clutter this one up). Running high-density units (in my first case, GPUs) horizontally, with the fan having to blow air *down* onto a heatsink, with maybe another hot unit sitting above or to the side, is just thermodynamically inefficient. The fans are working against physics, and if there's another GPU directly above the fan, then it can only blow red-hot air from the back of the upper GPU core onto the heatsink. Cue high temperatures and fans running at 85-100% capacity.

I've had loads of fan failures on GPUs and eventually switched to a vertical layout, where the main GPU exhaust points straight upwards. This allows convection to provide cool air for the fans to blow sideways onto the heatsinks... but with a high-density setup, radiated heat from the backside of the GPU next door is *still* a problem. The retail GPUs don't cool the rear side of their circuit boards and I've measured them at up to 90˚C in places using an IR thermometer.

With the 1.15x all-in-one solutions, the design is very much like a traditional GPU / CPU. A fan blows air down onto a big heatsink. Of course, the TPC is so much lower that my considerations are almost moot... but with the comment that the FPGA must have hit 90˚C (by Stefan, discussing when the active fan failed), there's room for making use of convective cooling as well as relying on downward-blowing physics-fighting fans Smiley

OK, so I'm a mad fan of the Apple G4 Cube. If there was a hope in hell of compiling Stefan's SDK for PowerPC then I'd be using my example (pride of place on my desk, kept alive at all costs, though not doing much right now after having burnt out 4 GPUs, 3 hard drives and a PSU) to control the FPGA array I'll eventually build.

Using the same concepts, look at the 1.15d and how it connects to the Exp Board 1.3. My picture above is my Test Unit as explained. My quad-board rig design (had to downsize from 5-board because the fans pushed the power budget too close to the PSU max output!!!! heh) will have each unit mounted vertically, with the power and USB connections at the bottom, in a Cube-styled enclosure with adequate venting for cool air to enter from below, rise up through the boards, and exit at the top.

I don't plan to use ANY active fans on the 25mm heatsinks supplied with the 1.15d boards. The cheap crappy fan on my picture above is there for safety, and I'll be removing it during testing to see whether the horizontal fan keeps the board cool enough.

You see, there's a tunnel between the FPGA board and the Experimental Board. Even with convection only, cool air will flow through this 'tunnel' and provide cooling to the immediate *reverse* of the FPGA, which will be getting hot. The Experimental Board itself will provide a heat barrier to prevent the back of the FPGA heating the front of the board next to it (remember it's high-density, like the GPU solutions).

I think this 'tunnel' and the ability to direct cooling air to the *back* of the board, something most people ignore with GPUs (and is a very significant heat load in high density rigs) is a great feature of the 1.15d setup, which is why I'll be going to use these rather than the optimised 1.15x boards.

Without tall, small-diameter fans on each FPGA heatsink, my enclosures can be made more elegant whilst still maintaining high density. I don't know what Stefan's 1.15x active cooling product is like, as I can't use it, but my experience with small-diameter cooling fans as per those used on older GPUs etc. is that they can make a horrible high-pitched whining noise. I'm sure Stefan's is a quality item but in 6 months, will it be making a racket like some of my GPU fans?

This is all moot if my design doesn't work, of course. I'm doing a Cube but having two 80mm PC case fans blowing cool air up from the bottom, and two identical fans at the top of the enclosure blowing hot air out. Inside a sealed acrylic enclosure, this should provide enough pressure to ensure air is *forced* through the 'tunnels' and through the pins on the FPGA heatsinks. We're only talking about 10W per board max, after all...

If there's a way to read the temperature of the FPGA core and feed this back to the fans, then a *really* neat automatic solution could be built - but to begin with I'll simply chuck a potentiometer in with the fans. I'm hoping that four 80mm 3W fans is massive overkill for my design, and the fans can be run slowly and *quietly*.


Put it this way, my girlfriend has put up with my GPU frame rigs for months now. The noise made by all the fans is enough to affect *my* sleep and I'm accepting it, not getting irritated by it. Hopefully my FPGA rigs, when complete, will be damn-near silent. It would be poetic to have the G4 Cube managing the FPGAs... but the Cube doesn't even have USB2 and I still haven't managed to compile the SDK on a reasonably-standard Intel Snow Leopard Mac yet... so my old first-gen AppleTV, which (with a bit of hacking) can be made to run the regular OS, may be put into use if there are no OS snags. Otherwise it's a Mac Mini.

Regardless, it's going to look cool, hopefully run cool, and whilst replacing 9 GH/sec is beyond my financial means at the moment, once I've got this SDK built on the Mac, I'll be discussing volume discounts and best deals with Stefan Wink
donator
Activity: 305
Merit: 250
Nice custom setup!  It looks like for the 1.15x you have ditched the stock heatsink.  Are those aluminum heatsinks?  I am thinking copper won't make much of a difference since the key bottleneck is the transfer from the FPGA to the heatsink.
legendary
Activity: 1022
Merit: 1000
BitMinter
You can't see much different from the other side. Since the PSU is emitting warm air, i decided not to drill a hole in the wall. The fan would just suck hot air out of the PSU. Instead i moved the fan about 1cm from the wall to help blowing the cold air from above over the boards. It makes a big difference ! At first my plan was to go only with the 120mm fan but it did not work out as i expected. Both fans run at 13.8V which gives them a little boost. They are from be quiet, below 20db. Best fans for the money imo ! I love them.

You can see that board nr6 needs some help to stay cool but the clamp is also transfering some heat away.  



brand new
Activity: 0
Merit: 250
Hey Catfish, just curious, does OS X support running VMs?  I would think the java process/drivers should have no problem running inside a VM (as opposed to GPUs).  It would be nice to have an OS X software, but maybe run linux inside a VM if you run into more roadblocks.
Part of the appeal of proper Macs (and Hackintoshes, though these have to be *damn* finely tuned to run all logic board resources properly and tonymacx86's friendly 'it's as easy as 1-2-3' website is only half the story... I have an ex-BTC miner case with far too powerful a CPU (i5-2500) currently running Snow Leopard and it's quicker than the 8-core Mac Pro I'm typing this on, and has three GPUs in it) is that they're great development platforms.

OS X was always good for development - proper Unix, best UI in the business, and a whole host of features targeted at the developer as a *user too* made for great cross-platform development as Apple hopped on the open-source bus (some bitterly complain about Apple's selectivity, some simply applaud the professional work given back esp. in compiler development). With Intel Macs, you've then got a machine that can run every significant desktop OS natively (seeing the number of Mac laptops at hacker conventions says it all, really) - web developers in particular can test every target config on the same Mac very easily.

Yeah, you can run VMs on Windows too, but until very recently it wasn't possible to run Mac OS X inside a VM on Windows or Linux - so the only OS out there that allowed development and testing of all major platforms was Apple's. The 'Apple Tax' looks cheap when you only need one machine to run every OS at the same time, and their laptop design is IMO way superior to anyone else in the market (I wouldn't buy Sony with a gun to my head due to their rootkit scandals and proprietary Windows-only support). I seriously use a 10" Macbook Air as my main consultancy machine (OK, it's got a $600 Sandforce SSD upgrade!) - for what's smaller than a netbook, it runs ridiculously well (including running financial analytics software in Windows in a VMware box).

Parallels were actually first to market and I've tried both - I've stuck with VMware since the stability issues of the 2.x days - Parallels seemed to sacrifice ultimate hypervisor-level stability for Windows gaming performance, and I don't play games, and definitely not on Windows Smiley - VMware's product was more 'professional' and, of course, had the benefit of their expertise in their existing products for Intel platforms.

So... to answer your question, yep. I could run a VM on one of my Macs. I already have a bare Ubuntu image I can clone IIRC, but I *very* rarely bother running Linux inside a VM on OS X... the Unix support of OS X is enough for Linux to be only required for tasks tailored for Linux (and hence best run natively - I'm happy to admit that Linux has a much faster kernel than OS X and is superior in *many* high-load server tasks).


However I want to run this thing on proper OS X. I don't have £20k to spend like some people, but I sure as hell plan to be buying at least £3,000 worth of Stefan's boards - this sort of investment has the potential to require the sort of babysitting that my damn 9 GH/s custom GPU frame rigs need, and I'd prefer all the infrastructure and control code to be on my favourite platform and decentralised. AFAIK, the big-iron VM solutions (with failover support for crashing servers etc.) aren't available for the Mac (since Apple don't sell servers any more!) and I'd rather not have my entire FPGA farm output dependent on virtualisation.

This is particularly pertinent because there's an off-chance I'll be using this Hackintosh sitting half-built next to me rather than my main Mac Pro workstation (the Mac has 8 old Xeon cores and 10 GB memory, the Hac has the i5-2500 and 16 GB and is 50% quicker in all but disk performance, which I'm still working on). And the stability of a Hackintosh running VMs gets deep into logic board / CPU feature support in the DSDL, and the logic board I'm using is the nightmare Asus job with the 5 PCIe slots that I originally battled to accept 5 GPUs under Linux (old thread in Hardware, regarding boards that happily ran 4 or more GPUs Smiley ) - it's not production-stable for VMs under Snow Leopard right now.
legendary
Activity: 1764
Merit: 1002
The way i cool my 1.15d boards. 120mm fan from above, 92mm from the side on the other side of the box.



I'm glad i went that route.

could you shoot another pic from that angle for the other fan?  nice setup!
donator
Activity: 305
Merit: 250
Let me see if I can help.  Will send you a PM.
brand new
Activity: 0
Merit: 250
The IR thermometers don't work very well if you point the targeting laser at a heatsink Smiley This is both due to the point of a heatsink and also the multiple pins making it hard to get a *direct* path of IR photons streaming perpendicularly from a flat part of the heatsink, IME.

However, pointing the aiming laser at the circuit board at the edge of the heatsink, or (if possible) horizontally onto the black IC die itself, tends to get more accurate results. I'm not expecting degree-level accuracy - but if the thermometer claims 80˚C then I'm assuming trouble. I've got two fans on this thing and I'm sure it'll be OK. Just wanted to know the 'comfortable' temperature range these things run at - I'm used to these crazy GPUs which run constantly for months at 90˚C...

As to progress - the hardware is ready to test but I'm getting frustrated with the software. I'll get it working - even if I work through the night - I'm a determined nutter sometimes - but it's been roadblock after roadblock attempting a Mac OS X build.

The Makefiles may have worked for Tiger with a Fink installation of legacy libraries but I'm having to write new makefiles for every component since my main machine runs Snow Leopard and has MacPorts FOSS package management. And teh ice kitteh isn't even cutting edge - I'm not making a jump to Lion since these are my production machines.... well not yet, anyway Smiley

I've written a new Makefile for the LibusbJava source and eventually built the Java class libraries successfully (I'm not a Java coder - though I've been programming for 30 years (since a kid) and have 14 years freelance systems consultancy under my belt - but I've always been a financial expert and was more interested in hedge funds than sticking to one particular tool... I prefer to use the right one for the job, and in finance it's often SQL, which I'd still take anyone on at. Macro and meta-macro processors written in Pascal though... you have to be kidding me Cheesy ). I'll send you the altered build instructions for Snow Leopard when I've got it all working.

My current problem is that the BMP macro processor won't link... as I said, Pascal isn't a language I've used in the wild so I'm not overly familiar with it, but it 'feels' structured like any other OO language. The source files will compile but they won't assemble / link. The problem is in the bmp.pas file at line 309 where a call to the CMacroBuf class (method 'insert' which takes a single parameter of type CMacroBuf) complains that the class is trying to instantiate a child using the 'create' constructor, which expects a CTextBuf parameter. There's no obvious (to me) way of casting the CMacroBuf into the CTextBuf that the 'create' constructor requires, or any obvious inheritance from CTextBuf to CMacroBuf which would allow me to pass the CTextBuf contents of the passed CMacroBuf into the method and satisfy the code. And yes, I've seen that the CMacroBuf class appears to delegate its methods from CTextBuf anyway (maybe it's proper inheritance, my opinion on which is flamebait to Comp.Sci purists so I'll keep quiet, but it'd make sense). Maybe I simply haven't got a clue about Pascal and I'm stumbling in the dark, but it's well written code (even though I like more comments, heh)...

I highly suspect that the problem is my configuration and not any bug in the code. I've built virtually all of the SDK from scratch on my Mac, having had written new Makefiles along the way and understand the wide variety of code flavours on offer (why don't you write the whole thing in Ruby, eh, Stefan? I'd like that. Ruby is nice. Every tool is written in a different language! I can't honestly believe that it's 'the right tool for the job' mentality - surely the meta-macro parser would be a classic Lisp candidate, no? Heh) - and your code is of high quality. I'm not a fan of meta-parsers since writing code is a problem in itself, and writing code to allow you to write a new dialect of code seems to be a 'now you have *two* problems' joke, but given that the macro processor (and meta-macros... FFS that's having a laugh) is in an unfamiliar language, I'm somewhat in the dark.

My money is on a clash between the expected versions of dependencies required by the ZTEX SDK and the actual versions of libraries / SDKs / etc. that I have installed on my Mac.


One polite request Stefan - could you list the actual versions of the APIs / SDKs / libraries that your SDK depends on? I wasted an hour thinking I was going to have to rewrite your Java LibUSB wrapper (and I don't like Java) because the only information on the Wiki was that the 'libusb' library was needed. Well, there are two incompatible APIs of libusb. I took a guess that due to the deprecation date of the 'old' libusb being well before your development of the ZTEX SDK, that you'd be using the current 1.0.8 version of libusb. Of course, with all functions and constants prefixed differently, making the Java wrapper work with the 'standard' libusb would require a rewrite. In fact, the libusb-compat package (aka the legacy API, no longer supported) was required and fortunately worked on my Mac.

The situation is the same with the SDCC and Free Pascal Compiler tools required to build your SDK from scratch. Perhaps I'm not looking hard enough, but the actual dependency *versions* would be REALLY helpful to people like me porting the software.


I'll try an older version of the FPC - the fact that initial 'make' results in warnings that you are using obsolete flags raises flags that the code probably only works using an older version... but which version, and whether the older version works on OS X or not, is the question. Personally, I'd rather maintain the codebase so that it's compatible with currently-maintained libraries (the legacy USB libraries may have vulnerabilities I'd rather not introduce to my system) and will send you over Snow Leopard Makefiles as soon as I've got everything working.

But if you could throw me a bone regarding the issue with compiling BMP, I'd much appreciate it.


(yeah, obviously I could already be up and running with any of the 9 Linux machines in this office... but I'm after a complete mining solution using low-power FPGAs and controlled by a low-power old Mac, just for the hell of it...)
hero member
Activity: 489
Merit: 500
Immersionist
I am currently looking into setting up a licensed production of the 1.15x over here in Hong Kong (as well as setting up a GPU farm or other options), but I have slight difficulties to acquire the Xilinx XC6SLX150-N3CSG484C.

Everything else would be ready. I have a contract manufacturer that can do smaller quantities for me standing by (I worked with them during the past 10 years a couple of times), other parts are a no-brainer, Stefan could send out the boards and license within a relative short time frame, but Xilinx/Avnet just not organized enough to actually give me a quote and take my order :/ I've had numerous phone calls and plenty of (unanswered emails) during the past few weeks. It seems over here they always expect the next Apple to call with a demand of a quadrillion units over the next few years or so. If anybody has tried to go this path or could help supplying the FPGAs please let me know via PM.

Hong Kong is not on the list of designated countries so shipping crypto hardware etc is not a problem, but in worst case I'd even come and pick them up (along with securing payment up-front of course, as I'd have to do that when ordering direct anyway). To be fair, I could actually place an order on Avnet Express anytime with a lead time of about 4 weeks, but they only have one price no matter if you buy 1 piece or 5000 pieces (no, I don't want to order 5000 pieces), and it's above the target price on which ZTEX based his math. (the FPGA seems to be considerably cheaper in Germany than in the US, which I find hard to believe).

-- // --

I only have one single 1.15x and the ambient temperature in the room is usually around 20-25C right now, but it doesn't seem like heat will be a problem. It barely gets warm underneath the FPGA/PCB.

I'll also get some Icarus this week for testing (as said, I am looking into all options including 7990 but ZTEX so far makes the best impression to me on the FPGA front).

donator
Activity: 305
Merit: 250
legendary
Activity: 1022
Merit: 1000
BitMinter
The way i cool my 1.15d boards. 120mm fan from above, 92mm from the side on the other side of the box.



I'm glad i went that route.
Pages:
Jump to: