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

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: TheSeven on March 06, 2012, 04:39:29 AM

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

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

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.

catfish

brand new

Activity: 0

Merit: 250

nelisky

legendary

Activity: 1540

Merit: 1002

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

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: nelisky on March 06, 2012, 05:43:05 AM

Quote from: TheSeven on March 06, 2012, 04:39:29 AM

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

legendary

Activity: 1540

Merit: 1002

Quote from: TheSeven on March 06, 2012, 04:39:29 AM

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.

nelisky

legendary

Activity: 1540

Merit: 1002

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.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: ztex on March 06, 2012, 04:04:14 AM

Quote from: TheSeven on March 05, 2012, 01:32:58 PM

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.

Quote from: ztex on March 06, 2012, 04:04:14 AM

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.

Quote from: ztex on March 06, 2012, 04:04:14 AM

Quote

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

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: TheSeven on March 05, 2012, 01:32:58 PM

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

Quote

@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

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: ztex on March 05, 2012, 05:38:06 AM

Quote from: TheSeven on March 03, 2012, 05:14:14 AM

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

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: TheSeven on March 03, 2012, 05:14:14 AM

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.

nelisky

legendary

Activity: 1540

Merit: 1002

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.

BR0KK

hero member

Activity: 784

Merit: 500

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

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: antirack on March 02, 2012, 10:40:04 PM

Job well done to get this kick started! I have downloaded your tree and tried to get it to work to no avail. It seems the fact that I am using Python 3.2.2 _may_ be the problem, since "invisible syntax" is no longer allowed with version 3. Or possibly it's because I am on Windows.

Code:

File "C:\Users\master\Modular-Python-Bitcoin-Miner\worker\fpgamining\ztexdev.py", line 187
self.checkCapability("CAPABILITY_FPGA");
^
TabError: inconsistent use of tabs and spaces in indentation

As mentioned above, I am new to many things here, including Java and Python development. At first I copy and pasted your changes and files manually into my miner files, then I installed github to clone the complete tree. Same result. I also ran into some problems finding the modules, but adding the import statement (for ztexdev with path) into ztexworker.py fixed that.

I suggest to post this on the Modular-Python-Bitcoin-Miner thread as well, makes more sens to continue this over there without creating unnecessary clutter over here.

On a more positive sidenote, I have two more ZTEX 1.15x in the mail Wink

Thanks for spotting these, I have been lazy and copied much of the code from Ztex Java and then adapted in place, leaving some cruft behind. My branch has been updated with those removed.

But I'm confused, did you get it working at all? I don't yet do python 3 (too much critical code that breaks so it will not be an easy migration) but I might start using it for this

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: ztex on March 02, 2012, 05:56:00 AM

There is an Open Source discount program: http://www.ztex.de/os_discount_program.e.html

For the implementation of ZTEX FPGA Board support for other Open Source bitcoin mining software I'm willing to give up to 100% OS discount for a single board.

But this is a lot of work because the ZTEX FPGA boards are more complex then competitor boards. Not just BTCMiner needs to be ported (host software is about 1800 lines) also a part of the SDK (host API is about 4700 lines) needs to be rewritten if another language than Java is used.

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

antirack

hero member

Activity: 489

Merit: 500

Immersionist

Quote from: nelisky on March 02, 2012, 05:53:46 PM

Quote from: antirack on March 02, 2012, 01:00:37 AM

It currently works with Icarus, X6500 and GPUs. It would be great if somebody could create a worker (or modify an existing worker) for the ZTEX board, do you have any pointers how to get started on this?

https://github.com/nelisky/Modular-Python-Bitcoin-Miner/tree/ztex

This is a very crude first attempt, many things are still missing, the devices need to be preflashed and the bitstreams must match the firmware. Only one device is supported (it does filter by serial, but then uses only the first device found) and the freq change algorithm from the error rate is much, much simpler than ztex's, and I only implemented the low speed FPGA config so far.

Next step would be multiple device suport but as I only have one currently I'm not going to blindly implement that. I might add to the code base to support more of ztex's original java source goodies ported to python, like the high speed config, but I'll be happy to pass that anyone else wanting to lend a hand.

Have fun (I'm mining on p2pool with my single ztex using this code right now).

Job well done to get this kick started! I have downloaded your tree and tried to get it to work to no avail. It seems the fact that I am using Python 3.2.2 _may_ be the problem, since "invisible syntax" is no longer allowed with version 3. Or possibly it's because I am on Windows.

Code:

File "C:\Users\master\Modular-Python-Bitcoin-Miner\worker\fpgamining\ztexdev.py", line 187
self.checkCapability("CAPABILITY_FPGA");
^
TabError: inconsistent use of tabs and spaces in indentation

As mentioned above, I am new to many things here, including Java and Python development. At first I copy and pasted your changes and files manually into my miner files, then I installed github to clone the complete tree. Same result. I also ran into some problems finding the modules, but adding the import statement (for ztexdev with path) into ztexworker.py fixed that.

I suggest to post this on the Modular-Python-Bitcoin-Miner thread as well, makes more sens to continue this over there without creating unnecessary clutter over here.

On a more positive sidenote, I have two more ZTEX 1.15x in the mail Wink

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: antirack on March 02, 2012, 01:00:37 AM

It currently works with Icarus, X6500 and GPUs. It would be great if somebody could create a worker (or modify an existing worker) for the ZTEX board, do you have any pointers how to get started on this?

https://github.com/nelisky/Modular-Python-Bitcoin-Miner/tree/ztex

This is a very crude first attempt, many things are still missing, the devices need to be preflashed and the bitstreams must match the firmware. Only one device is supported (it does filter by serial, but then uses only the first device found) and the freq change algorithm from the error rate is much, much simpler than ztex's, and I only implemented the low speed FPGA config so far.

Next step would be multiple device suport but as I only have one currently I'm not going to blindly implement that. I might add to the code base to support more of ztex's original java source goodies ported to python, like the high speed config, but I'll be happy to pass that anyone else wanting to lend a hand.

Have fun (I'm mining on p2pool with my single ztex using this code right now).

bulanula

hero member

Activity: 518

Merit: 500

Quote from: catfish

My entire network is run by my Mac Mini Server, and due to the timing and prices of *good* SSDs when I bought it (the SandForce controllers hadn't been brought out, neither the Crucial series, and the OCZ Vertex was the only performance alternative but the chipset was developed by a small, little-known firm, Indilinx IIRC), it has two Intel X25-M SSDs in RAID-0. Running a main server on 'suicide RAID' would make most sysadmins foam at the mouth, but it's different with SSDs, since their failure mode is read-only. If the SSD dies, then you can still read your data off the broken RAID and copy onto new drives. And besides, we're all backing up our servers aren't we?

Not really related to FPGA but here goes :

That is total BS mate. You need to do some research.

The main thing that dies in current SSDs is the actual controller.

Also, endurance of the NAND ( how much charge remains in the NAND cells without them being powered ) decreases as you go through the P/E cycles.

This means that if you "burn" through the cycles ( often 5000 or 3000 for 34nm and 25nm NAND ) and keep the drives powered off for like a week then no data can be recovered at all as the cells lose their charge.

The read-only SSD death is a total myth AFAIK.

When it dies, it dies.

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: ztex on March 02, 2012, 05:56:00 AM

There is an Open Source discount program: http://www.ztex.de/os_discount_program.e.html

For the implementation of ZTEX FPGA Board support for other Open Source bitcoin mining software I'm willing to give up to 100% OS discount for a single board.

But this is a lot of work because the ZTEX FPGA boards are more complex then competitor boards. Not just BTCMiner needs to be ported (host software is about 1800 lines) also a part of the SDK (host API is about 4700 lines) needs to be rewritten if another language than Java is used.

That is why I considered using MPBM. I already control my single ztex board using python, but lack firmware config atm. There are a lot of safety checks and code handling libusb oddities in ztex's sources that I'm completely ignoring, but need to go in to make this feature complete.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

There is an Open Source discount program: http://www.ztex.de/os_discount_program.e.html

For the implementation of ZTEX FPGA Board support for other Open Source bitcoin mining software I'm willing to give up to 100% OS discount for a single board.

But this is a lot of work because the ZTEX FPGA boards are more complex then competitor boards. Not just BTCMiner needs to be ported (host software is about 1800 lines) also a part of the SDK (host API is about 4700 lines) needs to be rewritten if another language than Java is used.

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