Topic: Modular Python Bitcoin Miner - Official Thread - page 17. (Read 74189 times)

So I tried this, and it actually seemed to be sending MORE shares to my backup pool than it had previously (this was with priority set to 20 for main and 1 for backup).

With the default settings and priorities of 1000 (main) and 1 (backup), it was sending about 100Mh/s of 2000Mh/s total to my backup pool over the course of ~24 hours.

Any other ideas? Thanks.

@Theseven:

Awesome! I've got it up and running with the D2XX drivers and things look ok so far! However I'm an error that i used to get with the old X6500 as well:


Any idea on that one?

In config.py, like this:

See x6500.py for more available config options to be put there.

@TheSeven:

Thanks for the quick reply! I might try building my own WinUSB driver inf file (but we'll see how that goes). For now I think the easiest thing to do is to just use the D2XX driver (I want to test your miner over the weekend).


Edit:

If I wanted to add the FTDI D2xx line would it in:

config.py (under the workers section)

or

\workers\fpgaming\x6500.py

Thanks in advance for the help!



Cheers!

You can only install 64bit drivers on a 64bit OS, and Win7 x64 has mandantory driver signing.
You have 4 options:

• Build a WinUSB driver inf file for the device (I might do that at some point if nobody else wants to bother with it) and install a recent libusb dll that can use WinUSB.
• Find a signed libusb driver version and build a driver inf file based on that.
• Disable driver signing (BCD patch) and use an arbitrary libusb device or filter driver.
• Keep D2XX driver and set "useftd2xx": True in the worker parameters section (where the serial number is).

Here the steps I've taken so far:

I'm running:

Windows 7 64-bit

I have:

- Python 2.6.7 (32-bit) installed (
- curses-2.2.win32-py2.6.‌exe (From: http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses)
- USB module copied into MPBM folder (http://sourceforge.net/projects/pyusb/files/PyUSB%201.0/1.0.0-alpha-2/pyusb-1.0.0a2.zip/download)
- Copied the default_config.py and renamed it to config.py
- Setup the serial number for my X6500 and my pool information in the config.py

I'm at the point where I need to get libusb (from what I gather) installed. I previous had the FTDI D2XX driver (64bit) installed. Do I need to have the 32-bit drivers installed?

Excellent reply. Thanks. I intend to setup more than one, but first I'm waiting for Mr. ngzhang to deliver another fpga board. Right now I have 1 Icarus board mining with your miner. I must admit I'm a big sucker for colored terminals and I find watching the miner's output the equivalent of "seeing into the matrix"

The priority values just define how hashrate will be distributed between the pools in the long term. If one pool has two times the priority of another one, it will get twice the hashrate compared to the other one on average. The absolute values don't matter, just the relative differences do. Assuming you have one pool with priority 1000 and another one with 2000 that's the same as if the first one had priority 1 and the second one 2.

This should not make job requests fail, but if a pool has issues, these values do influence MPBM's failover behavior. It is recommended to have at least two pools with similar priority levels (let's say no more than a factor of 2 or 3 apart from each other), otherwise MPBM might try to fetch work from your primary pool too agressively during an outage, causing the work buffer to run empty before it attempts to fetch work from another pool. This is especially important if you use the bias values I have posted above to make it distribute hashrate more evenly, the default values should be a bit more tolerant here (by "punishing" pools a lot harder for failed requests or stales).
I'd recommend setting up two (or more) pools with the same priority for load balancing and failover, and if you want to, additionally the demo pool entries (at a lower priority) if you want to donate some hashrate.

In regards to this:

 "priority": 30, \

I take it the higher the number the higher the priority. And if so what is a recommended priority setting. I'm testing with BTC Guild for example, and I just kept the stock config's 30 level priority. This might be too high?? Could this explain failed job requests?

Wohoo..got it working. Just a note for those on Win 7 x64. First download and install curses mython module from here:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses


On a different note, what percent stale shares are you folks seeing?

Edit: Whoops, replied to wrong thread. But still relevant. I meant to reply to the Icarus thread.

In theory, building a WinUSB driver for the FTDI should work, libusb can nowadays use WinUSB as a backend.
I haven't got around to building such a driver yet though.

For those with Win x64, where are you getting libusb from?
 I'm basically stuck at the x6500 driver; no backend available

If your main pool behaves normally this should only happen shortly after starting the miner (or if the backup pool is incredibly lucky).
I might have to adjust some of the bias values in the default configuration to improve the startup behavior, in order to not confuse people...

You might want to try something like these:
That should make the hashrate distribution more predictable and less pool luck dependent. Use that with priority 10-20 for the main and 1 for the backup pool.

If you want it to just distribute hashrate accordingly to the priority/hashrate settings and completely ignore the pool's behavior, use this:
This will make it flood the primary pool with requests though if it's down and might end up not being able to fetch work quick enough in that situation, so this should only be used with multiple load-balanced pools at similar priority levels.

Mark.

So what's the proper way to specifiy a backup pool? I set my primary pool to a priority of '1000' and the backup to '1', yet my backup pool seems to be getting lots of shares still for some reason...

Thanks for the help coblee, got it running successfully with all 5 x6500s in one instance

When using the icarus worker, if I stop the miner and restart it, the icarus worker will fail to start with this message:


It seems like I have to disconnect and reconnect them in order for it to work again. Any ideas?

Here's the relevant part:

Weird, specifying them by serial # doesn't seem to work on my Mac. No matter what serial # I put, it seems to connect to device #0 first. The second instance then connects to device #1, and so on.

Coblee can I see what your config file looks like? Would love to only have 1 instance running.

Thanks for all the help

I have 2 x6500 workers in a single instance of MPBM on my Mac.

No idea how hotplug cannot work if single workers do, that's really weird. They both enumerate all devices on the bus, just that the single worker skips everything where the serial doesn't match, and that hotplug spawns a single worker for every serial that it finds on the bus.
But you should be able to just copy the worker definition in the config file for all 5 boards instead of running 5 MPBM instances. That's basically what hotplug would do anyway.