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

[mezzomix]

I found that even with DPMS=false the screen blanker was enabled. I tried to set 'xset s noblank' and 'xset q' shows now 'prefer blanking: no'. Since I switched this parameter I did not see a single line in the log with the lower GPU frequency. Now I let the miner run and see if it is still working in 24 hours.

I have no idea why this problem did no show up with the old version.

[mezzomix]

Does it work fine if you disable --auto-gpu and --auto-fan? Finding the first version with this problem is probably crucial...

I don't know if this is working with my system (AMD E350 single chip CPU/GPU). Most of the GPU parameters are read-only. Control is very limited with this mobile chip.

[kano]

I thought it relevant to point out here since Luke-Jr is again spreading lies about his cgminer clone code - in the cgminer thread.

Firstly he made this comment

...
Feel free to make comparisons on the BFGMiner thread.

To which I replied in cgminer:
https://bitcointalk.org/index.php?topic=28402.msg1465045#msg1465045

But specifically he lied about it here in his reply to my comment (above) in cgminer:

...

Clone: Stratum code, copied from cgminer, Scrypt code, copied, GPU code, copied, pool & work scheduling, copied, API, copied, Icarus, BFL, Ztex, driver code, copied. Even the code that makes the CM1 work properly, copied.

More FUD and lies again, kano? Let's try a table:

Code	BFGMiner	cgminer
...
Icarus driver	Original	Copied, heavily modified and known buggy
...
Ztex driver	Original	Copied
...

...

Of course note the question mark he used above ... which is relevant since of course he is incorrect.

Again as usual I will actually prove what I say, rather than the usual fact that Luke-Jr just lies about this stuff all the time and never proves his lies .. since they are lies and he cannot prove them.

Firstly my answer to the Icarus lie:

Firstly note, I'll only waste my time doing this with one source file rather than spending hours sorting through it all.
This one shows so well how much bullshit his post it.

So ... I just now git cloned his clone miner to a directory on my computer

Code:

git clone https://github.com/luke-jr/bfgminer.git

and then ran this command:

Code:

git blame driver-icarus.c | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3

and the clone result right now (that anyone can run if they like) is

Code:

      5 ckolivas   
     10 Con Kolivas
    526 Kano       
    381 Luke Dashjr
    175 Xiangfu    

and in my cgminer git

Code:

      5 ckolivas     
     18 Con Kolivas  
    698 Kano         
      8 Luke Dashjr  
      3 Paul Sheppard
    180 Xiangfu      

The main changes to the clone code he copied from me (why it says he wrote more than 8 lines in the clone, but still less than me) are CM1 code
They're not in the cgminer version, the cgminer version only supports a CM1 with an Icarus bitstream and no extra CM1 commands that aren't necessary anyway - but the work division, fpga count, baud rate and timing code necessary for the CM1 were written by me.

I'll also point out that there is a file in his git called icarus-common.h that says he wrote every line - but of course I wrote most of the code in there.

i.e. in cgminer the driver-icarus.c file has ALMOST NO CODE from Luke-Jr.
He then copied FROM CGMINER to his clone and modified it and still there is more code in there written by me than by him in his clone.

But also as I point out above at the end of the quote - he has quite literally taken code I wrote and in his clone put it so that it says he wrote it - in the case of icarus-common.h
Even his git lies.

But I will also do the above again for ztex where he posted a lie again saying it was his code in the clone where in fact nelisky wrote most of it originally in cgminer:

Code:

(git blame driver-ztex.c ; git blame libztex.c ; git blame libztex.h) | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3

In this clone:

Code:

      8 ckolivas    
     92 Con Kolivas 
    168 Denis Ahrens
    160 Luke Dashjr 
    759 nelisky     
    236 Peter Stuge 

So I guess he's also trying to claim he wrote nelisky's code now - damn he lies so much.

... and BTW ... in cgminer the above numbers are:

Code:

      8 ckolivas    
    111 Con Kolivas 
    184 Denis Ahrens
      6 Kano        
     18 Luke Dashjr 
    864 nelisky     
    228 Peter Stuge

Anyone feel free to check the other lies in his cgminer table post - proving 2 above of the lies is enough for the moment.
https://bitcointalk.org/index.php?topic=28402.msg1465962#msg1465962

Code	BFGMiner	cgminer
Scrypt	Copied, known bugs	Original
getwork	Copied	Original
GBT	Original	Original, known bugsOne reported possible bug
Stratum	Copied, plus many bugfixes because of problemsproblems in his clone, not cgminer	Original
Share submission and stale detection	OriginalCopied, modified, with the share submission code recently done by Kano and ckolivas also copied	Original
RPC API	Copied, useless "features" hidden	Original
Device driver interface	Original	CopiedOriginally committed to cgminer now much modified
BFL driver	OriginalCopied	Copied, Originally committed to cgminer then heavily modified and about-to-be heavily modified again
CM1 driver	OriginalCopied (and modified) from Kano's Icarus code	Non-existent
Icarus driver	OriginalMostly Kano's Icarus code	Copied, heavily modified and known buggyOriginal - Xiangfu's original cgminer code heavily modified by Kano
ModMiner driver	Original	Copied, heavily modified and his cgminer version didn't even work until it was modified by Kano!
OpenCL driver	Copied, with minor low-level improvements	Original
X6500 driver	Original	Non-existent
Ztex driver	OriginalCopied	CopiedOriginal
VCOM USB interfaces	OS-provided with performance problems and reported device sharing problems	Custom

[Luke-Jr]

Hey Luke-Jr

Any idea why I can't log on to bitminter using stratum?
I am trying to connect using:
stratum+tcp://mint.bitminter.com:3333/
and all I get in return is
"No servers were found that could be used to get work from"

I initially tried bfgminer-2.10.* but Doc Haribo says try it with 2.9.* as it worked for him.

Went into this looking to fix some bugs, but I think it's actually a case of confusion between pool docs and miner
BitMinter's stratum is on eu1.bitminter.com, not mint.bitminter.com ; that is, stratum+tcp://eu1.bitminter.com:3333 should work (and does for me)
You can also use http://mint.bitminter.com:8332 and let BitMinter redirect you to stratum when/if they prefer it (they seem to at the moment).

[Luke-Jr]

NEW VERSION 2.10.3, JANUARY 22 2013

Human readable changelog:

• Current block display shows end of the previous block hash and (when GBT or Stratum servers are active) the next block's (that you're looking for) height.
• miner.php and RPC API updates from Kano, including multiuser support for miner.php
• Finally fix long-standing scrypt difficulty and u-hashrate calculation bugs.

Full changelog

• Revert "x6500: Whenever we get a hardware error, purge buffers just in case of read/write desync"
• Bugfix: libblkmaker: Check that zero-padding on base58check input matches output (needed to properly reject addresses with too many or too few prefix/pad '1's)
• Bugfix: Free bin2hex output in __update_block_title
• Bugfix: Allocate space for the terminating null byte on new current_hash
• Display tail end of prevblock hash rather than start+32bits
• Try to extract block height from coinbase scriptSig, when mining stratum
• Display next block height when using GBT
• Use suffixes for target-difficulty also, in share accept/reject loglines
• Bugfix: Implement common target_diff function, fixing scrypt-specific bugs in and simplifying common code shared by set_blockdiff, calc_diff, and share_diff
• Set DISPLAY to :0 by default (on non-Windows)
• Bugfix: Reset pool bytes received when zeroing stats
• miner.php trim trailing zeros on some of the STATS numbers
• Semi-Cherrypick: API stats - include pool network bytes + in miner.php
• Best Share readme
• API zero - zero statistics - all or bestshare - with optional on screen summary
• api.c pgaenable not re-enabling the device - plus related debug
• diffexactone pool diff1 used for share value calculation is ffffffff... not 100000000... :P
• miner.php user/pass fix 'usr' is readonly
• miner.php optional user/pass login restrictions
• zero (most) API stats
• Remember best share per pool and return in API pools
• ztex: precheck the secondary solutions to avoid hw errors the ztex bitstreams gives back the latest checked nonce and its hash7 value and two possible solutions.
• Bugfix: configure: if blocks require at least one command, so fill with true
• Bugfix: Only log stratum resume if it was actually "idle" before
• Zero the best share string memory when zeroing stats.
• Change the pool stratum socket buffer to new cgminer implementation, to allocate it in a grow-only fashon and reduce virtual memory fragmentation at the expense of CPU time.
• Differentiate socket full from sock full.
• Allow stratum to startup without notify but check it is valid before creating stratum work.
• Do not try to generate stratum work unless the notify command has succeeded.
• Document Mac OS X configure usage with Homebrew pkg-config path
• Clean up post-configure display of compile environment
• Bugfix: If native ncurses detection fails, print "none?" result before moving on to try AC_SEARCH_LIBS scan
• Fix more printf-format non-compatibilities
• Update windows-build.txt

[Fiyasko]

BFGminer=Total freaking ripoff of CGMiner with some personal tweaks

[crazyearner]

bug still present showing mining in GH/s and not MH/s

[Luke-Jr]

bug still present showing mining in GH/s and not MH/s

Really? I made sure to fix this in 2.10.3, and verified it by mining on some scrypt server someone on IRC let me use... :/

[mezzomix]

I found that even with DPMS=false the screen blanker was enabled. I tried to set 'xset s noblank' and 'xset q' shows now 'prefer blanking: no'. Since I switched this parameter I did not see a single line in the log with the lower GPU frequency. Now I let the miner run and see if it is still working in 24 hours.

Noblank did not help. What worked was to switch the pool (from eligius/GBT to btcguild/stratum). Now, 2.10.2 is running since 48 hours without the GPU miner threads going into the WAIT state.

[ocminer]

I have one x6500 where only one fpga works, bfgminer fails at this board giving a core dump:

 [2013-01-25 23:59:06] Probing for an alive pool
 [2013-01-25 23:59:08] Long-polling activated for http://us.eclipsemc.com:8337 (getblocktemplate)
 [2013-01-25 23:59:10] Long-polling activated for http://pit.deepbit.net:8332/listenChannel (getwork
)
 [2013-01-25 23:59:11] XBS 0.1: Flushed 1 nonces from buffer at init
 [2013-01-25 23:59:11] XBS 0.1: Frequency set to 200 MHz (range: 2-250)
 [2013-01-25 23:59:11] XBS 0: JTAG detect returned -2
 [2013-01-25 23:59:11] Thread 0 failure, exitingSegmentation Fault
root@TX1XP:~/bfgminer-2.10.2#

On my other boards it seems to work...

MPBM simply ignores the non working FPGA and runs with the resuming FPGA, can bfgminer do the same ?

[Luke-Jr]

I have one x6500 where only one fpga works, bfgminer fails at this board giving a core dump:

 [2013-01-25 23:59:06] Probing for an alive pool
 [2013-01-25 23:59:08] Long-polling activated for http://us.eclipsemc.com:8337 (getblocktemplate)
 [2013-01-25 23:59:10] Long-polling activated for http://pit.deepbit.net:8332/listenChannel (getwork
)
 [2013-01-25 23:59:11] XBS 0.1: Flushed 1 nonces from buffer at init
 [2013-01-25 23:59:11] XBS 0.1: Frequency set to 200 MHz (range: 2-250)
 [2013-01-25 23:59:11] XBS 0: JTAG detect returned -2
 [2013-01-25 23:59:11] Thread 0 failure, exitingSegmentation Fault
root@TX1XP:~/bfgminer-2.10.2#

On my other boards it seems to work...

MPBM simply ignores the non working FPGA and runs with the resuming FPGA, can bfgminer do the same ?

Looks doable. Let me see if I can figure out a way to reproduce the crash here...

[coinotron]

I'm pool operator at Coinotron.com. I recently introduced support for Stratum for an "exotic" Terracoin coin. TRC is basically BTC with few tunings. You can mine for TRC using the same miners as in case of BTC.

I have observed very strange behavior of some miners using BFGminer 2.10.2. When new block is solved by network pool creates new block template and emits it to all subscribed miners using mining.notify rpc.

The issue is: very often those BFGminer miners keep submitting shares for previous block (stales) for quite a long time (several seconds)

In example below Client 52 asks for transactions after he received mining.notify number 946, and almost 3 seconds later submits work belonging to previous block (945). 2 sec later the same situation occurs.
I'm sure that miner received mining.notify 946 message because 150ms later he asks for transactions for block template 946

Can you please look into it?

[2013-01-29 06:47:18.505] Coin: TRC, New block on network detected: 60023
[2013-01-29 06:47:18.505] Coin: TRC, BlockTemplate created: 946, For block num: 60024, in: 0ms
[2013-01-29 06:47:18.505] ClientId: 52, Outbound message: {"params": ["946", "xx", "xx", "xx", ["xx"], "xx", "xx", "xx", true], "id": null, "method": "mining.notify"}
[2013-01-29 06:47:18.646] ClientId: 52,  Inbound message: {"params": ["946"], "id": "txlist946", "method": "mining.get_transactions"}
[2013-01-29 06:47:21.391] ClientId: 52,  Inbound message: {"params": ["ClientId: 52", "945", "xx", "xx", "xx"], "id": 145, "method": "mining.submit"}
[2013-01-29 06:47:21.391] ClientId: 52, Outbound message: {"id": 145, "result": null, "error": [21, "Job not found (=stale)", null]}
[2013-01-29 06:47:23.294] ClientId: 52,  Inbound message: {"params": ["ClientId: 52", "945", "xx", "xx", "xx"], "id": 146, "method": "mining.submit"}
[2013-01-29 06:47:23.294] ClientId: 52, Outbound message: {"id": 146, "result": null, "error": [21, "Job not found (=stale)", null]}

[Luke-Jr]

I have observed very strange behavior of some miners using BFGminer 2.10.2. When new block is solved by network pool creates new block template and emits it to all subscribed miners using mining.notify rpc.

The issue is: very often those BFGminer miners keep submitting shares for previous block (stales) for quite a long time (several seconds)

In example below Client 52 asks for transactions after he received mining.notify number 946, and almost 3 seconds later submits work belonging to previous block (945). 2 sec later the same situation occurs.
I'm sure that miner received mining.notify 946 message because 150ms later he asks for transactions for block template 946

Can you please look into it?

Can you provide a test stratum URI that I can reproduce this with?

[coinotron]

Can you provide a test stratum URI that I can reproduce this with?

Yes. Just create account at coinotron.com, create worker  (type must be TRC).
Uri: coinotron.com:3333

[Luke-Jr]

FWIW, I just came across a remote buffer overflow exploit in both cgminer and BFGMiner. It's unlikely that it can be used for anything other than a pool crashing the miner program, and I will have it fixed in the next BFGMiner release. Just in case (I'm no security expert), details are only available privately to persons with a good reason to know (like Con) until the fix is released.

[twobitcoins]

To prepare for the arrival of BFL ASICs, I built bfgminer 2.10.3 and tested it for solo mining with bitcoin-qt 0.7.2.  This is a report of various issues I encountered.


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.


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.


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.


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.


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.

My personal preference is for coinbase transactions to pay public keys rather than addresses, mostly because that is how it was historically done from the days of mining directly within the bitcoin client, but I admit it is of little practical importance.  It looks like most coinbase transactions pay addresses these days.

[Luke-Jr]

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

[Epoch]

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.

[Luke-Jr]

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]

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!