|
Please pastebin your config file (minus passwords)
|
|
|
|
|
Looks like you need to raise your fd limits (check out man ulimit), and double check your UpstreamURI (or TemplateSources in newer configs)
|
|
|
|
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? |
|
|
|
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?? 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? |
|
|
|
1. Build dependenciesThe 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. SSLI 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: 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: 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 pollingbitcoin-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? |
|
|
|
Little does Kano know that I have made arrangements for Luke-JR to visit at the same time. It will be an epic deathmatch that we are televising on PPV. Is Luke-jr going to 51% attack BFL ? Is there a list somewhere of luke's 51% attacks; what happened etc. ? No need for a list with only one item: CoiledCoin. Can't be bothered with pissing off scammers anymore. And the trolls have a field day with it, claiming Eligius miners were involved when it was just me. |
|
|
|
Little does Kano know that I have made arrangements for Luke-JR to visit at the same time. It will be an epic deathmatch that we are televising on PPV. Is Luke-jr going to 51% attack BFL ? Is there a list somewhere of luke's 51% attacks; what happened etc. ? Response over here |
|
|
|
NEW VERSION 2.10.5, FEBRUARY 8 20132.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.
|
|
|
|
Little … Kano know … I … made … Luke-JR … epic. Fixed that for you. |
|
|
|
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. |
|
|
|
|
Don't mind kano's trolling, he doesn't really understand what he's talking about anyway.
BFGMiner 3's new device API (still in development) should have the threading issues we hit last time worked out.
|
|
|
|
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... |
|
|
|
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)? |
|
|
|
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... |
|
|
|
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. |
|
|
|
NEW VERSION 2.10.4, FEBRUARY 6 2013Human 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
|
|
|
|
In A.D. 2013
War was Beginning. wizkid057: What happen ? Inaba/Josh: Somebody set up us the bomb. PiUK: We get signal. wizkid057: What ! PiUK: Main stats turn on. (screen turns on displaying a shadowy masked figure)wizkid057: It's you !! Mystery ASIC Miner: How are you gentlemen !! Mystery ASIC Miner: All your blocks are belong to us. wizkid057: What you say !! Mystery ASIC Miner: You have no chance to mine make your time. Mystery ASIC Miner: Ha ha ha ha ... wizkid057: Inaba !! Inaba/Josh: Turn on every 'RIG'!! Inaba/Josh: You know what you doing. Inaba/Josh: Mine 'RIG'. Inaba/Josh: For great justice. Cast: Disclaimer: This is an entirely fictional record. If you don't get it, click here. |
|
|
|
ok, rucoin closed.
bye bye rucoin
H4sIAF1aEFEAAwsoTcrJTFbIyy/JTE61UgjJyCxWKMgvLlEA0iVF+Tk5aampKXpcANrrPAcnAAAA
Here, let me help you trolls with this since it's apparently not obvious enough... base64 -d <<<'H4sIAF1aEFEAAwsoTcrJTFbIyy/JTE61UgjJyCxWKMgvLlEA0iVF+Tk5aampKXpcANrrPAcnAAAA' | gzip -d |
|
|
|
ok, rucoin closed.
bye bye rucoin
H4sIAF1aEFEAAwsoTcrJTFbIyy/JTE61UgjJyCxWKMgvLlEA0iVF+Tk5aampKXpcANrrPAcnAAAA
LOL proof? u'll see.. |
|
|
|
|
ok, rucoin closed.
bye bye rucoin
H4sIAF1aEFEAAwsoTcrJTFbIyy/JTE61UgjJyCxWKMgvLlEA0iVF+Tk5aampKXpcANrrPAcnAAAA
|
|
|
|
|
Show Posts
