The best selling FPGA board - page 2.

rjk

sr. member

Activity: 448

Merit: 250

1ngldh

Quote from: TheSeven on March 23, 2012, 11:53:31 AM

Actually I asked several people if they could name any more cons, because I feared exactly this would happen. They couldn't come up with any either.
Hm, now that I think of it, "not supported by cgminer" might be another one...

Can you name some more cons? I'd very happily listen to that. Everyone learns from their mistakes, and the JTAG-based protocol definitely was one.
Some of the cons that I listed for the other boards were present on the x6500 rev. 2 as well, but have been fixed in rev. 3.

I'd really appreciate it if some more experts on this area (whether affiliated with one of the board vendors or not) could chime in and make a better (and neutral) comparison chart. This whould probably be taken to some wiki (http://wiki.btcfpga.com/?) though.

The only other thing I can think of is that Ztex seems to have far lower power use than any of the others. Isn't it like 8 watts for a single chip at 200Mhash? If you double that for 2 chips that makes 16 watts, which is still lower than x6500 iirc.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: BFL-Engineer on March 23, 2012, 11:45:38 AM

We are very happy to see that based on FPGA mining LLCs research,
it turns out that their products is the best that there is on the market

Good Luck,

Actually I asked several people if they could name any more cons, because I feared exactly this would happen. They couldn't come up with any either.
Hm, now that I think of it, "not supported by cgminer" might be another one...

Can you name some more cons? I'd very happily listen to that. Everyone learns from their mistakes, and the JTAG-based protocol definitely was one.
Some of the cons that I listed for the other boards were present on the x6500 rev. 2 as well, but have been fixed in rev. 3.

I'd really appreciate it if some more experts on this area (whether affiliated with one of the board vendors or not) could chime in and make a better (and neutral) comparison chart. This whould probably be taken to some wiki (http://wiki.btcfpga.com/?) though.

BFL-Engineer

full member

Activity: 227

Merit: 100

We are very happy to see that based on FPGA mining LLCs research,
it turns out that their products is the best that there is on the market

Good Luck,

rupy

hero member

Activity: 725

Merit: 503

Ah, sorry it was related to MPBM. Embarrassed

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: torusJKL on March 23, 2012, 10:01:37 AM

How does the design of X6500 rev 2 & 3 compare to the Ztex in repsect of the CPU load?

No difference between rev. 2 and rev. 3.
The kind of workload is very different between the ztex and x6500 board, on the latter it is more I/O bound, while ztex is just CPU-intensive.
I'd expect the x6500 to be slightly worse than the ztex here. In my tests 10 x6500 boards on a quadcore atom were utilizing 1.5-2 CPU cores, while 2 ztex boards were like 10-20% load on one core of a dualcore atom. This wasn't tested on the same machine, so there might be some more factors coming into play here, but I think you get a general idea of what it looks like.
IMHO this is the only drawback that the x6500 currently has, compared to the other boards, and this will definitely be redesigned in a future board revision.

Quote from: torusJKL on March 23, 2012, 10:01:37 AM

Why is the Icarus protocol better if the problem is the host side SHA256 calculation?

Because for an Icarus worker, the host will only have to calculate one SHA256 per difficulty 1 share that was found, while on the ztex it's 20 per second additionally. Also, the ztex board will need to be polled for shares every 100 milliseconds (configurable), while the Icarus board will report shares by itself via an interrupt endpoint.

torusJKL

hero member

Activity: 619

Merit: 500

Quote from: TheSeven on March 23, 2012, 09:14:08 AM

I would not call it buggy. It's by design. Java is just a lot more efficient than Python, and ztex's interface stresses this a lot. Each board worker needs to calculate about 20 SHA256 hashes per second on the host CPU, and this is currently implemented as python code, which is just generally slow for that kind of thing.
I might be able to use hashlib to improve this particular worker, but I can't use it in a lot of other places because it can't calculate midstates.
But then there's still the rather inefficient (iterating over all possible clock multipliers 10 times a second) overclocking algorithm. It could probably be optimized as well, but I'll stick with it for now for safety reasons, and to avoid unneccessary warranty/liability issues with ztex.

How does the design of X6500 rev 2 & 3 compare to the Ztex in repsect of the CPU load?
Why is the Icarus protocol better if the problem is the host side SHA256 calculation?

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: rupy on March 23, 2012, 06:53:50 AM

Quote from: TheSeven on March 23, 2012, 12:42:05 AM

Quote from: CA Coins on March 23, 2012, 12:10:12 AM

TheSeven, nice summary and thanks for working on the MPBM support for ztex.

Are you getting high CPU load for the ztex boards with MPBM? Ztex's java process doesn't use the CPU much and will run on an atom. There was a bug during firmware programming that caused high CPU loads that was fixed.

Well, I said relatively high. It's like 5-10% per board on a dualcore 1.8GHz atom, and most of that can probably be done way more efficiently in C or even Java. It's just a damn lot compared to those <1% needed by the SimpleRS232 or Icarus protocol.

No, your setup is buggy, my 5 card cluster has 0% CPU usage on D510MO Atom with Java 1.6 on Suse.

I would not call it buggy. It's by design. Java is just a lot more efficient than Python, and ztex's interface stresses this a lot. Each board worker needs to calculate about 20 SHA256 hashes per second on the host CPU, and this is currently implemented as python code, which is just generally slow for that kind of thing.
I might be able to use hashlib to improve this particular worker, but I can't use it in a lot of other places because it can't calculate midstates.
But then there's still the rather inefficient (iterating over all possible clock multipliers 10 times a second) overclocking algorithm. It could probably be optimized as well, but I'll stick with it for now for safety reasons, and to avoid unneccessary warranty/liability issues with ztex.

In any case, ztex boards need a relatively high amount of host-side calculations, which should better be done on the board's MCU (if it would be capable enough, which that EZ-USB crap probably isn't). That's what I'd call a bug. With other boards, the miner software just has to push work and gets notified if a nonce was found, which is less than 10% of the CPU usage that ztex's interface needs, usually <1% absolute (and would probably be <0.1% on your CPU, if implemented in Java).

rupy

hero member

Activity: 725

Merit: 503

Quote from: TheSeven on March 23, 2012, 12:42:05 AM

Quote from: CA Coins on March 23, 2012, 12:10:12 AM

TheSeven, nice summary and thanks for working on the MPBM support for ztex.

Are you getting high CPU load for the ztex boards with MPBM? Ztex's java process doesn't use the CPU much and will run on an atom. There was a bug during firmware programming that caused high CPU loads that was fixed.

Well, I said relatively high. It's like 5-10% per board on a dualcore 1.8GHz atom, and most of that can probably be done way more efficiently in C or even Java. It's just a damn lot compared to those <1% needed by the SimpleRS232 or Icarus protocol.

No, your setup is buggy, my 5 card cluster has 0% CPU usage on D510MO Atom with Java 1.6 on Suse.

Dhomochevsky

sr. member

Activity: 242

Merit: 251

I agree with that, it's highly subjective. For example, for me it's a con. Shipping from china is much better. Arrives in a week and some change, and I pay no duties. From the USA though it will take about 2 weeks, and I need to pay almost 50% duties.

DeepBit

donator

Activity: 532

Merit: 501

We have cookies

Quote from: TheSeven on March 22, 2012, 09:20:28 PM

Shipped from USA

It's not a pro, may be even the opposite :)

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: torusJKL on March 23, 2012, 02:28:03 AM

Quote from: TheSeven on March 22, 2012, 09:20:28 PM

X6500 Rev. 3:

Relatively high miner software CPU load due to interface design issues, will be fixed in future revisions

Is that a hardware problem that will be fixed with future revisions of the board or is it software and we can expect a fix also for rev 2 and rev 3 boards?

It's a hardware issue, but it isn't as bad as you might think. It just means running more than about 10 boards with an atom host might cause high stales.

torusJKL

hero member

Activity: 619

Merit: 500

Quote from: TheSeven on March 22, 2012, 09:20:28 PM

X6500 Rev. 3:

Relatively high miner software CPU load due to interface design issues, will be fixed in future revisions

Is that a hardware problem that will be fixed with future revisions of the board or is it software and we can expect a fix also for rev 2 and rev 3 boards?

CA Coins

donator

Activity: 305

Merit: 250

I see. Thanks for the clarification.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: CA Coins on March 23, 2012, 12:10:12 AM

TheSeven, nice summary and thanks for working on the MPBM support for ztex.

Are you getting high CPU load for the ztex boards with MPBM? Ztex's java process doesn't use the CPU much and will run on an atom. There was a bug during firmware programming that caused high CPU loads that was fixed.

Well, I said relatively high. It's like 5-10% per board on a dualcore 1.8GHz atom, and most of that can probably be done way more efficiently in C or even Java. It's just a damn lot compared to those <1% needed by the SimpleRS232 or Icarus protocol.

CA Coins

donator

Activity: 305

Merit: 250

TheSeven, nice summary and thanks for working on the MPBM support for ztex.

Are you getting high CPU load for the ztex boards with MPBM? Ztex's java process doesn't use the CPU much and will run on an atom. There was a bug during firmware programming that caused high CPU loads that was fixed.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: rjk on March 22, 2012, 09:55:54 PM

Excellent summary, TheSeven. Soon wondermine will apparently be producing his nanominer, and the projected sale price according to him fits in nicely.

Competition doesn't sleep though!

Looks like basically all other FPGA board vendors are considering backplane setups as well now, except maybe for ztex.

rjk

sr. member

Activity: 448

Merit: 250

1ngldh

Excellent summary, TheSeven. Soon wondermine will apparently be producing his nanominer, and the projected sale price according to him fits in nicely.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: Pipesnake on March 22, 2012, 08:06:47 PM

There is no "best". Considering MPBM has support for everything there is no reason they can't all play nicely together. At this point I think it all depends on what's available.

Yes, finally it has support for all of them. Even for BFL

There are definitely some pros and cons for every board. I'll try to summarize (neutrally):

BFL Single:

Excellent price/performance ratio for an FPGA board
Temperature sensors
Shipped from USA
Very high power consumption and heat dissipation for an FPGA board
High lead times
Very odd communication protocol, causes quite some inefficiencies
Completely unusable with P2Pool (>50% stales)
Overheats really easily
Not stackable

Icarus:

Lots of expansion headers and I/Os routed, thus extensible, and possibly usable for other FPGA projects
Probably the most heat robust board
Stackable
Shipped from China
Uses speed grade 2 FPGA, thus ~20-30MH/s less than the other Spartan6 boards
No heatsink mounting holes
No temperature sensors
Discontinued

X6500 Rev. 3:

Spartan 6 Speed grade 3 FPGA
Molex power connector (additionally to barrel connector)
Standard 3pin molex fan headers
Heatsink mounting holes
Temperature sensors
Fresh batch currently shipping (available at Cablesaurus)
Can be cooled by big fans from the side (low noise level)
Stackable
Shipped from USA
Relatively high miner software CPU load due to interface design issues, will be fixed in future revisions

ZTEX:

Spartan 6 Speed grade 3 FPGA
Standard 3pin molex fan headers
Low lead times
Heatsink mounting holes
Stackable
Shipped from Germany
Only a single FPGA, thus relatively high price, especially at low quantities
Relatively high miner software CPU load due to interface design issues
No temperature sensors

Pipesnake

legendary

Activity: 1012

Merit: 1000

There is no "best". Considering MPBM has support for everything there is no reason they can't all play nicely together. At this point I think it all depends on what's available.

Energizer

sr. member

Activity: 273

Merit: 250

Icarus is the best! For few simple valuable reasons:

1- It can be used as a dev board not just for mining!
2- ONLY ~20 Watts
3- The price "569$" is considered to be the lowest price as it comes fully equipped with fan/heat sink/power adapter/usb cable!
4- Zhang is always in time!

Thank you Zhang for developing such impressive boards "ICARUS" we are looking forward for your new design "Lancelot"!

Topic: The best selling FPGA board - page 2. (Read 10405 times)