Bitcoin Forum
December 03, 2016, 01:57:39 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 244934 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 07, 2013, 05:18:05 AM
 #561


NEW VERSION 2.10.4, FEBRUARY 6 2013

Human readable changelog:
  • Support for most OpenWrt-compatible routers, including better big-endian compatibility. Packages are built for 12.09 "Attitude Adjustment".
  • Native 64-bit Windows port.
  • Kano's RPC example is now included as the bfgminer-rpc program.
  • Improved bitstream for ModMiners, with gains of about 10 Mh/s on average. This was originally supposed to be part of BFGMiner 2.9.2, but somehow slipped through the cracks! You'll need to power cycle your board, or use the --force-dev-init option to upload the new bitstream.
  • FPGA-README now includes a ZTEX Windows guide from Jason Snell.
  • Many bugfixes and some small improvements all over.

Full changelog
  • New platform ports: OpenWrt and Win64
  • Update official Windows build compiler and libraries:
    • Upgrade GCC from 4.6.3 to 4.7.2
    • Upgrade libusbx from 1.0.10 to 1.0.14
    • Upgrade jansson from 2.3.1 to 2.4
    • Upgrade libcurl from 7.26.0 to 7.28.1
    • Upgrade pthreads-win32 from 2.8.0 to 2.9.1
  • Bugfix: Release libudev handle when ID_MODEL doesn't match what we're looking for
  • openwrt: Script to build for multiple platforms easily
  • openwrt: Bitstreams should be "all" arch
  • Working OpenWrt Buildroot Makefile
  • Do not enable the pool disable on reject feature unless explicitly enabled with --disable-rejecting.
  • Check for calloc failure for completeness in gen_stratum_work.
  • Cache the coinbase length to speed up stratum work generation.
  • Cache the header length when generating stratum work to avoid calculating it on every work generation, and to only need one alloc+sprintf, speeding up work generation.
  • Use heap ram for coinbase in gen_stratum_work, zeroing it before use.
  • Provide a wrapper for aligning lengths of size_t to 4 byte boundaries.
  • Bugfix: ztex: While 1.15y can finish highspeed FPGA config immediately, at least 1.15x needs some delay
  • Use CURLOPT_OPENSOCKETFUNCTION to intercept the socket being created for stratum, in order to workaround CURLINFO_LASTSOCKET breakage on Win64
  • make-release: Update for Win64 and bfgminer-rpc.exe
  • Use localtime_r instead of localtime, including a Windows implementation that handles Win64's broken struct timeval.tv_sec
  • Use standard execv arg type on Win64
  • Bugfix: Correct various size mismatches
  • Ensure winsock2.h is always included before windows.h
  • Bugfix: Add necessary Winsock library to bfgminer-rpc linking
  • Bugfix: Remove dependencies of compat.h on miner.h for Windows (moves timersub/timeradd to compat.h where it belongs)
  • modminer: Raise default/maximum clocks to 210 and 250 respectively
  • modminer: Use better-performing X6500 overclocker bitstream
  • Disable libusb linkage/usage when neither X6500 nor ZTEX support is desired
  • Add support for "--scan-serial all" via simply globbing /dev
  • fpgautils: serial_autodetect implementation using sysfs
  • fpgautils: Unified serial_autodetect function to find a serial device regardless of the underlying method
  • fpgautils: Look for bitstreams in ../share/bfgminer/ too
  • Bugfix: Ensure curses library is always linked in NCURSES_LIBS, to avoid unnecessary dependencies for (non-curses) tools
  • Bugfix: GBT: work->data is always little-endian, but libblkmaker wants the nonce in native-endian
  • Bugfix: cpu: Corrections necessary to get 'c' and 'cryptopp' algorithms working on big endian
  • Bugfix: Sanity check for bits exponent in real_block_target
  • Bugfix: cpu: Increment nonce after checking (rather than before), to avoid skipping the first nonce of each scanhash call
  • cpu: via: Only swap back the nonce, rather than all data
  • cpu: Minor optimization by checking H==0 before calling fulltest
  • Bugfix: Skip yasm check when building for non-x86 platforms
  • Allow --scantime alias to --scan-time
  • Build bfgminer-rpc program from api-example.c
  • Bugfix: Remove miner.h include from api-example.c since it isn't needed and pulls in libblkmaker
  • Make wrapping consistent at 79-80 characters per line
  • Bugfix: Correct numerous misspellings, typos, etc
  • Bugfix: Prefer using a non-frozen mining thread for watchdog
  • Bugfix: x6500: Expose x6500_fpga_data even if JTAG reset/detect fail, since it is still used to store temperature info if the other FPGA initializes
  • Adding ZTEX Windows guide from Jason Snell

1480773459
Hero Member
*
Offline Offline

Posts: 1480773459

View Profile Personal Message (Offline)

Ignore
1480773459
Reply with quote  #2

1480773459
Report to moderator
1480773459
Hero Member
*
Offline Offline

Posts: 1480773459

View Profile Personal Message (Offline)

Ignore
1480773459
Reply with quote  #2

1480773459
Report to moderator
1480773459
Hero Member
*
Offline Offline

Posts: 1480773459

View Profile Personal Message (Offline)

Ignore
1480773459
Reply with quote  #2

1480773459
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480773459
Hero Member
*
Offline Offline

Posts: 1480773459

View Profile Personal Message (Offline)

Ignore
1480773459
Reply with quote  #2

1480773459
Report to moderator
1480773459
Hero Member
*
Offline Offline

Posts: 1480773459

View Profile Personal Message (Offline)

Ignore
1480773459
Reply with quote  #2

1480773459
Report to moderator
1480773459
Hero Member
*
Offline Offline

Posts: 1480773459

View Profile Personal Message (Offline)

Ignore
1480773459
Reply with quote  #2

1480773459
Report to moderator
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
February 07, 2013, 08:00:50 PM
 #562

Has anyone managed to get BFGMiner running under OSX Mountain Lion? I'm sure it will run in Parallels, but I'm hoping there's a way to avoid that.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 07, 2013, 08:35:17 PM
 #563

Has anyone managed to get BFGMiner running under OSX Mountain Lion? I'm sure it will run in Parallels, but I'm hoping there's a way to avoid that.
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.

RoboCoder
Sr. Member
****
Offline Offline

Activity: 387


Save A Life, Adopt a Pet Today!


View Profile WWW
February 07, 2013, 08:38:23 PM
 #564

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!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 07, 2013, 08:43:57 PM
 #565

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
Sr. Member
****
Offline Offline

Activity: 387


Save A Life, Adopt a Pet Today!


View Profile WWW
February 07, 2013, 08:46:10 PM
 #566

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
Legendary
*
Offline Offline

Activity: 917



View Profile
February 07, 2013, 08:46:27 PM
 #567

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
RoboCoder
Sr. Member
****
Offline Offline

Activity: 387


Save A Life, Adopt a Pet Today!


View Profile WWW
February 07, 2013, 08:50:26 PM
 #568

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
Jr. Member
*
Offline Offline

Activity: 35


View Profile
February 07, 2013, 11:23:22 PM
 #569

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 08, 2013, 12:06:33 AM
 #570

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
Sr. Member
****
Offline Offline

Activity: 387


Save A Life, Adopt a Pet Today!


View Profile WWW
February 08, 2013, 01:35:37 AM
 #571

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
Hero Member
*****
Offline Offline

Activity: 504



View Profile
February 08, 2013, 01:47:06 AM
 #572

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?


Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 08, 2013, 02:04:26 AM
 #573

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
Full Member
***
Offline Offline

Activity: 144


View Profile
February 08, 2013, 02:37:01 AM
 #574

In miner.c, is template_nonce supposed to be incremented at some point?  It seems to always be zero.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 08, 2013, 02:55:51 AM
 #575

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

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

HolyScott
Full Member
***
Offline Offline

Activity: 160



View Profile WWW
February 08, 2013, 04:05:39 AM
 #576

Luke thank you for the X64 version.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 08, 2013, 07:15:07 AM
 #577

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 Tongue

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 08, 2013, 08:53:36 PM
 #578

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
Jr. Member
*
Offline Offline

Activity: 35


View Profile
February 08, 2013, 09:09:26 PM
 #579

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 08, 2013, 09:30:30 PM
 #580

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?

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!