Modular Python Bitcoin Miner - Official Thread

[TheSeven]

Pulled the latest version and works without problems. Logging to the log file now also works. I can stop the miner with Ctrl-C.

Here are a couple of errors I am getting, but everything seems to work fine though.

Code:

2012-03-26 18:45:18.245000 [100]: Ztex board 04A3469722: Proxy: Exception caught: Traceback (most recent call last):
2012-03-26 18:45:18.245000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\boardproxy.py", line 75, in run
2012-03-26 18:45:18.245000 [100]:     self.device = ZtexDevice(self, self.serial, self.takeover, self.firmware)
2012-03-26 18:45:18.245000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\driver.py", line 73, in __init__
2012-03-26 18:45:18.245000 [100]:     raise Exception("Can not open the specified device, possibly because it is already in use")
2012-03-26 18:45:18.245000 [100]: Exception: Can not open the specified device, possibly because it is already in use
2012-03-26 18:45:18.245000 [100]: Ztex board 04A3469722: Traceback (most recent call last):
2012-03-26 18:45:18.245000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\ztexworker.py", line 170, in main
2012-03-26 18:45:18.245000 [100]:     elif data[0] == "dying": raise Exception("Proxy died!")
2012-03-26 18:45:18.245000 [100]: Exception: Proxy died!
2012-03-26 18:45:18.245000 [100]: 
2012-03-26 18:45:18.261000 [100]: Ztex board 04A32E00E9: Proxy: Exception caught: Traceback (most recent call last):
2012-03-26 18:45:18.261000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\boardproxy.py", line 75, in run
2012-03-26 18:45:18.261000 [100]:     self.device = ZtexDevice(self, self.serial, self.takeover, self.firmware)
2012-03-26 18:45:18.261000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\driver.py", line 73, in __init__
2012-03-26 18:45:18.261000 [100]:     raise Exception("Can not open the specified device, possibly because it is already in use")
2012-03-26 18:45:18.261000 [100]: Exception: Can not open the specified device, possibly because it is already in use
2012-03-26 18:45:18.261000 [100]: Ztex board 04A32E00E9: Traceback (most recent call last):
2012-03-26 18:45:18.261000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\ztexworker.py", line 170, in main
2012-03-26 18:45:18.261000 [100]:     elif data[0] == "dying": raise Exception("Proxy died!")
2012-03-26 18:45:18.261000 [100]: Exception: Proxy died!
2012-03-26 18:45:18.261000 [100]: 
2012-03-26 18:45:18.276000 [100]: Ztex board 04A346CEC7: Proxy: Exception caught: Traceback (most recent call last):
2012-03-26 18:45:18.276000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\boardproxy.py", line 75, in run
2012-03-26 18:45:18.276000 [100]:     self.device = ZtexDevice(self, self.serial, self.takeover, self.firmware)
2012-03-26 18:45:18.276000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\driver.py", line 73, in __init__
2012-03-26 18:45:18.276000 [100]:     raise Exception("Can not open the specified device, possibly because it is already in use")
2012-03-26 18:45:18.276000 [100]: Exception: Can not open the specified device, possibly because it is already in use
2012-03-26 18:45:18.276000 [100]: Ztex board 04A346CEC7: Traceback (most recent call last):
2012-03-26 18:45:18.276000 [100]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\ztex\ztexworker.py", line 170, in main
2012-03-26 18:45:18.276000 [100]:     elif data[0] == "dying": raise Exception("Proxy died!")
2012-03-26 18:45:18.276000 [100]: Exception: Proxy died!

This part looks like two workers are fighting for some boards, or the hotplug worker has detected boards that are currently being controlled by some other software. I need to know some more details about your configuration to figure out what exactly is going on.

Code:

2012-03-26 18:48:46.573000 [200]: ABCPool long poll failed: Traceback (most recent call last):
2012-03-26 18:48:46.573000 [200]:   File "C:\Modular-Python-Bitcoin-Miner\modules\theseven\bcjsonrpc\bcjsonrpcworksource.py", line 181, in _longpollingworker
2012-03-26 18:48:46.573000 [200]:     response = conn.getresponse()
2012-03-26 18:48:46.573000 [200]:   File "C:\python32\lib\http\client.py", line 1046, in getresponse
2012-03-26 18:48:46.573000 [200]:     response.begin()
2012-03-26 18:48:46.573000 [200]:   File "C:\python32\lib\http\client.py", line 346, in begin
2012-03-26 18:48:46.573000 [200]:     version, status, reason = self._read_status()
2012-03-26 18:48:46.573000 [200]:   File "C:\python32\lib\http\client.py", line 316, in _read_status
2012-03-26 18:48:46.573000 [200]:     raise BadStatusLine(line)
2012-03-26 18:48:46.573000 [200]: http.client.BadStatusLine: ''

That's just a dropped long poll connection from the pool (due to them restarting something?), nothing to worry about. MPBM will just reconnect it.

[antirack]

I have these longpoll errors frequently with ABCPool, so unless they are having issues at this moment I suspect there is something wrong. I didn't see it happen with the alpha version, but I don't have a log file to check.

I don't have any other miner working in the background. I just power cycled my ztex boards and reprogrammed them, still the same.

It only happens in the beginning a couple of times, but strangely not for all the boards. I just restarted MPBM and it happened 4 times in total, 3 time with with my board *C7 and only 1 time with my board *22. Not at all with my 3rd board *E9.

Edit: the ABCPool longpoll error also happens on the alpha version.


 

[coretechs]

Just upgraded the instance I was using for my X6500s.  I added the workers and pool to my config but I'm getting the following error for each board:

Code:

2012-03-25 23:28:17.791608 [100]: X6500 worker 4: Proxy: Exception caught: Traceback (most recent call last):
  File "/home/user/Modular-Python-Bitcoin-Miner2/modules/fpgamining/x6500/boardproxy.py", line 77, in run
    else: self.device = FT232R(FT232R_PyUSB(self.serial, self.takeover))
  File "/home/user/Modular-Python-Bitcoin-Miner2/modules/fpgamining/x6500/util/ft232r.py", line 309, in __init__
    import usb
ImportError: No module named usb
2012-03-25 23:28:17.792289 [100]: X6500 worker 4: Traceback (most recent call last):
  File "/home/user/Modular-Python-Bitcoin-Miner2/modules/fpgamining/x6500/x6500worker.py", line 211, in main
    elif data[0] == "dying": raise Exception("Proxy died!")
Exception: Proxy died!

Also I am unable to kill the process with ctrl-c, it just keeps getting jobs.

Did you upgrade from v0.0.4 to v0.1.0beta, or just from v0.1.0alpha (testing branch) to v0.1.0 beta?
Did you previously use the D2XX driver or PyUSB?
Have you installed PyUSB correctly for the Python version you're running MPBM on?

I upgraded from 0.0.4 by doing a git pull.  I have the D2XX driver installed (older version as recommended, though I did try a later one to rule that out) and had configured PyUSB in the past based on the guide on fpgamining.com.  When creating the workers in the new version, it automatically saves them using PyUSB even if I try to specify D2XX on the worker config.  I assume I have some configuration issue

I went back to 0.0.4 and it loads with no problems and the boards function as expected.

BTW this is running on Mint 11 (ubuntu)

[TheSeven]

I upgraded from 0.0.4 by doing a git pull.  I have the D2XX driver installed (older version as recommended, though I did try a later one to rule that out) and had configured PyUSB in the past based on the guide on fpgamining.com.  When creating the workers in the new version, it automatically saves them using PyUSB even if I try to specify D2XX on the worker config.  I assume I have some configuration issue

I went back to 0.0.4 and it loads with no problems and the boards function as expected.

BTW this is running on Mint 11 (ubuntu)

OK, I'll fix that. However it looks like this is purely a display issue, the workers should actually accept that setting, just show the wrong one when reading it back. This means that it should actually mine correctly... does it?

BTW I'd strongly recommend switching to PyUSB.

[BR0KK]

It's finally running but I'm having difficulties running more than one board. My FPGA Miner VM goes right into Bluescreen Of  Death when more than one board is connected while starting mpbm.


Could this be because all the boards use the same serial number? (While flashing them with BTCMiner for cluster mode all the boards get the same number assigned to them. Not shure how to change that back?)

I leave the donations on while I'm testing this miner btw.

[TheSeven]

urgh... ztex, WHAT THE HELL!? what's the point of a serial number!?

MPBM won't like that at all. As far as I can tell the hotplug worker will ignore all but one which have the same serial. Instantiating multiple of them manually will make all hell break loose, effectively ending up in that bluescreen (by triggering a windows or libusb bug apparently).

You'll probably have to assign them different serial numbers again. Ask ztex for instructions, I have no clue.

[antirack]

It's finally running but I'm having difficulties running more than one board. My FPGA Miner VM goes right into Bluescreen Of  Death when more than one board is connected while starting mpbm.


Could this be because all the boards use the same serial number? (While flashing them with BTCMiner for cluster mode all the boards get the same number assigned to them. Not shure how to change that back?)

I leave the donations on while I'm testing this miner btw.

What is the exact command you use the program them for cluster mode? (and you only need to do it once in their lifetime if I am not wrong)

[BR0KK]

Programming one device:
java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -f ztex_ufm1_15d2.ihx -s 01-02-01

Reprogramming that specific device:
java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -ps 01-02-01 -f ztex_ufm1_15d2.ihx

Reprogramming all devices that had been programmed with the firmware .....:
java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -pt ztex_ufm1_15d2 -f ztex_ufm1_15d2.ihx

Somewhere between these steps it must have happened...... -s is the serial number of a device (it could be anything even a name) I took one of the boards serial numbers when I tried to run this for the first time:) <--- had no clue what I was doing then.....

When I run BTCminer with the option -I i get this printout:


See .... Every board uses the same Serial number ..... I might ask Ztex how to change that.

[antirack]

Programming one device:
java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -f ztex_ufm1_15d2.ihx -s 01-02-01

Reprogramming that specific device:
java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -ps 01-02-01 -f ztex_ufm1_15d2.ihx

Reprogramming all devices that had been programmed with the firmware .....:
java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -pt ztex_ufm1_15d2 -f ztex_ufm1_15d2.ihx

Somewhere between these steps it must have happened...... -s is the serial number of a device (it could be anything even a name) I took one of the boards serial numbers when I tried to run this for the first time:) <--- had no clue what I was doing then.....

When I run BTCminer with the option -I i get this printout:
Pic is comming soon;)

You could always just copy and paste the output, no pic needed.

Can't you just unplug all your devices but one, then program with a new serial number? Rinse and repeat for all your boards. Problem fixed. I am not very experienced with the programming mode, so I can't think of any other solution for now.

[BR0KK]

I'm on an iPhone right now. Pics are easier to make  

[bitcowok]

I'm assuming a bitstream file is missing. (which is correct, i'm managing bitstreams myself)

Your assumption is correct. Just put the right bitstream there, or disable bitstream upload at all (which means you have to boot the boards manually).

Any clues as to disabling bitstream upload? (or how to configure anything at all?)

I see a "config" directory with a default.cfg which seems to be a binary format (what the?)

the old version had a config.py or similar which was nicely commented. I see no such file with this release, unless i'm missing something obvious. I'm fairly sure i've read the whole thread, and of course first post still says documentation "coming soon...". perhaps a wiki is in order?

Thanks
-bitcowok

[TheSeven]

I'm assuming a bitstream file is missing. (which is correct, i'm managing bitstreams myself)

Your assumption is correct. Just put the right bitstream there, or disable bitstream upload at all (which means you have to boot the boards manually).

Any clues as to disabling bitstream upload? (or how to configure anything at all?)

I see a "config" directory with a default.cfg which seems to be a binary format (what the?)

the old version had a config.py or similar which was nicely commented. I see no such file with this release, unless i'm missing something obvious.

There is no such thing any more. The new configuration store is a Python pickle, so that it is easily machine read/write/editable. Configuration is now done through user interface modules, currently only WebUI supports that: http://localhost:8832 (user: admin, password: mpbm)

I'm fairly sure i've read the whole thread, and of course first post still says documentation "coming soon...". perhaps a wiki is in order?

Thanks
-bitcowok

Yes, a wiki sounds like a plan. Maybe put it into http://wiki.btcfpga.com?

[O_Shovah]

Hello everybody,

As promised i release some images and data of my FPGA family at its daily work.

The setup (please excuse the messy workbench)                                                                                                                                                                

     

[From left to right: ARM board "Gumstix" (the first i developed on), Icarus(rev0),120mmfan ,x6500(rev2),120mmfan,Pandaboard ES(revB2),Bitforce single(1.0)]

And the mining data thanks to TheSeven

[macbook-air]

MPBM's support of fallback pools is the best. Any idea to make it support phatk2 video card mining?

[TheSeven]

MPBM's support of fallback pools is the best. Any idea to make it support phatk2 video card mining?

Well, in theory you should be able to rip the relevant parts of code out of poclbm or some other python gpu miner, and implant it into MPBM as a worker module. I'd figure that this should probably be an out of process worker module like ztex/x6500, to prevent GIL congestion and have some isolation to prevent a buggy GPU driver from taking down the whole MPBM instance.

[hashking]

I just recieved 3 x6500 boards and 2 of them work fine but one of them I keep getting

X6500 A4014OEH: Error while booting board: Traceback (most recent call last):
2012-03-26 16:29:52.619000:   File "worker\fpgamining\x6500.pyc", line 194, in main
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\fpga.pyc", line 83, in detect
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 90, in detect
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 331, in _readIdcodes
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 166, in read_dr
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 163, in shift_dr
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 170, in read_tdo
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\ft232r.pyc", line 203, in read_data
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\ft232r.pyc", line 163, in write
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\ft232r.pyc", line 410, in write
2012-03-26 16:29:52.619000:   File "usb\legacy.pyc", line 148, in bulkWrite
2012-03-26 16:29:52.619000:   File "usb\core.pyc", line 619, in write
2012-03-26 16:29:52.619000:   File "usb\backend\libusb01.pyc", line 474, in bulk_write
2012-03-26 16:29:52.619000:   File "usb\backend\libusb01.pyc", line 556, in __write
2012-03-26 16:29:52.619000:   File "usb\backend\libusb01.pyc", line 384, in _check
2012-03-26 16:29:52.619000: USBError: [Errno None] libusb0-dll:err [_usb_reap_async] timeout error
2012-03-26 16:29:52.619000:
2012-03-26 16:29:52.619000:

My other two work fine.
I am using Windows 7 64 bit.  Downloaded the software off of fpgamining.com.

[TheSeven]

I just recieved 3 x6500 boards and 2 of them work fine but one of them I keep getting

X6500 A4014OEH: Error while booting board: Traceback (most recent call last):
2012-03-26 16:29:52.619000:   File "worker\fpgamining\x6500.pyc", line 194, in main
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\fpga.pyc", line 83, in detect
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 90, in detect
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 331, in _readIdcodes
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 166, in read_dr
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 163, in shift_dr
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\jtag.pyc", line 170, in read_tdo
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\ft232r.pyc", line 203, in read_data
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\ft232r.pyc", line 163, in write
2012-03-26 16:29:52.619000:   File "worker\fpgamining\util\ft232r.pyc", line 410, in write
2012-03-26 16:29:52.619000:   File "usb\legacy.pyc", line 148, in bulkWrite
2012-03-26 16:29:52.619000:   File "usb\core.pyc", line 619, in write
2012-03-26 16:29:52.619000:   File "usb\backend\libusb01.pyc", line 474, in bulk_write
2012-03-26 16:29:52.619000:   File "usb\backend\libusb01.pyc", line 556, in __write
2012-03-26 16:29:52.619000:   File "usb\backend\libusb01.pyc", line 384, in _check
2012-03-26 16:29:52.619000: USBError: [Errno None] libusb0-dll:err [_usb_reap_async] timeout error
2012-03-26 16:29:52.619000:
2012-03-26 16:29:52.619000:

My other two work fine.
I am using Windows 7 64 bit.  Downloaded the software off of fpgamining.com.

Hm, USB communication trouble... Wild guess: Bad cable? Might also be all kinds of other shit though.

[hashking]

I switched the cable with one of the good ones and its the same thing.  The other 2 work great.  Once it gets going then I get this.
X6500 A4014OEL: Discovering FPGA 0...
2012-03-27 22:33:25.213000: X6500 A4014OEL: Error while booting board: Traceback (most recent call last):
2012-03-27 22:33:25.213000:   File "worker\fpgamining\x6500.pyc", line 194, in main
2012-03-27 22:33:25.213000:   File "worker\fpgamining\util\fpga.pyc", line 83, in detect
2012-03-27 22:33:25.213000:   File "worker\fpgamining\util\jtag.pyc", line 88, in detect
2012-03-27 22:33:25.213000: NoDevicesDetected

X6500 A4014OEL: Reading FPGA temperatures failed: list index out of range

[TheSeven]

I've made some packages for windows users who haven't got Python installed, see the first post.
Can somebody who doesn't have the neccessary stuff installed on his system yet please try these out?
If I test them locally, I never know if they're really self-contained or if something just picked up a library that was present on my system anyway.
Just extract both zip files to the same directory and run mpbm.exe.

Interesting... I need to check why this is happening tomorrow.
Temporary workaround: Move that dll file into c:\windows\system32 (on 32bit windows) or c:\windows\syswow64 (on 64bit windows).

[hashking]

Is this a bad board?