What am I doing wrong?
Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 12. (Read 260061 times)
January 02, 2013, 01:26:21 PM
working on getting the RPC API working, but can't get past this error:
What am I doing wrong?
What am I doing wrong?
December 27, 2012, 01:32:29 PM
Human readable changelog:
There is now a [Z]ero stats option under the display menu which resets all the visible statistics.
Very nice, I've been wanting that for awhile now. There is now a [Z]ero stats option under the display menu which resets all the visible statistics.
December 27, 2012, 12:47:32 PM
https://github.com/luke-jr/bfgminer/issues/200
Request for ability to view current FPGA clock speeds.
Also, love the more aggressive clocks for the MMQ, I've got U: 11.9/min. Pretty awesome.
Request for ability to view current FPGA clock speeds.
Also, love the more aggressive clocks for the MMQ, I've got U: 11.9/min. Pretty awesome.
December 27, 2012, 06:33:20 AM
NEW VERSION 2.10.2, DECEMBER 27 2012
Human readable changelog:
- There is now a [Z]ero stats option under the display menu which resets all the visible statistics.
- The current pool target diff is now shown in the status line like so:
Connected to mining.eligius.st diff 1 with LP as user 16kNKa7WUg8QAPFy8dJRv7USSu2fAG2pkW - The current block target diff is now shown in the status line like so:
Block: 00000599115b83cd... Diff:2.98M Started: [11:15:11] Best share: 7.73k - Block solve detection is now supported with scrypt mining as well (BLOCK! written at end of share and solved blocks listed under pool stats).
- Stratum support for scrypt mining.
- Numerous subtle bugfixes.
Full changelog
- Update documentation to include block difficulty
- Reset all stats when requested
- Reset total diff1 shares when zeroing stats as well to show correct work utility.
- Update documentation.
- Parse anything in the stratum socket if it's full without waiting. Empty the socket even if a connection is not needed in case there are share returns.
- Provide a mechanism to zero all the statistics from the menu.
- Display the current pool diff in the status line.
- Display block diff in status line.
- Generalise the code for solving a block to enable block solve detection with scrypt mining.
- Generate the output hash for scrypt as well and use the one function to set share_diff.
- Use one size for scratchbuf as a macro in scrypt.c
- Remove the unused sha224 functions.
- Check staged_rollable under staged lock, when cloning available work.
- scrypt_diff uses a uint64_t as well.
- Correct target for stratum support with scrypt mining.
- Bugfix: Ensure nonces are put in data as little-endian in test_nonce*
- Add low-level debugging info for data_buffer (some only enabled with -DDEBUG_DATABUF)
- Make all_data_cb fwrite-compliant by returning nmembs, and check for unlikely overflows
- Bugfix: Need to do extract_sockaddr before trying to initiate stratum (erroneous http URI usage, except at startup)
- Bugfix: Update last GBT work in pool_active before staging it, since otherwise it could possibly be consumed before we copy it
- Bugfix: Address Windows-specific formatting issues (including lack of support for %ll*)
- Bugfix: ztex: Correct formatting for reset failure error
- ztex: Fix formatting in a debug message
- cairnsmore: Don't bother timing dynclock detection, since there's no standard way to log it accurately
- Correct formatting in FPGA drivers
- opencl/adl: Fix formatting to fit strict rules
- Explicitly cast all_data.buf to char* for debug printing
- Follow strict time_t handling rules
- Use GNU format-checking attribute when available for applog
December 22, 2012, 10:37:04 PM
Wasn't this thread up to 26 pages? Who's comments are disappearing?
December 22, 2012, 06:53:35 PM
on a windows 7 system setup with 4ztex boards and 6 6500s i can not get any version past 2.9.1 to work
a few that i have tried crash. a few just wont load the 6500 boards
any ideas hit of changes done after 9.1 that could cause this?
let me know how i can help. time's going to be limited till after Christmas but i'll for sure do what i can to help get this figured out
So 2.9.2 fails? Can you make a debuglog?a few that i have tried crash. a few just wont load the 6500 boards
any ideas hit of changes done after 9.1 that could cause this?
let me know how i can help. time's going to be limited till after Christmas but i'll for sure do what i can to help get this figured out
Code:
bfgminer YOUR OPTIONS GO HERE --debuglog 2>debug.log
December 22, 2012, 06:44:31 PM
on a windows 7 system setup with 4ztex boards and 6 6500s i can not get any version past 2.9.1 to work
a few that i have tried crash. a few just wont load the 6500 boards
any ideas hit of changes done after 9.1 that could cause this?
let me know how i can help. time's going to be limited till after Christmas but i'll for sure do what i can to help get this figured out
a few that i have tried crash. a few just wont load the 6500 boards
any ideas hit of changes done after 9.1 that could cause this?
let me know how i can help. time's going to be limited till after Christmas but i'll for sure do what i can to help get this figured out
December 21, 2012, 03:07:54 PM
I see no reference to the new pgaset command in the documentation? How do we use this command? is it a flag we use on the executable, or one for the config file?
Looks great though!
It should be documented in the API-README file. Looks great though!
December 21, 2012, 03:03:39 PM
I see no reference to the new pgaset command in the documentation? How do we use this command? is it a flag we use on the executable, or one for the config file?
Looks great though!
Looks great though!
December 21, 2012, 12:33:04 PM
amazing
December 21, 2012, 05:01:52 AM
NEW VERSION 2.10.1, DECEMBER 21 2012
Human readable changelog:
Full changelog
Human readable changelog:
- Replaced the work-based efficiency with new bandwidth-based efficiency.
- modminer: Enable frequency adjustments up to 230 MHz, and allow changing the frequency (non-sticky) via the new "pgaset" RPC command (based on code by kano).
- Various fixes to improve portability, specifically to Mac OS X and Windows (workaround for broken libcurl builds).
- Numerous stratum fixes, including failover recovery. Also allow using stratum with scrypt.
- miner.php updates from kano
Full changelog
- libztex: fixed a typo
- libztex: check returnvalue of libusb_claim_interface() and release the interface in case of early exit
- Bugfix: submissions: Skip FD_ISSET when fd==-1 (let the next select setup deal with cleaning them out)
- Bugfix: Remove sws from write_sws list when discarding it due to pre-send stratum disconnection
- Bugfix: Shutdown stratum socket when initiate fails, so it doesn't linger
- Bugfix: Clear stratum receive buffer when initializing, in case there was extra unprocessed data in it from a previous connection
- Stop all work from the current pool if it's a stratum pool once it is disconnected since it will be invalid upon reconnecting.
- Discard all staged work from stratum pools as well as the shares upon disconnection since all the work becomes invalid.
- Use correct cbreak after 15 second delay when no pool is found alive.
- modminer: Set default clock frequency to user request so it sticks better
- modminer: Make valid frequency range consistent: 2-230
- Allow stratum to work with scrypt.
- MMQ add api pgaset for clock
- API V1.23 - new pgaset command, to be used soon
- Protect the best_share/best_diff values under control lock.
- Bugfix: modminer: Return failure to change frequency when device reports it
- opencl: Look in the right place for OpenCL library on Mac OS X
- Bugfix: AC_C_BIGENDIAN is reported to have problems, and invasive even if buried in a conditional, so don't use it
- Bugfix: Check for bswap_* first, to avoid redefinition based on other variants
- Bugfix: autoheader isn't smart enough to figure out variable defines, so use AH_TEMPLATE for each possible header
- Check a stratum pool hasn't gone dead while being a backup pool and missed having its idle flag cleared.
- Fix null pointer issue when one chip on an X6500 is not initialized yet when reading temperature.
- Hot-patch broken libcurl pkgconfig CFLAGS found in libcurl's Windows binaries
- Update OpenCL 1.2 headers from http://www.khronos.org/registry/cl/api/1.2/
- Reorganize detection of platform byteswap macros and endian to be more robust using autoconf
- Move new bandwidth-based Efficiency to status line
- Replace work-based efficiency with new bandwidth-based efficiency
- Bugfix: Pull out GBT request collapsing since it is no longer needed with new get_work main loop
- Bugfix: Free unused work when waiting on external GBT request
- README: Explicitly mention automake dependency
- README: Update AMD APP SDK URIs
- Bugfix: Free shares discarded before beginning submission
- Bugfix: Discard stratum shares waiting for a writable socket, if the pool disconnects in the meantime
- Bugfix: Always let watchpool thread handle dead pool recovery (including for stratum-only pools)
- Bugfix: Avoid lingering stratum_auth when connection is lost
- API-README explain custom page extensions in miner.php
- miner.php add a sample group pool report
- miner.php allow where,group,having on cumstom pages
- Bugfix: Hook CURLOPT_DEBUGFUNCTION to count actual bytes sent/received by libcurl
- Bugfix: Reset pool transparency_time when connecting to stratum
- Bugfix: Immediately discard shares found on disconnected stratum pools, since there is no way to submit them
- Bugfix: Decrement total_submitting when stale shares are discarded before any submission attempts
- Bugfix: Only try to compare stratum job_id for work that has a job_id (ie, ones that came from stratum)
- Bugfix: Recheck has_stratum even if the pool hasn't changed, in case pool has switched to another protocol in the process; also only delay 5 seconds before retry if pool is the same
- Bugfix: Try GBT if no pool protocol is known (can occur in the process of stratum failover to GBT)
- Bugfix: Correctly track discarded stratum shares, and log them as "disconnect" in sharelog
- Check for EWOULDBLOCK when supported in send and recv as well.
- Use the raw send() command instead of curl_easy_send since curl raw socket usage introduces random bugs on windows.
- Use raw recv() command in place of curl_easy_recv since the curl implementation introduces random bugs on windows builds when the recv fails.
- miner.php when displaying a single rig, add prev/next rig buttons if they exist, next to refresh
- miner.php allow custom page joins for STATS
- miner.php - include windows easyphp link
- driver-ztex: use the correct size for the swap array
- API stats - display pool byte transfer stats
- Pool store data transfer stats
- Benchmark incorrect work size
- ChangeLog refer to NEWS
- driver-ztex: search the complete noncerange based on the actual speed
- API-README update
- api use a dynamic io buffer, truncated before it reaches the current ~64k limit
December 16, 2012, 07:19:02 PM
Done. Is it OK to just drop links to posts here?
Yeah, that's fine. In the future, it's better to just post the issue to GitHub - it's less likely to slip my mind that way. December 16, 2012, 06:49:39 PM
Update on issue mentioned in my previous post here:
When solo mining bitcoins, miner misbehaves in a same way as with terracoins. Setup is same as above except pools are:
Pool 0 = Bitcoin server (bitcoin-qt 0.7.1)
Pool 1 = BitParking, LP using GW
Pool 2 = BTCGuild merged-mining, LP using GW
Please open a github issue with the details of this. When solo mining bitcoins, miner misbehaves in a same way as with terracoins. Setup is same as above except pools are:
Pool 0 = Bitcoin server (bitcoin-qt 0.7.1)
Pool 1 = BitParking, LP using GW
Pool 2 = BTCGuild merged-mining, LP using GW
December 16, 2012, 03:54:51 PM
Doh, should have checked the git before posting. Thanks LJR!
December 16, 2012, 03:52:31 PM
I don't want to make a github feature request until I know if this is feasible or not:
Can you make the FPGA clock setting a user-selectable setting? For example, my MMQ starts at 200mhz per card, and slowly steps up to 210mhz over the next half hour or so. it would be advantageous for me to have it automatically start at 210mhz, to avoid losing those "extra" hashes I'm not getting out of the chips at 200-210mhz. I realize this slow step-up is to avoid hardware errors and damage to the chips, but I have adequate cooling, the cards themselves never go over 35C. I'm getting my X6500s tomorrow, so I would also like to see it easily user selectable for that as well.
Is this even possible, or would this require extensive re-coding of bitstreams?
It's possible, and already has a issue: https://github.com/luke-jr/bfgminer/issues/102 Can you make the FPGA clock setting a user-selectable setting? For example, my MMQ starts at 200mhz per card, and slowly steps up to 210mhz over the next half hour or so. it would be advantageous for me to have it automatically start at 210mhz, to avoid losing those "extra" hashes I'm not getting out of the chips at 200-210mhz. I realize this slow step-up is to avoid hardware errors and damage to the chips, but I have adequate cooling, the cards themselves never go over 35C. I'm getting my X6500s tomorrow, so I would also like to see it easily user selectable for that as well.
Is this even possible, or would this require extensive re-coding of bitstreams?
December 16, 2012, 03:45:46 PM
I don't want to make a github feature request until I know if this is feasible or not:
Can you make the FPGA clock setting a user-selectable setting? For example, my MMQ starts at 200mhz per card, and slowly steps up to 210mhz over the next half hour or so. it would be advantageous for me to have it automatically start at 210mhz, to avoid losing those "extra" hashes I'm not getting out of the chips at 200-210mhz. I realize this slow step-up is to avoid hardware errors and damage to the chips, but I have adequate cooling, the cards themselves never go over 35C. I'm getting my X6500s tomorrow, so I would also like to see it easily user selectable for that as well.
Is this even possible, or would this require extensive re-coding of bitstreams?
Can you make the FPGA clock setting a user-selectable setting? For example, my MMQ starts at 200mhz per card, and slowly steps up to 210mhz over the next half hour or so. it would be advantageous for me to have it automatically start at 210mhz, to avoid losing those "extra" hashes I'm not getting out of the chips at 200-210mhz. I realize this slow step-up is to avoid hardware errors and damage to the chips, but I have adequate cooling, the cards themselves never go over 35C. I'm getting my X6500s tomorrow, so I would also like to see it easily user selectable for that as well.
Is this even possible, or would this require extensive re-coding of bitstreams?
December 16, 2012, 12:38:56 AM
I'm considering replacing the work-based efficiency displayed in BFGMiner with a bandwidth-based efficiency. Thoughts? Yay/nay?
Count on a Yay from me 
December 16, 2012, 12:31:29 AM
I'm considering replacing the work-based efficiency displayed in BFGMiner with a bandwidth-based efficiency. Thoughts? Yay/nay?
I say Yah
December 15, 2012, 10:47:21 PM
I'm considering replacing the work-based efficiency displayed in BFGMiner with a bandwidth-based efficiency. Thoughts? Yay/nay?
December 15, 2012, 01:26:03 PM
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...
Jump to: