Bitcoin Forum
April 28, 2024, 10:21:19 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
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 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 259842 times)
jborkl
Sr. Member
****
Offline Offline

Activity: 246
Merit: 250


Team Heritage Motorsports


View Profile WWW
December 04, 2012, 04:01:21 PM
 #461

Luke,

I have to say 2.9.4 is working very well

solo mining

over 43,000 lw with only 283 dw

Thank you for the improvement

1714299679
Hero Member
*
Offline Offline

Posts: 1714299679

View Profile Personal Message (Offline)

Ignore
1714299679
Reply with quote  #2

1714299679
Report to moderator
1714299679
Hero Member
*
Offline Offline

Posts: 1714299679

View Profile Personal Message (Offline)

Ignore
1714299679
Reply with quote  #2

1714299679
Report to moderator
1714299679
Hero Member
*
Offline Offline

Posts: 1714299679

View Profile Personal Message (Offline)

Ignore
1714299679
Reply with quote  #2

1714299679
Report to moderator
"With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714299679
Hero Member
*
Offline Offline

Posts: 1714299679

View Profile Personal Message (Offline)

Ignore
1714299679
Reply with quote  #2

1714299679
Report to moderator
1714299679
Hero Member
*
Offline Offline

Posts: 1714299679

View Profile Personal Message (Offline)

Ignore
1714299679
Reply with quote  #2

1714299679
Report to moderator
DobZombie
Hero Member
*****
Offline Offline

Activity: 896
Merit: 532


Former curator of The Bitcoin Museum


View Profile
December 04, 2012, 04:14:49 PM
 #462

Use GBT. Not only will it work better, but it's also required for --coinbase-sig to work at all.

didn't know that, now I do Smiley

Tip Me if believe BTC1 will hit $1 Million by 2030
1DobZomBiE2gngvy6zDFKY5b76yvDbqRra
jborkl
Sr. Member
****
Offline Offline

Activity: 246
Merit: 250


Team Heritage Motorsports


View Profile WWW
December 04, 2012, 04:29:03 PM
Last edit: December 04, 2012, 04:44:27 PM by jborkl
 #463

Rephrase that, Thank you for fixing the issues.  Thank you including the solo readme

donation sent,

0441e0ade497631485d254d79f053dedce5fae8a04f8a77338a2a2c1ac952d39

mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
December 08, 2012, 10:41:53 AM
 #464

Luke, I sent you a pull request for the 'best share' computation bug: https://github.com/luke-jr/bfgminer/pull/193
mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
December 08, 2012, 11:34:21 AM
 #465

subSTRATA, that is correct.

More precisely, what was happening is that for shares with a difficulty between 1 and the target, "best share" was reporting them with an incorrect difficulty due to endianness issues. (However shares with a difficulty higher than the target were properly reported.) All in all this was just a display bug. No blocks were lost.
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
December 08, 2012, 09:59:36 PM
 #466

I found the solution mrb wrote to be a bit confusing, and wanted to clean up this code anyway, so I rewrote all these functions in a hopefully more readable/understandable way for 2.10.0: bfab076d (please excuse the accidental libblkmaker change)
Since this change is pretty big, I also (now having a good understanding of the problem) wrote a very simple fix-only for 2.8.x and 2.9.x: 006faac6

Obviously this code could very easily result in lost blocks/shares if it malfunctions, so I would very much appreciate anyone familiar with C and/or block hashing and targets to review this code before I release it. At the bottom of each link, there is a place to leave comments - feel free to post your review there, or even add comments/questions inline the code if that seems more appropriate (if you put your mouse over a line, a blue "+" appears to the left of it - click that). Of course, if you don't have or want a GitHub account, feel free to email/PM/post-here any reviews as well.

Thanks,

Luke

mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
December 10, 2012, 09:54:31 AM
 #467

I was busy this weekend, but I will try to review these patches Monday.
aspirez
Newbie
*
Offline Offline

Activity: 41
Merit: 0


View Profile
December 10, 2012, 10:21:49 PM
 #468

When i try to build BFG 2.9.4 on windows i receive the following error. Someone knows how to fix that?

Code:
gcc.exe: error: @CPPFLAG_CURL_STATICLIB@: No such file or directory
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
December 10, 2012, 10:44:24 PM
 #469

When i try to build BFG 2.9.4 on windows i receive the following error. Someone knows how to fix that?

Code:
gcc.exe: error: @CPPFLAG_CURL_STATICLIB@: No such file or directory
This is a bug in your libcurl install. Find libcurl.pc and just remove that @CPPFLAG_CURL_STATICLIB@ from it entirely.

Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
December 11, 2012, 03:31:05 AM
 #470

NEW VERSION 2.9.5, DECEMBER 11 2012

Just a few minor fixes to make 2.8.8 and 2.9.5 before releasing 2.10.0 (just needs a bit more testing). Not too much to see here.

Human readable changelog:
  • Bug fixes only.

Full changelog
  • Bugfix: Copy share hash to work->hash before doing 4-byte flip required by fulltest
  • driver-ztex: libztex_setFreq() must be called before ztex_releaseFpga()
  • libztex: Make log messages say bitstream when refering to bitstreams
  • Increase FD_SETSIZE to 4096 on Windows
  • Bugfix: Use AC_PROG_CPP in libusb include subdirectory detection for improved portability
  • Bugfix: Free input memory after prioritising pools in TUI
  • Bugfix: Free filename entry for writing config file when done with it
  • Bugfix: Free stratum nonce1 before replacing it with new value on reconnect

Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
December 11, 2012, 05:44:18 AM
 #471

NEW VERSION 2.10.0, DECEMBER 11 2012

Lots of new code here, not much testing yet. I'm promoting 2.9.5 to stable and releasing this as not-yet-stable.

Human readable changelog:
  • Avoid fetching more GBT jobs when we already have a usable one, or are already in the process of getting a new one that will suffice. This drastically improves efficiency on GBT pools and reduces unnecessary bandwidth waste.
  • Share submissions are now processed asyncronously in parallel, in a single dedicated thread, instead of spawning a new thread for every submission. This makes BFGMiner scale better to bigger rigs with more shares, and enables it to react to network outages better. Additionally, a new "AS" (Active Submissions) number has been added to the status line to make it easy to see at a glance what's going on.
  • New --skip-security-checks option to allow miners to skip checks when it saves bandwidth (stratum).
  • Con's new work scheduler: The old work scheduler would spawn threads that all tried to grab work as best as they could, and this would lead to much more work than necessary being grabbed from getwork pools, and potentially hitting the pool at precisely the same time from multiple threads making a getwork failure more likely. It was also very difficult to track how much work was really available at any one time since all the threads were off doing their own thing. Centralising the work creation means it is strictly tracked now and as soon as one work item is taken, the scheduler will generate or download another one. The advantage here is to maximise the efficiency of work we get from any getwork source, be it with or without rolltime. It is also much less likely to have dips in providing work, should lead to less getwork failures, and scale to higher hashrates even with the old getwork protocols.
  • When the primary pool is stratum, GBT, or getwork in failover mode, no backup connections will be maintained to backup pools. The total number of unused stratum connections now should be extremely small.
  • Ztex driver improvements courtesy of Denis and Peter.
  • Lots of work under the hood and other minor goodies. Check full changelog.

Full changelog
  • Bugfix: Free work before replacing it with clone
  • Bugfix: Since we are using pipes for select notifier on *nix, we need to use read/write there
  • Bugfix: Winsock needs send/recv for sockets, not write/read
  • Bugfix: opencl: Initialize pc_data to avoid clean_work checking uninitialized pointers
  • Bugfix: Correct parenthesis in bind() call in Windows notifier_init
  • Include Windows error messages in notifier_init errors
  • Include prctl header for thread renaming to work.
  • Set tv_idle time if a pool is not active when input from the menu.
  • minor unlikely zero pointer test
  • BeaverCreek doesn't like BFI INT patching.
  • Only stratum pools that are idle need to be kicked via cnx_needed.
  • Do not do any setup if opt_api_listen is disabled in api.c.
  • libztex: in case the selectFpga() failed set the selected fpga to unknown
  • Only set the lagging flag for select_pool() on failed getwork if we're not in opt_fail_only mode.
  • driver-ztex: support for broken fpga on a multifpga board
  • libztex: use a function for the twice called firmware reset code
  • libztex: removed an unused struct member (ztex->valid)
  • Set the pool lagging flag on startup to avoid it being shown initially, and only unset it once the maximum number of staged work items has been reached.
  • libztex: Include compat.h for substitute libusb_error_name (on older libusb versions missing it)
  • Suppress warning about "succeeded" not being used in finish_req_in_progress for now
  • Bugfix: Always give the get_work thread a curl, regardless of other outstanding curls in use
  • Bugfix: Failover after even a single job-request failure (or else it takes too long on timeouts)
  • Bugfix: Need to remove and re-add curl easy handles from multi to start a new request
  • Access total_submitting under mutex lock to avoid any potential races, and increment it as soon as we queue the submission up
  • Just leave the submit_work thread running persistently
  • Bugfix: Restore work->pool after prepare_rpc_req since clean_work now clears it
  • Bugfix: Now that stage_work is trying to manipulate staged_work in the same thread, clone_available needs to stage it outside of its own lock
  • Make main() the getwork scheduler once everything is set up, so that all app exits use the kill_work and quit paths.
  • Set successful connect to true on auth stratum to allow summary on exit from single stratum pool.
  • Hash_pop should signal further waiters on its own pthread conditional in case there are multiple waiters.
  • Check the job_id has not changed on stratum work when deciding if the work is stale as might occur across disconnections.
  • Perform pool_resus on getwork pool that generates work in getwork_thread.
  • Set pool lagging message for getwork pool that falls to zero staged in getwork thread.
  • Stage extra work when the primary pool is a getwork pool without rolltime.
  • Do not try to clean up twice if kill message is given.
  • Only recalculate total_staged in getwork thread if required.
  • Include the correct config header in libztex and include it before other includes.
  • Implement a completely new getwork scheduler. Stage all work from the one thread, making it possible to serialise all requests minimising the number of getworks requested or local work generated. Use a pthread conditional to wake up the thread whenever work is removed to generate enough work to stay above the watermark set by opt_queue. Remove all remnants of the old queueing mechanism, deleting the now defunct queued count.
  • Bugfix: Clean up share hashing and target checks, fixing share difficulty calculation for above-target would-be-shares
  • Use templates from pool_active and longpolls without fetching more unnecessarily
  • Try to avoid requesting GBT jobs when there is already a request in progress that will likely provide sufficient work
  • Reuse most recent GBT job if in get_work_thread if it isn't stale
  • libztex: fixed some warnings and removed some whitespaces
  • Remove all references to the now unused workio_cmd structure.
  • Remove the old workio command queue thread, replacing it with a kill conditional to exit the program.
  • Remove getwork command from workio_cmd queues and do them directly from queue_request.
  • Begin tearing down the old workio command queues by removing submit commands from there and submit them asynchronously via their own threads.
  • driver-ztex: changed two pairs of malloc()/memset() to calloc()
  • libztex: Read bitstream file in 2kb blocks with simpler and faster code
  • Added the binary versions of ztex_ufm1_15d4.ihx and ztex_ufm1_15y1.ihx
  • libztex: Add firmware download support for ZTEX 1.15d and 1.15x
  • libztex: Factor out local version of libusb_get_string_descriptor_ascii()
  • libztex: Don't return error when a bitstream was already configured
  • libztex: Read bitstream file in 64kb blocks with simpler and faster code
  • libztex: Verify that the mining firmware is not a dummy firmware
  • libztex: Match mining firmware ZTEX descriptor against the dummy firmware
  • libztex: Start download sequence only after reading in the new firmware
  • libztex: Download mining firmware to all devices with dummy firmware
  • Update windows build instructions.
  • Set pool probed to true on successful authorisation with stratum to avoid it being pinged later.
  • Style changes.
  • Allow pool active to be called on stratum or disabled pools in the watchpool thread if the pool has not been probed.
  • lock (most of) the threaded statistics updates
  • README stats don't add up
  • Rearrange summary lines and include count of active submissions in progress
  • Defer submissions instead of blocking in pop_curl_entry
  • Run a single share submission thread asynchronously submitting all shares in parallel
  • Handle share submissions asynchronously, one at a time (still threaded)
  • Split up json_rpc_call so it can be used asynchronously in libcurl-multi
  • Split submit_upstream_work into _request and _completed stages, pulling out json_rpc_call
  • Bugfix: Adjust USB_* variables to new LIBUSB_* names
  • Bugfix: Avoid double-free due to realloc_strcat moving memory around
  • Bugfix: Stratum connections might be needed for share submissions up to a minute after the last time they are used to generate work
  • Bugfix: Clean work before trying to generate new stratum work on top of it
  • Bugfix: modminer: Get rid of useless usbutils include
  • Make need connection return true if a pool is idle.
  • New --skip-security-checks option to allow miners to skip checks when it saves bandwidth
  • Skip stratum transaction download when there are no transactions
  • API add Best Share to summary
  • API lock access to some summary statistics (and copy them)
  • Enable backup stratum connections for getwork when the primary pool doesn't have longpoll aka solo mining.
  • Check for correct absence of opt_fail_only in cnx_needed.
  • Remove unused variable.
  • The specification for stratum has been elaborated to say that a changed diff applies only to new work so do not retarget when submitting shares.
  • Suspend stratum connections to backup pools when there is no requirement to potentially grab work from them.
  • Rename rename_thr to RenameThread to match cgminer
  • modminer: Adopt symbolic command names from kanoi
  • Make gen_stratum_work more robust by using a dynamically allocated array for the header in case bogus data is sent by the pool to avoid overflowing a static array.
  • scrypt_diff now returns a uint64_t
  • Support monitoring and reporting much higher diffs for scrypt mining, truncating irrelevant zeroes from displayed hash.
  • Pass ostate values around in scrypt to be able to extract full hashes if needed later on.
  • Revert "Handle crash exceptions by trying to restart cgminer unless the --no-restart option is used."
  • Provide helper function realloc_strcat to extend arbitrary length arrays based on string length.
  • Use base_work for comparison just for cleanness in __copy_work
  • Remove all static work structs, using the make and free functions.
  • Add pool no. to stale share detected message.
  • Add info about which pool share became stale while resubmitting.
  • Reduce extra slots in the max backlog for ztex to minimise memory waste.
  • Get rid of unused last_work in opencl thread data.
  • Do away with the flaky free_work api in the driver code which would often lose the work data in opencl and simply flush it before exiting the opencl scanhash.
  • Minor work handling restructure, including moving some stratum data from fixed-size buffers to their own heap allocations.
  • opencl: Use new dev_error function for REASON_DEV_NOSTART
  • Provide rudimentary support for the balancing failover strategies with stratum and GBT by switching pools silently on getwork requests.
  • Convert remaining modminer and bfl uses of usleep to nmsleep.
  • Convert libztex to nmsleep where possible.
  • Convert unreliable usleep calls to nmsleep calls in ztex driver.
  • Tidy up device error counts
  • Only increase gpu engine speed by a larger step if the temperature is below hysteresis instead of increasing it to max speed.
  • Convert pool not responding and pool alive message on backup pools to verbose level only since they mean a single failed getwork.
  • Use stratum block change from backup pools as an alternative to longpoll for pools that don't support LP.
  • Round some more static string arrays to 4 byte boundaries.
  • There is no need for the static arrays to be larger than required, so long as they're 4 byte aligned to appease ARM.
  • Hash1 is only used by the CPU mining code and never changes so remove it from the work struct and bypass needing to process the value for all other mining.

mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
December 11, 2012, 07:04:00 AM
 #472

I found the solution mrb wrote to be a bit confusing, and wanted to clean up this code anyway, so I rewrote all these functions in a hopefully more readable/understandable way for 2.10.0: bfab076d (please excuse the accidental libblkmaker change)
Since this change is pretty big, I also (now having a good understanding of the problem) wrote a very simple fix-only for 2.8.x and 2.9.x: 006faac6

Obviously this code could very easily result in lost blocks/shares if it malfunctions, so I would very much appreciate anyone familiar with C and/or block hashing and targets to review this code before I release it. At the bottom of each link, there is a place to leave comments - feel free to post your review there, or even add comments/questions inline the code if that seems more appropriate (if you put your mouse over a line, a blue "+" appears to the left of it - click that). Of course, if you don't have or want a GitHub account, feel free to email/PM/post-here any reviews as well.

006faac6 looks fine.

I have not had time to review the bigger patch. I see you released 2.10.0, so I will just test it when I have time..
purelithium
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
December 14, 2012, 07:05:21 PM
Last edit: December 14, 2012, 07:20:52 PM by purelithium
 #473

Why is this not pinned anymore?

Edit: I am seeing a frustrating problem. I wonder if it is the software or the pool. I am using a new pool connected by the stratum protocol, and occasionally it will be declared as "not responding" by bfgminer. It then falls back on a backup pool, which is good. What I don't understand is why it doesn't attempt to reconnect to the higher priority stratum pool. The software appears not to re-attempt connection once it has been declared dead. The only way to force it to reconnect is to restart the software. This is frustrating when using a MMQ because it resets the clock speeds, thereby affecting overall hash rate.


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

Activity: 2576
Merit: 1186



View Profile
December 14, 2012, 07:49:29 PM
 #474

Why is this not pinned anymore?
For some reason, theymos gives trolls moderator power. Diablo-D3 has been seen abusing his more and more lately, so that's probably what happened there.

Edit: I am seeing a frustrating problem. I wonder if it is the software or the pool. I am using a new pool connected by the stratum protocol, and occasionally it will be declared as "not responding" by bfgminer. It then falls back on a backup pool, which is good. What I don't understand is why it doesn't attempt to reconnect to the higher priority stratum pool. The software appears not to re-attempt connection once it has been declared dead. The only way to force it to reconnect is to restart the software. This is frustrating when using a MMQ because it resets the clock speeds, thereby affecting overall hash rate.
Which version/branch? I'm seriously considering rewriting the work fetching code for the next version considering the number of fundamental design flaws in the code inherited from cgminer.

purelithium
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
December 14, 2012, 10:52:54 PM
 #475

Sorry, it's 2.10.0 this has been seen on two different machines running this version on win7 64bit.

Edit: pinned again! Smiley

Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
jddebug
Sr. Member
****
Offline Offline

Activity: 446
Merit: 250



View Profile
December 14, 2012, 11:02:07 PM
 #476

Awesome job with 2.10.0! I haven't tested it yet with solo mining Terracoins, but pooled mining (getwork) works flawlessly.
Issues like this one are gonne, and it seems 2.10.0 is the first version since 2.8.3 that can magically create higher accepted
rate than actual hash rate! All versions inbetween used to have problems there, with few versions returning up to 15% less
accepted shares. I have tested it over 1 week using multiple pools, and using CGMiner as well, which seems to be doing the
job noticably worse than BFGminer at this point.



On Linux using Stratum it can not recover from a pool failure and doesn't drop to backup pools either.
purelithium
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
December 15, 2012, 02:24:14 PM
 #477

subSTRATA: I've seen the dev saying before that it takes about a week of uptime for the "u" value to be accurate.

I see you've only been running that instance for 2 min, that'll happen.

Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
JakeTri
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
December 15, 2012, 02:57:44 PM
 #478

I think the litecoin stats issue is just a "display" issue ... if you go to GPU menu by pressing "G" you will see the proper stats for each GPU. Similar, if you query the stats using API you get proper stats too but the one display on the main screen are crazy high.

I suspect it is something to do with the calculation of the hash rate based on accepted shares ... I may be wrong here but the only place where the hash rate based on accepted share is displayed have this issue and all other places show proper hash rate ....

Jake

BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
December 15, 2012, 06:26:03 PM
 #479

I don't believe anyone ever opened the scrypt display issue on the GitHub issue tracker, and since it is otherwise at the bottom of the bottom of my priority list (since I don't care about scrypt), I probably won't remember to get to it otherwise... I suspect it's probably the scrypt code trying to use some other base target for "difficulty 1". Since Litecoin is a scam, I don't care what it defines to be difficulty 1 and will likely fix the bug by setting "difficulty 1" to the same value Bitcoin uses. Either way, a solution can be found sooner if someone else wants to step up to maintain the scrypt code...

Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
December 16, 2012, 03:47:21 AM
 #480

I'm considering replacing the work-based efficiency displayed in BFGMiner with a bandwidth-based efficiency. Thoughts? Yay/nay?

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 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!