Bitcoin Forum
December 11, 2016, 12:09:08 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 245147 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 03, 2012, 03:12:19 PM
 #61

NEW VERSION: 2.4.0 - May 3, 2012

Note this is an "upstream changes from CGMiner only" release.
However, since BFGMiner has had reasonably accurate Icarus hash measurement from the start, my fix in CGMiner/BFGMiner 2.4.0 makes BFGMiner as ideally accurate as reasonably possible.

This version has a fairly significant upgrade to the way networking is done, so there is a minor version number update instead of a micro version, but it has already been heavily tested.

Human readable changelog:
  • A whole networking scheduler of sorts was written for this version, designed to scale to any sized workload with the fastest networking possible, while minimising the number of connections in use, reusing them as much as possible.
  • The restart feature was added to the API to restart BFGMiner remotely.
  • If you're connected to a pool that starts rejecting every single share, BFGMiner will now automatically disable it unless you add the --no-pool-disable option.
  • Once a pool stops responding, BFGMiner won't keep trying to open a flood of extra connections.
  • Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.
  • Hashrates on FPGAs are now reasonably accurate.
  • Longpoll messages won't keep going indefinitely while a pool is down.

Full changelog:
  • Only show longpoll warning once when it has failed.
  • Convert hashes to an unsigned long long as well.
  • Detect pools that have issues represented by endless rejected shares and disable them, with a parameter to optionally disable this feature.
  • Bugfix: Use a 64-bit type for hashes_done (miner_thread) since it can overflow 32-bit on some FPGAs
  • Implement an older header fix for a label existing before the pthread_cleanup macro.
  • Limit the number of curls we recruit on communication failures and with delaynet enabled to 5 by maintaining a per-pool curl count, and using a pthread conditional that wakes up when one is returned to the ring buffer.
  • Generalise add_pool() functions since they're repeated in add_pool_details.
  • Bugfix: Return failure, rather than quit, if BFwrite fails
  • Disable failing devices such that the user can attempt to re-enable them
  • Bugfix: thread_shutdown shouldn't try to free the device, since it's needed afterward
  • API bool's and 1TBS fixes
  • Icarus - minimise code delays and name timer variables
  • api.c V1.9 add 'restart' + redesign 'quit' so thread exits cleanly
  • api.c bug - remove extra ']'s in notify command
  • Increase pool watch interval to 30 seconds.
  • Reap curls that are unused for over a minute. This allows connections to be closed, thereby allowing the number of curl handles to always be the minimum necessary to not delay networking.
  • Use the ringbuffer of curls from the same pool for submit as well as getwork threads. Since the curl handles were already connected to the same pool and are immediately available, share submission will not be delayed by getworks.
  • Implement a scaleable networking framework designed to cope with any sized network requirements, yet minimise the number of connections being reopened. Do this by create a ring buffer linked list of curl handles to be used by getwork, recruiting extra handles when none is immediately available.
  • There is no need for the submit and getwork curls to be tied to the pool struct.
  • Do not recruit extra connection threads if there have been connection errors to the pool in question.
  • We should not retry submitting shares indefinitely or we may end up with a huge backlog during network outages, so discard stale shares if we failed to submit them and they've become stale in the interim.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Hpman
Full Member
***
Offline Offline

Activity: 176



View Profile
May 04, 2012, 08:49:31 AM
 #62

Hi, I'm using ubuntu 12.04. For preparation i'm using ./configure --enable-ztex but it stops with
Code:
checking for libusb_init in -lusb-1.0... no
configure: error: Could not find usb library - please install libusb
I thought libusb is already installed per default on ubuntu ? Do i need to copy any header file in the bfgminer directory ?
I installed libsusb-dev too but it doesn't help.

Thanks Hpman
PS: BTCMiner works, i guess without libusb it would not.
libusb-dev wasn't enough, I've added  "libusb-1.0-0-dev" too and it works. Now it stops at
Code:
checking for LIBCURL... no
checking for LIBCURL... no
configure: error: Missing required libcurl dev >= 7.10.1
It seems that there is no libcurl.pc existing (for pkg-config)
curl-config --version shows  libcurl 7.22.0

Hpman

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 04, 2012, 01:40:25 PM
 #63

Code:
[quote author=Hpman link=topic=78192.msg881895#msg881895 date=1336121371]checking for LIBCURL... no
checking for LIBCURL... no
configure: error: Missing required libcurl dev >= 7.10.1
It seems that there is no libcurl.pc existing (for pkg-config)
curl-config --version shows  libcurl 7.22.0[/quote]It's part of libcurl4-gnutls-dev for Debian/Ubuntu.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 06, 2012, 02:36:12 PM
 #64

    NEW VERSION - 2.4.1, MAY 6 2012

    While Kano continues to try rewriting his own hashrate measurements for CGMiner's Icarus driver, BFGMiner's Icarus driver was already (and still is) more accurate. I did take the opportunity to give it even more specific calibration, though.

    As BFL+Icarus owners might have known, BFGMiner has worked with both devices together from the start.

    Finally, Kano recently injected RPC API code through the device driver API in CGMiner. While I made an attempt to sanitize it upstream, Con didn't merge it in time for 2.4.1; BFGMiner of course includes this cleanup, since it is important to a sane (and secure!) device driver API.

    Human readable changelog:
    • --benchmark won't crash
    • A pool will only be disabled if it rejects shares for at least 3 minutes in a row. Then it will be checked every longpoll to see if it is accepting shares, and if so, will be re-enabled.
    • More accurate hashrate on Icarus
    • Ztex quad 1.15y support
    • Extra device stats in RPC API

    Full changelog
    • Icarus: Calibrate hashrate yet even more accurately
    • In the unlikely event of finding a block, display the block solved count with the pool it came from for auditing.
    • Display the device summary on exit even if a device has been disabled.
    • Use correct pool enabled enums in api.c.
    • Import Debian packaging configs
    • Ensure we test for a pool recovering from idle so long as it's not set to disabled.
    • Fix pool number display.
    • Give BFGMiner -T message only if curses is in use.
    • Reinit_adl is no longer used.
    • API 'stats' allow devices to add their own stats also for testing/debug
    • API add getwork stats to BFGMiner - accesable from API 'stats'
    • Don't initialise variables to zero when in global scope since they're already initialised.
    • Get rid of unitialised variable warning when it's false.
    • Move a pool to POOL_REJECTING to be disabled only after 3 minutes of continuous rejected shares.
    • Some tweaks to reporting and logging.
    • API support new pool status
    • Add a temporarily disabled state for enabled pools called POOL_REJECTING and use the work from each longpoll to help determine when a rejecting pool has started working again. Switch pools based on the multipool strategy once a pool is re-enabled.
    • Removing extra debug
    • Fix the benchmark feature by bypassing the new networking code.
    • Reset sequential reject counter after a pool is disabled for when it is re-enabled.
    • ztex updateFreq was always reporting on fpga 0
    • Trying harder to get 1.15y working
    • Specifying threads on multi fpga boards extra cgpu
    • Missing the add cgpu per extra fpga on 1.15y boards
    • API add last share time to each pool
    • Don't try to reap curls if benchmarking is enabled.

    kano
    Legendary
    *
    Offline Offline

    Activity: 1932


    Linux since 1997 RedHat 4


    View Profile
    May 06, 2012, 03:24:07 PM
     #65

    Cheesy

    Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
    CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
    Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
    Hpman
    Full Member
    ***
    Offline Offline

    Activity: 176



    View Profile
    May 07, 2012, 11:32:12 AM
     #66

    Code:
    [quote author=Hpman link=topic=78192.msg881895#msg881895 date=1336121371]checking for LIBCURL... no
    checking for LIBCURL... no
    configure: error: Missing required libcurl dev >= 7.10.1
    It seems that there is no libcurl.pc existing (for pkg-config)
    curl-config --version shows  libcurl 7.22.0
    Quote
    It's part of libcurl4-gnutls-dev for Debian/Ubuntu.

    I've installed libcurl4-gnutls-dev but it doesn't help Sad, previously i used libcurl4-openssl-dev.  Is it possible that 12.04 changes the way for  version check of libcurl?

    Thanks Hpman


    kentrolla
    Hero Member
    *****
    Offline Offline

    Activity: 504


    View Profile
    May 22, 2012, 06:09:32 PM
     #67

    are there any plans to add the option to cpu mine with windows?

    Luke-Jr
    Legendary
    *
    Offline Offline

    Activity: 2100



    View Profile
    May 22, 2012, 06:19:05 PM
     #68

    are there any plans to add the option to cpu mine with windows?
    I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves?

    kentrolla
    Hero Member
    *****
    Offline Offline

    Activity: 504


    View Profile
    May 22, 2012, 08:44:46 PM
     #69

    are there any plans to add the option to cpu mine with windows?
    I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves?
    yes, my friend says he gets 30mh/s with his cpu. every little extra bit helps imo.

    Luke-Jr
    Legendary
    *
    Offline Offline

    Activity: 2100



    View Profile
    May 22, 2012, 09:10:14 PM
     #70

    are there any plans to add the option to cpu mine with windows?
    I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves?
    yes, my friend says he gets 30mh/s with his cpu. every little extra bit helps imo.
    The electricity to mine 30 MH/s with a CPU costs more than you'll get.

    kentrolla
    Hero Member
    *****
    Offline Offline

    Activity: 504


    View Profile
    May 23, 2012, 01:20:52 AM
     #71

    not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.

    kano
    Legendary
    *
    Offline Offline

    Activity: 1932


    Linux since 1997 RedHat 4


    View Profile
    May 23, 2012, 01:45:03 AM
     #72

    not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.
    If you believe that, then you would of course have no issue with buying a $100-$200 GPU that will mine bitcoins 10-50x faster than your CPUs and thus also make CPU mining pointless.

    Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
    CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
    Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
    rjk
    Sr. Member
    ****
    Offline Offline

    Activity: 420


    1ngldh


    View Profile
    May 23, 2012, 03:04:06 AM
     #73

    Also, search for pooler's fork of cpuminer. It's been better optimized than what is in cgminer' sources anyways. Maybe you will get 40 mhash/s instead of 30!

    Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
    Luke-Jr
    Legendary
    *
    Offline Offline

    Activity: 2100



    View Profile
    June 03, 2012, 04:01:51 AM
     #74

    NEW VERSION - 2.4.2, JUNE 2 2012

    This release cycle, I finally got around to cleaning up the old (from cpuminer days) "work_restart" flag array that indicated longpolls to the actual mining threads. This should have been totally uncontroversial, as it has no practical behaviour change in itself, but Con decided not to pull it in favour of a more complex and less efficient solution that probably nobody will ever care to write - too bad he didn't bring that up when I'd discussed making this change a month or so ago. As a result, cgminer and BFGMiner have drifted further apart for what I think is fair to describe as no reason whatsoever. It also means cgminer 2.4.2 doesn't have the new functionality based on that cleanup (also to blame is Kano removing epoll support from the Icarus driver in past releases): BFGMiner 2.4.2 no longer sits in a loop of "wait for data from Icarus; check if there's a longpoll; ..." on Linux, it simply sleeps the full timeout (11.2 seconds generally) and is interrupted by the operating system if the Icarus finds a share or a longpoll occurs. This might seem trivial, but should shave some small percentage off longpoll stales and improve CPU time on low-powered FPGA rigs (some of us are running their FPGAs on routers or Raspberry Pis now!).

    On the bright side, Kano finally rewrote my code (that he had removed from cgminer) to improve Icarus hashrate reporting, so I took his version over mine to bring BFGMiner closer to the cgminer codebase. I kept my more accurate Icarus timing measurements (and recalibrated them with the new code), though, so it should be just as accurate as before.

    Human readable changelog:
    • epoll is used when available (ie, just Linux) to allow Icarus reads to sleep the full duration without waking the thread, and provides faster interruption for longpolls
    • Longpoll will now finally only connect to the main pool unless you switch pools, and then it will drop the longpoll on the next block if you are still on the new pool. This should complete the rework to make cgminer have the absolute optimum number of connections open at any one time - the minimum possible while having the best hashrate, and will likely decrease the lost work across block changes. No solution to multipool+LP here was going to be perfect but this seemed the best overall to miners and pools alike.
    • The windows crash at 7 days which occurred thanks to the AMD driver screwup should be fixed. Now it will behave the way it used to behave: you'll just lose your fan monitoring once the driver is broken.
    • New Icarus code should scan more of each work item and has some hidden advanced timing options (see new readme file)
    • Saved config file when there are no GPUs should no longer be corrupt.
    • Separate READMEs for API and FPGA evolving.

    Full changelog
    • API.class compiled with Java SE 6.0_03 - works with Win7x64
    • miner.php highlight devs too slow finding shares (possibly failing)
    • API update version to V1.11 and document changes
    • API save default config file if none specified
    • api.c save success incorrectly returns error
    • api.c replace BUFSIZ (linux/windows have different values)
    • Move RPC API content out of README to API-README
    • Open a longpoll connection if a pool is in the REJECTING state as it's the only way to re-enable it automatically.
    • Use only one longpoll as much as possible by using a pthread conditional broadcast that each longpoll thread waits on and checks if it's the current pool before
    • If shares are known stale, don't use them to decide to disable a pool for sequential rejects.
    • Restarting cgminer from within after ADL has been corrupted only leads to a crash. Display a warning only and disable fanspeed monitoring.
    • Icarus: fix abort calculation/allow user specified abort
    • Icarus: make --icarus-timing hidden and document it in FPGA-README
    • Icarus: high accuracy timing and other bitstream speed support
    • add-MIPSEB-to-icarus-for-BIG_ENDIAN
    • work_decode only needs swab32 on midstate under BIG ENDIAN
    • add compile command to api-example.c
    • save config bugfix: writing an extra ',' when no gpus
    • Add dpkg-source commits

    kano
    Legendary
    *
    Offline Offline

    Activity: 1932


    Linux since 1997 RedHat 4


    View Profile
    June 03, 2012, 11:09:55 AM
     #75

    You need to update your git links to gitorious coz there's no links to the source code in the first post any more ...

    Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
    CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
    Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
    iopq
    Hero Member
    *****
    Offline Offline

    Activity: 644


    View Profile
    June 03, 2012, 11:17:01 AM
     #76

    not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.
    then buy some, it's more efficient

    so say instead of spending extra $50 on the power bill just buy $50 of bitcoins so you get 10 bitcoins instead of like 5 that you would have gotten if you were cpu mining
    this keeps the difficulty down for the rest of us

    Luke-Jr
    Legendary
    *
    Offline Offline

    Activity: 2100



    View Profile
    June 03, 2012, 02:17:57 PM
     #77

    You need to update your git links to gitorious coz there's no links to the source code in the first post any more ...
    Thanks, I pushed the latest code to GitHub. Note the tbz2/zip source links should have worked too.

    rjk
    Sr. Member
    ****
    Offline Offline

    Activity: 420


    1ngldh


    View Profile
    June 09, 2012, 06:36:35 PM
     #78

    How about some screenshot action. This is what keeps happening, and this time I decided to make a core dump of the process. The command window when I found it was not accepting button presses, so it seems that the mining process had frozen entirely. Since the U number was so low, it was obvious that the process had continued to run even after the unit stopped hashing, and froze much later - the U is normally around 11-12, and the average hash rate is normally around 865 not 675. As you can see from the screenshot, the last LP that it reported before it froze was at 13:53:09 Eastern Time, and it had stopped considerably before that although I'm not sure when. Screenshot was taken at around 14:30.

    In addition, the secondary internal red light on the BFL unit was steady on, and not blinking every 5 seconds as expected. It also was idling and not running at full burn or stuck in a loop. Normally when the machine is idle, the internal red light goes dim.

    I am not sure what the core dump contains, so I won't post it, but if Con, Kano, or Luke-Jr want to see it just ask and I will send it over.


    Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
    Luke-Jr
    Legendary
    *
    Offline Offline

    Activity: 2100



    View Profile
    June 09, 2012, 07:48:14 PM
     #79

    How about some screenshot action. This is what keeps happening, and this time I decided to make a core dump of the process. The command window when I found it was not accepting button presses, so it seems that the mining process had frozen entirely. Since the U number was so low, it was obvious that the process had continued to run even after the unit stopped hashing, and froze much later - the U is normally around 11-12, and the average hash rate is normally around 865 not 675. As you can see from the screenshot, the last LP that it reported before it froze was at 13:53:09 Eastern Time, and it had stopped considerably before that although I'm not sure when. Screenshot was taken at around 14:30.

    In addition, the secondary internal red light on the BFL unit was steady on, and not blinking every 5 seconds as expected. It also was idling and not running at full burn or stuck in a loop. Normally when the machine is idle, the internal red light goes dim.

    I am not sure what the core dump contains, so I won't post it, but if Con, Kano, or Luke-Jr want to see it just ask and I will send it over.
    This is a BitForce FPGA, correct? You can send me the core dump (I imagine it's too big for email), but I'm not sure it will be of much use since you're running on Windows - perhaps I can pick out some strings from it. It does contain all your pool login info, note.

    P_Shep
    Legendary
    *
    Offline Offline

    Activity: 924


    View Profile WWW
    June 09, 2012, 08:10:30 PM
     #80

    I'm working on something for that.
    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!