ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards

[BR0KK]

@catfish:

I'm a windows guy and i need the windows 7 installation for other reasons:) It runs fine with the VM Config. I did it because my unix or linux (linux hates me .... every time i install it something unexplainable happens that i myself can't fix..... which annoyes the hell out of me and i end up using windows instead) skills are not that good and i do not have a clue how to compile BTCMiner for mac osx 10.7.3.

BTW if you use Snow Leopard Server DO NOT UPGRADE Lion..... Lion Server App is crap compared to Snow leopard. Apple messed it up completely.

[1714295949]

1714295949

[nelisky]

I have updated https://github.com/nelisky/Modular-Python-Bitcoin-Miner/tree/ztex with high speed FPGA configuration (which appears to be just as slow from my tests) and multi device hotplug support, though I only tested with my single board. Anyone having multiple ztex boards and wanting to experiment with MPBM, please give this a try and let me know.

[ztex]

I wonder why you ignored my inquiry about implementing MPBM support a couple of weeks ago then...

Sorry, I did not ignored it. I read it as announcement.

[TheSeven]

I wonder why you ignored my inquiry about implementing MPBM support a couple of weeks ago then...

Sorry, I did not ignored it. I read it as announcement.

Well, I don't remember the exact wording, but I think I asked for interface documentation and possibly access to a board back then.

MPBM v0.1.x is slowly maturing, if things go very well some preview release might be released during the next week. If not, it might have to wait until some time in May (I have some exams ahead...).
Currently I have to deal with the ztex worker module as a 3rd party worker module, I can't maintain it myself because I don't have a ztex board. This means that it's likely to not work anymore in v0.1.x (which is a radical redesign).

There are 3 options now:

• Keep the ztex module as a community-maintained worker module (and hope nelisky will keep maintaining it)
• Make it an official 3rd party worker module (maintained by ztex)
• Make it a core MPBM module (maintained by me (I might need a board for that), and shipped with the official MPBM package)

@ztex: btw, does the USB core used in that cypress chip support interrupt endpoints? I'd really like to get rid of polling...

[ztex]

There are 3 options now:

• Keep the ztex module as a community-maintained worker module (and hope nelisky will keep maintaining it)
• Make it an official 3rd party worker module (maintained by ztex)
• Make it a core MPBM module (maintained by me (I might need a board for that), and shipped with the official MPBM package)

For me there is no reason to participate in development of some kind of software that does the same as BTCMiner. I will only support your software in frame of the OS discount program, see  http://www.ztex.de/os_discount_program.e.html for the conditions.

There is even a con:  ZTEX FPGA boards allow frequency scaling. Improper use of this feature may cause damage. This is mainly a warranty issue. (For that reason logging will become mandatory in the next BTCMiner release.)

@ztex: btw, does the USB core used in that cypress chip support interrupt endpoints? I'd really like to get rid of polling...

Interrupt transfers are supported by the SDK. But they (as any USB transfers) are initiated by the host, i.e. they do not avoid polling. Interrupt transfers only guarantee a certain latency.

[TheSeven]

There are 3 options now:

• Keep the ztex module as a community-maintained worker module (and hope nelisky will keep maintaining it)
• Make it an official 3rd party worker module (maintained by ztex)
• Make it a core MPBM module (maintained by me (I might need a board for that), and shipped with the official MPBM package)

For me there is no reason to participate in development of some kind of software that does the same as BTCMiner. I will only support your software in frame of the OS discount program, see  http://www.ztex.de/os_discount_program.e.html for the conditions.

This is probably a matter of personal preference, but from my perspective it might even make sense to drop BTCMiner completely at some point, and instead focus on providing a standardized interface, that any miner software can plug into, just like it works for GPUs.

But for now this basically boils down to: If I get a board, I will maintain it. If not, I can't.

There is even a con:  ZTEX FPGA boards allow frequency scaling. Improper use of this feature may cause damage. This is mainly a warranty issue. (For that reason logging will become mandatory in the next BTCMiner release.)

Sure, but that issue just can't really be avoided. The only thing that helps here is designing that feature to be at least mostly bullet proof. Doing it in the µC firmware (at least by default, if possible with thermal or current monitoring) could help as well.

@ztex: btw, does the USB core used in that cypress chip support interrupt endpoints? I'd really like to get rid of polling...

Interrupt transfers are supported by the SDK. But they (as any USB transfers) are initiated by the host, i.e. they do not avoid polling. Interrupt transfers only guarantee a certain latency.

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

[nelisky]

Is there a way to stop the FPGA from mining without forcing a reconfigure to get it going again? The use case being many boards loosing network connectivity which will make them go round and round on the same data while waiting for new work, which is wasted electricity.

[nelisky]

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

While that is true, and I guess it would be simple enough to add an interrupt transfer to signal the existence of a golden nonce to process, you would stop fetching the error rate data which, I believe, isn't something you could easily handle on the uC. And since we ztex boards allow for user controlled frequency scaling, this data is VERY important.

[TheSeven]

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

While that is true, and I guess it would be simple enough to add an interrupt transfer to signal the existence of a golden nonce to process, you would stop fetching the error rate data which, I believe, isn't something you could easily handle on the uC. And since we ztex boards allow for user controlled frequency scaling, this data is VERY important.

Isn't the error rate calculated by looking at the shares that the µC uploads to the PC? Or is there some more sophisticated self-testing mechanism on the FPGA?

[nelisky]

Every time you poll ztex board you get 2 x nonce and 2 x goldennonce. The latter is when there's a diff=1 share found and the former is just the last calculated nonce (twice because ztex uses 2 hashers in parallel, I believe).

I don't know why as it's been a while since I had to tinker with the sha256 algo, but hash(nonce)[28:32] == H7+0x5be0cd19 if the hasher is doing its thing. Ztex can set me straight if I'm full of it right now

But regardless, in a nutshell you get nonces to verify at every read, but the board verifies and stores the golden nonces itself. I am assuming that going the interrupt transfer route you would only be interested in getting transfers in the event of a golden nonce, making the error rate resolution much smaller and potentially harmful to the board.

If, on the other hand, you would get interrupt transfers for every nonce calculated... well, nothing gained from current approach, right?

I might have gotten this all wrong, so feel free to call bs.

[TheSeven]

Hm, something like that makes very much sense, but should probably be done at the firmware level. That way some kind of thermal runaway trap could be implemented on the board itself, mitigating at least some of the third party miner warranty issues. It would also reduce host to board traffic and miner CPU time a lot.

[ztex]

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

Even in larger clusters (50+) the CPU usage of BTCMiner during normal operation is almost zero. There has to be another reason (than the kind of used USB transfers).

[ztex]

Is there a way to stop the FPGA from mining without forcing a reconfigure to get it going again? The use case being many boards loosing network connectivity which will make them go round and round on the same data while waiting for new work, which is wasted electricity.

Already implemented: after about 5 minutes of inactivity the FPGA board enters a low power state. This is implemented in firmware,

But due to the support of backup servers this feature shouldn't be used much.

[ztex]

Isn't the error rate calculated by looking at the shares that the µC uploads to the PC? Or is there some more sophisticated self-testing mechanism on the FPGA?

Error rate is measured by verification of the latest hash value. Error rate measurement based on shares would be inaccurate / slow  because in average there would be only one measurement every 20s.

[ztex]

Every time you poll ztex board you get 2 x nonce and 2 x goldennonce. The latter is when there's a diff=1 share found and the former is just the last calculated nonce (twice because ztex uses 2 hashers in parallel, I believe).

In order to avoid loss if two shares are found within the poll interval the firmware stores (and returns) the previous solutions too. This is why the output is doubled.


A few word about interrupt transfers:

Interrupt transfers guarantee a certain latency, e.g. you want to see the mouse pointer moving while you are transferring data to your USB HD.

They do not generate an interrupt on the host computer. They are initiated by the host as any USB transfers, i.e. CPU time for all kind of transfers is about the same. The difference is the latency.

Latency for Bitcoin mining is not an issue:
1. because it doesn't matter if you would receive a share with a delay of 50ms
2. bandwidth is extremely low. Therefore latency is always small if only FPGA boards are connected to the USB.

[nelisky]

Is there a way to stop the FPGA from mining without forcing a reconfigure to get it going again? The use case being many boards loosing network connectivity which will make them go round and round on the same data while waiting for new work, which is wasted electricity.

Already implemented: after about 5 minutes of inactivity the FPGA board enters a low power state. This is implemented in firmware,

But due to the support of backup servers this feature shouldn't be used much.

Backup servers are fine, and they do solve the most common use case but my biggest pain is not pool downtime, rather network issues and no backup pool will help with those.

So just not sending new work to the board for 5 minutes will trigger low power sounds like a great feature, and if I want to force the FPGA to hold still I can issue a resetFpga() though that means I need to reconfigure it afterwards, correct?

[TheSeven]

A few word about interrupt transfers:

Interrupt transfers guarantee a certain latency, e.g. you want to see the mouse pointer moving while you are transferring data to your USB HD.

They do not generate an interrupt on the host computer. They are initiated by the host as any USB transfers, i.e. CPU time for all kind of transfers is about the same. The difference is the latency.

Latency for Bitcoin mining is not an issue:
1. because it doesn't matter if you would receive a share with a delay of 50ms
2. bandwidth is extremely low. Therefore latency is always small if only FPGA boards are connected to the USB.

Yes, you could do the same thing (if you don't mind about latency) with an IN BULK endpoint that NAKs all requests until there is a device-side event. Doing it with an IN INTERRUPT EP additionally guarantees that a request is sent once per frame (for bInterval = 1).
However, IIUC (and I haven't yet looked at nelisky's code in detail), the current interface requires the host software to actively poll for events because the device always responds to the transfer immediately, and not only if there was an event. That way the polling can't be offloaded to the hardware, and thus the effective latency before the miner software notices that there's a share is much higher.

And yes, latency does matter, at least for P2Pool. 100ms more total longpoll + sendshare latency = ~1% more stales.

[ztex]

So just not sending new work to the board for 5 minutes will trigger low power sounds like a great feature, and if I want to force the FPGA to hold still I can issue a resetFpga() though that means I need to reconfigure it afterwards, correct?

The ultimate low power mode is to reset the FPGA. But this also requires reconfiguration afterwards.

[SamHa1n]

[DeepBit]

HDD mounting plates ? Nice idea :)