(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64

[Luke-Jr]

Way cool - best release yet.  Got a significant improvement in my modminers hash rate and fewer errors - i run under win7 x64 and it seems to be a bit more responsive in general!

Fantastic job!

Just for some statistics gathering, are you running the new Win64 version, or the Win32?


Also looking forward to hearing any success/failure reports from OpenWrt/router users...

[RoboCoder]

Way cool - best release yet.  Got a significant improvement in my modminers hash rate and fewer errors - i run under win7 x64 and it seems to be a bit more responsive in general!

Fantastic job!

Just for some statistics gathering, are you running the new Win64 version, or the Win32?

Win64 version!

[Epoch]

Did you try compiling it per the instructions in the README?
If that doesn't work, or there's anything missing, perhaps review the OSX Rundown issue and let me know what I need to add.
If after both of these, it still doesn't work, please create a debug.log and post it somewhere with details on what the problem(s) remaining are.

Thanks, gives me a place to start. I don't need cpu/gpu support, just BFL.

[RoboCoder]

And i would like to also add that i had been having a problem on one of the modminers where BFG 2.10.2 was reporting a frequency drop after a while (when temps got a little high in the mining pit) and basically one of the modminer modules would shut itself down dropping my hashrate to about 75% of normal.

With this bitstream it hasn't happened once. 

For those running modminers - this is must do update!

[kdf]

My X6500 shows up as dead with 2.10.4 but it shows up and runs when I switch back to 2.10.3. 

Is there something I am missing?

Thanks,

[Luke-Jr]

My X6500 shows up as dead with 2.10.4 but it shows up and runs when I switch back to 2.10.3. 

Is there something I am missing?

There's no notable changes to X6500 in this release that could cause this - is it possible something else may have changed too?

Hmm, perhaps try running 2.10.4 in the 2.10.3 directory (ie, with 2.10.3 DLLs)?

[RoboCoder]

My X6500 shows up as dead with 2.10.4 but it shows up and runs when I switch back to 2.10.3. 

Is there something I am missing?

Thanks,

Did you try a hard power cycle to force a reload of the bitstream?  I did that with my couple of x6500's and they worked fine.

[purelithium]

Avg is 881ish with new modminer bit stream. However, my u: is 832ish, which is about 8-10mhash lower than before. Avg before was around 850 with a u: of 840ish. It's definitely due to higher HW errors(4900 accepted shares, 9 rejected, 364 HW errors)

any way to switch back to the old bitstream? can I just copy the bitstreams folder from a previous version?

[Luke-Jr]

Avg is 881ish with new modminer bit stream. However, my u: is 832ish, which is about 8-10mhash lower than before. Avg before was around 850 with a u: of 840ish. It's definitely due to higher HW errors(4900 accepted shares, 9 rejected, 364 HW errors)

any way to switch back to the old bitstream? can I just copy the bitstreams folder from a previous version?

I'd guess it's coincidence so far - there hasn't been enough time to really measure u-hashrate yet.

You can sortof hack it to use the old one by copying it over - replace fpgaminer_x6500-overclocker-0402.bit in 2.10.4 with fpgaminer_top_fixed7_197MHz.bit from 2.10.3. But please be careful not to get the two files confused for any future bug/debugging stuff...

[twobitcoins]

In miner.c, is template_nonce supposed to be incremented at some point?  It seems to always be zero.

[Luke-Jr]

In miner.c, is template_nonce supposed to be incremented at some point?  It seems to always be zero.

Wow, facepalm from me. You're right, this is broken.

This could have hash-wasting effects on solo mining in some cases, so I'll try to wrap up a hotfix ASAP.

[HolyScott]

Luke thank you for the X64 version.

[Luke-Jr]

NEW VERSION 2.10.5, FEBRUARY 8 2013

2.9.10 will probably be the final release of 2.9.x before 2.10.5 is promoted to stable.
If you have any problems with 2.10.5, speak now

Human readable changelog:

• Fix critical solo mining bug.

Full changelog

• Bugfix: Actually increment template_nonce when we use it
• Change file modes.
• Fix logic fail on partial writes with stratum send that was leading to corrupt message submissions.

[Luke-Jr]

1. Build dependencies

The README file mentions package names for dependencies, but in some cases I had to use different package names on Ubuntu 12.04:

• Instead of libncurses5-dev, I needed libncursesw5-dev.
• Instead of libusb-dev, I needed libusb-1.0-0-dev.

I don't know if those are errors or just a consequence of differences between distributions.

Either libncurses5 or libncursesw5 should be fine; I'm guessing you had the latter installed, which is why you needed a specific dev package. I'll update the README to mention both... as well as the libusb package name.

2. SSL

I configured bitcoin-qt for SSL using a self-signed certificate as explained at https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon, but bfgminer refused to connect due to the self-signed certificate.  At first, I fixed it by disabling certificate verification:

Code:

curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0);

Later, I copied the certificate from bitcoin-qt and told bfgminer to verify using that certificate.  I also had to disable host name verification since I am connecting by IP address:

Code:

curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0);
curl_easy_setopt(curl, CURLOPT_CAINFO, "bitcoin.cert");

Is there some standard way this is supposed to work that I'm missing?  Maybe bfgminer needs settings to control these SSL behaviors.

SSL isn't really useful for mining, and doesn't quite interact well with BFGMiner in general.
It might seem to make sense for talking directly to a bitcoind, but bitcoind does not officially support exposing the JSON-RPC port to the internet (even with SSL), so I'm not sure this is a use case that should be encouraged.

3. getblocktemplate falling back to getwork

If I stop and restart bitcoin-qt while bfgminer is running, bfgminer detects that getblocktemplate failed and falls back to getwork from that point on.  I fixed it by patching pool_protocol_fallback.  There probably needs to be a way to force the use of getblocktemplate only.

Perhaps a --no-getwork option?

4. Long polling

bitcoin-qt does not support long polling, and by default bfgminer only calls getblocktemplate every 120 seconds, resulting in an average of 60 seconds of wasted work per block, or 10% of the total work.  Without long polling, I'd prefer to call getblocktemplate more like every 5 seconds.  I tried "--expiry 5" but found that it decreases the reported hash rate substantially.  The GPU load is also significantly reduced, so the effect is real.  I haven't tracked down exactly what effect the expiry setting is having, but it should be possible to make a new call to getblocktemplate while continuing to do work based on the result of the previous call.  Or am I just not using the correct options?

I tried applying pull request 1355 to add long polling support to my bitcoin-qt.  It mostly works: hashing proceeds at full speed and new blocks are detected right away.  The long polling implementation in the pull request is not ideal though.  It only returns when a new block is found, not to update the set of transactions, so that means fewer transaction fees for the miner and slower transaction processing for everyone.  It may be better for getblocktemplate to use the same logic for long polling that it uses to decide when to call CreateNewBlock: if a new block was received or if new transactions were received and at least 5 seconds have passed since the last update.  I tried to simulate that by making getblocktemplate sleep for 5 seconds instead of waiting for a new block.  It seemed to work, and didn't have a major impact on the hash rate.  Trying to handle it on the client side with "--expiry-lp 5" had the same performance problems as "--expiry 5".

Another issue with the pull request: it prevents bitcoin-qt from shutting down promptly because the RPC thread is busy waiting for a new block.

I'll look into this... not sure on a good solution to the bitcoind LP pullreq issue :/

5. --coinbase-addr

The --coinbase-addr option uses a single address for all mined blocks.  For privacy, it would be better for every block to use a distinct address.  That would require the user to supply a pool of addresses to bfgminer, and bfgminer would need to mark them as "used" in a way that is persistent across sessions.  I think it would be a nice enhancement.

Sounds like something for after I add persistent state to BFGMiner in the future. Could you open a GitHub issue so it's not forgotten?

[kdf]

My X6500 shows up as dead with 2.10.4 but it shows up and runs when I switch back to 2.10.3. 

Is there something I am missing?

There's no notable changes to X6500 in this release that could cause this - is it possible something else may have changed too?

Hmm, perhaps try running 2.10.4 in the 2.10.3 directory (ie, with 2.10.3 DLLs)?

I copied the 2.10.4 bfgminer.exe into the 2.10.3 directory and it worked.  A hard power cycle does not change anything.  If I run 2.10.4 or 2.10.5 using the new stuff the X6500 comes up dead and it won't load.  I am not sure if this makes a difference but I am running 2 GPU's and 2 BFL FPGA and 1 x6500 on this box.  All runs fine together using the 2.10.3 DLL's with the 2.10.4 bfgminer.exe but if I use any of the newer DLL's the x6500 will not run.

ideas??

[Luke-Jr]

My X6500 shows up as dead with 2.10.4 but it shows up and runs when I switch back to 2.10.3. 

Is there something I am missing?

There's no notable changes to X6500 in this release that could cause this - is it possible something else may have changed too?

Hmm, perhaps try running 2.10.4 in the 2.10.3 directory (ie, with 2.10.3 DLLs)?

I copied the 2.10.4 bfgminer.exe into the 2.10.3 directory and it worked.  A hard power cycle does not change anything.  If I run 2.10.4 or 2.10.5 using the new stuff the X6500 comes up dead and it won't load.  I am not sure if this makes a difference but I am running 2 GPU's and 2 BFL FPGA and 1 x6500 on this box.  All runs fine together using the 2.10.3 DLL's with the 2.10.4 bfgminer.exe but if I use any of the newer DLL's the x6500 will not run.

ideas??

Any of the newer DLLs messes it up?? For example, if you use 2.10.3 libusb DLL with the rest of the DLLs 2.10.4?

[m3ta]

Back to 2.10.3 for me - with .4 and .5 I get "all devices disabled."
As I reverted back, I kept trying new/older .dll combinations. Trial and error says it's the libblkmaker.

[RoboCoder]

Back to 2.10.3 for me - with .4 and .5 I get "all devices disabled."
As I reverted back, I kept trying new/older .dll combinations. Trial and error says it's the libblkmaker.

Not sure if you are having the exact same problem, but i had those types of errors and it turned out to be because of winusb being used for the modminer devices by default. There is a utility called zadig that i saw somewhere and that allowed me to select the correct library for each device.  I should note that i am talking windows here.

If I am not completely off base with my interpretation of the problem you are having - you can try it.  It is here in case you want to download it:
http://sourceforge.net/projects/libwdi/files/zadig/

its a useful utility either way.  I do know that you have to sometime go to the options menu and select list all devices to see some.

Hope this helps..

[Luke-Jr]

5. --coinbase-addr

The --coinbase-addr option uses a single address for all mined blocks.  For privacy, it would be better for every block to use a distinct address.  That would require the user to supply a pool of addresses to bfgminer, and bfgminer would need to mark them as "used" in a way that is persistent across sessions.  I think it would be a nice enhancement.

Sounds like something for after I add persistent state to BFGMiner in the future. Could you open a GitHub issue so it's not forgotten?

On my side, with Terracoin, solo mining works without using mentioned option, and unique address is used for each solo mined block. It's like that since
Terracoin started, which means BGFMiner version around 2.8.x

Does Bitcoin works differently?

Bitcoin's GBT only provides coinbasevalue, not coinbasetxn, so the miner needs to create coinbasetxn on its own (including deciding where to pay the reward).

Back to 2.10.3 for me - with .4 and .5 I get "all devices disabled."
As I reverted back, I kept trying new/older .dll combinations. Trial and error says it's the libblkmaker.

What device? Can you confirm (starting from scratch) that 2.10.5 works if you copy ONLY the libblkmaker DLL from 2.10.3?

[RicRock]

Hello,

Using version 2.10.5 I'm getting the error below when attempting to connect to mtred and it switches to stratum.
Am I missing something in my build?

Running X6500

root@raspberrypi:~# uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux


[2013-02-10 16:04:05] Switching pool 0 http://mtred.com:8337 to stratum+tcp://mtred.com:3333
 [2013-02-10 16:04:05] JSON stratum auth failed: [
   -3,
   "Method 'get_transactions' not found for service 'mining'",
   "Traceback: <class 'stratum.custom_exceptions.MethodNotFoundException'>: Method 'get_transactions' not found for service 'mining'\n/usr/local/lib/python2.6/dist-packages/Twisted-
12.3.0-py2.6-linux-x86_64.egg/twisted/internet/posixbase.py:614:_doReadOrWrite\n/usr/local/lib/python2.6/dist-packages/Twisted-12.3.0-py2.6-linux-x86_64.egg/twisted/internet/tcp.py:
215:doRead\n/usr/local/lib/python2.6/dist-packages/Twisted-12.3.0-py2.6-linux-x86_64.egg/twisted/internet/tcp.py:221:_dataReceived\n/usr/local/lib/python2.6/dist-packages/stratum-0.
2.11-py2.6.egg/stratum/protocol.py:174:dataReceived\n--- <exception caught here> ---\n/usr/local/lib/python2.6/dist-packages/stratum-0.2.11-py2.6.egg/stratum/protocol.py:199:lineRec
eived\n/usr/local/lib/python2.6/dist-packages/stratum-0.2.11-py2.6.egg/stratum/services.py:13:_handle_event\n/usr/local/lib/python2.6/dist-packages/stratum-0.2.11-py2.6.egg/stratum/
services.py:75:call\n"
]

TIA,
Ric