The best selling FPGA board

[rjk]

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

[TheSeven]

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.

[CA Coins]

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]

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]

I see.  Thanks for the clarification.

[torusJKL]

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?

[TheSeven]

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.

[DeepBit]

Shipped from USA

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

[Dhomochevsky]

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.

[rupy]

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.

[TheSeven]

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).

[torusJKL]

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]

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.

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.

[rupy]

Ah, sorry it was related to MPBM.  

[BFL-Engineer]

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,

[TheSeven]

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.

[rjk]

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.

[P_Shep]

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,

[fizzisist]

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.

Actually, we have some power measurements here (albeit on just one board right now, so the sample size is pretty small): http://fpgamining.com/documentation/hardware/power-measurements

Turns out we're in the same ballpark: 16.4 W at 400 MH/s.

[TheSeven]

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.

Well yeah, half the power for half the hashes...

fizzisist beat me to posting the x6500 numbers, but the ztex is told to be 9.4W for 190-230MH/s.

So there isn't really all that much difference among the FPGA boards in general, except for BFL