BFGMiner's "prime" branch seems to work, at 2000pps for me (on a system that primecoind was doing well under 100pps on, unoptimized). It's not user friendly, and not intended to be easy to use, as it's still in development. I'm not sure if I'm going to finish it, as I'm pretty sure Primecoin is a scamcoin - but maybe if others want to join in the development we can share the bounty?  Basically it mostly just needs cleanup at this point. |
|
|
|
NEW VERSION 3.1.3, JULY 11 2013Special thanks to iongchun for bisecting, debugging, and fixing the 100% CPU issue. Human readable changelog:- Fix 100% CPU usage hang with GBT/getwork pools.
- Make staged work underrun detection less overly aggressive.
- Generate baud rate list from OS on *nix (fixes Mac/BSD build).
Full changelog- Bugfix: Reset staged_full flag when discarding (stale) popped work, or increasing the queue minimum
- Bugfix: Only trigger staged work underrun if a mining thread was actually waiting for it (and do so sooner, before it has the work made)
- bytes_cpy: avoid malloc and memcpy when size is zero
- fix infinite loop in bytes_cpy when size is zero
- Bugfix: Generate iospeeds_local.h based on termios.h defines, and only try to use POSIX standard if that fails
|
|
|
|
|
Bump. Still plenty of credits to give away...
|
|
|
|
|
BFG 3.1.2 has some serious problems. I'll be releasing a 3.1.3 soon.
|
|
|
|
Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?
IMO, not gonna happen. BFGMiner makes extensive use of variable-length arrays (standard C since 1999). Microsoft explicitly refuses to support variable-length arrays. I'll look at patches of course, but I'm doubtful it can be done without making the code much uglier or slower. Wow, I never know MS's C compiler didn't support VLAs. They recommend that you compile as C++ and use vectors from the STL. I didn't see that recommendation when I searched MSDN. Do you happen to have a link handy? It may not be a bad idea to use STL, but I'm thinking if I do so, I might as well branch out to a full OO implementation. That would be quite an effort. My only objective is to be able to spawn several instances of bfgminer on a system. Why would I want to do that? I am building a "Condo" system where miners are hosted in a remote location. I want to give each user full control of his mining unit, which may be only part of a boxed system. For example, an Avalon box can have as many as 4 hardware modules, and each module can have 8 hashing units. A user in the condo system can own as small as a single hashing unit, and I want her to be able to launch her own instance of bfgminer on the same box where other users are running their own instance of bfgminer. Each bfgminer instance is associated with a user ID, and that user ID is in turn associated with particular hashing unit(s). The association of a user ID to hashing unit(s) is done by another subsystem, so all that really needs to happen is to allow bfgminer to accept a command-line parameter that indicates which hashing unit(s) it will use exclusively. I will give a hashing unit in the condo I am building to whoever can get this done, and yes, it's OK for it to be open source and GPL'd. If I were to do it, I would use VS, but if somebody else is willing to do it, it doesn't matter how it's done. Sounds like the -d option should work fine for this...? |
|
|
|
I'm trying to get bfgminer to autostart in a screen session automatically on reboot on a raspberry pi. I'm using something like: su bfgmineruser -c "screen ....." in /etc/rc.local.
When I type these commands by hand, they work fine. When started automatically at boot, bfgminer starts in a screen session like it is supposed to, BUT it doesn't recognize the Jalepeno. It is not doing any GPU mining at all, there is only one device on it, the Jalepeno.
Any suggestions or ideas would be appreciated.
My guess is the Jalapeno isn't booted when BFGMiner starts |
|
|
|
Here's an (untested) (edit: now tested and confirmed to work well) BASH script to program multiple devices with unique serial numbers: #!/bin/bash
EEPROMHex='eeprom-content.hex' # File used for manufacturer brand
Product='Block Erupter Sapphire'
SerialPrefix='Foo-' # Prepended before 8-digit serial number
SerialNoFile='last-serialno' # File holds the last allocated serial number
if ! [ -e "${SerialNoFile}" ]; then
echo "WARNING: Initializing ${SerialNoFile} file (this should only happen ONCE EVER)" >&2
echo '10000000' > "${SerialNoFile}"
fi
i="$(<"${SerialNoFile}")"
for dev in $(lsusb | perl -nle 'm/(\d{3}).*?(\d{3}).*CP210x/ && print "$1/$2"'); do
let ++i
echo "$i" >"${SerialNoFile}"
./cp210x-program -m $dev -w -F "$EEPROMHex" \
--set-product-string="$Product" \
--set-serial-number "${SerialPrefix}$i"
done |
|
|
|
Block spacing appears to be steady in a range of 30-40 seconds, the increases in difficulty are keeping it in this range for now. However, if an optimized miner with a large improvement in prime generation speed was released (ahem luke-jr's BFGminer) then I would expect to see a block spacing of ~10 seconds and the difficulty would take days to catch up.
Too bad nobody is doing altcoin releases sensibly in this area. There should be a minimum difficulty set high enough that it doesn't go through a rush like this. Bitcoin didn't break difficulty 1 for months (if not longer). |
|
|
|
|
This doesn't look anything like a FPGA to me, just a lot of custom CPUs.
I doubt it can perform any better than other CPUs, either.
I'm not aware of anyone putting the effort into running a miner on it.
|
|
|
|
Any hope of a gpu version? At least with my current (still incomplete) comprehension of the algorithm, it requires a bignum library. With this in mind, I don't plan to do a GPU port on my spare time. Maybe later, after CPU is working, if someone is willing to sponsor the development time. LukeJr, do you have any hints for people getting started on where to look or what to look for? Are you running Linux? Well, the most obvious one was hashing the block header once per nonce instead of 1-3x... I think the rest of my optimizations required actually comprehending the code  |
|
|
|
Can i go to sleep or is there a slight chance you'll release it to the public in the next few hours?  Probably not. I'll only release it after BFGMiner is working well with it, AND if I've concluded Primecoin isn't a scamcoin. |
|
|
|
I seem to be over 1000pps pretty consistently after some optimization. What kinda CPU you running on? i5-2400 I think it was around 90 pps before I optimized it. |
|
|
|
I seem to be over 1000pps pretty consistently after some optimization. |
|
|
|
Wow, shocked to see so many problems, it was working so well for me  Please everyone, help debug this: 1. Open http://luke.dashjr.org/tmp/code/webisect/webisect.php2. Enter a unique session id (try your name and a random number; eg "Luke-Jr-4239042") 3. Change the versions to match what you know works and what doesn't work. eg "bfgminer-3.1.1" and "bfgminer-3.1.2" This gets your bisect session started. You will then be presented with a series of builds to test. Depending on various factors, it may take a few minutes to produce each build (this is automated). 4. Download the build 5. Test the build 6. Click good, bad, or skip (see descriptions next to the buttons) If you get another build, go back to step 4 and repeat with that one. Eventually, you will hit an end (it should take about 6 builds between 3.1.1 and 3.1.2). Post the final result here, along with a clear description of your problem. Thanks, Luke |
|
|
|
I'll put up one Bitcoin in bounty for a CPU-miner (standalone) that will run on both windows and linux and outperform the built-in miner.
How much does it need to outperform it? I'm looking into possibly adding support to BFGMiner. |
|
|
|
NEW VERSION 3.1.2, JULY 8 20133.0.5 and 2.10.11 are also released with 3.1.2. 3.0.5 will likely also be the final 3.0.x release (if 3.1.2 isn't at least as stable, please let me know!), but 2.10.x will continue to be maintained for now. Human readable changelog:- TUI: The "GPU management" interface has been replaced with a new generic "Manage devices" interface, allowing easy enable and disable of non-GPU devices.
- Major CPU usage reduction for faster mining rigs (on my minirig host system, from 35% down to 13%!).
- erupter: New icarus-based driver to handle autodetection of (branded) Block Erupter devices.
- opencl: Add support for AMD Catalyst 13.2+ drivers.
- The device statlines have been condensed by reducing the device-specific space down to a single temperature reading. More detailed information (such as GPU fan speeds) is still available via RPC and the new "Manage devices" interface.
- RPC: New "devscan" command to probe for new devices on demand. The effect is the same as starting BFGMiner with -S noauto -S <parameter>.
- TUI: Display percentage invalid of found nonces with hw errors.
- cpu & opencl: These legacy drivers now respect the --scan-serial auto/noauto directives, and the old -C (enable CPU) and -G (disable GPU) options are now deprecated.
Full changelog- When not compiling with optimizations, initialize unused nonce2 space to avoid warnings from memory checking tools
- TUI Manage devices: Support PgUp/PgDn keys to skip over processors within the same device
- Bugfix: bitforce: Prefer 2nd temperature if higher than 1st
- When displaying device summary statlines, use the highest temperature reported by any processor
- Stratum: Fix nonce2 sizes greater than 4 and (on big-endian) smaller than 4
- bitforce: Manage TUI: Display both temperatures (if two), and enable changing fan speed
- opencl: Add fan speed to Manage device TUI now that it's been removed from statline
- DevAPI: Remove old statline APIs entirely, and add new override_statline_temp (used by modminer/x6500 for upload %)
- README: Update statlines
- TUI: Replace DevAPI statline_before with a predefined temperature column to free up statline space
- Refactor and simplify bin2hex to speed up and avoid unnecessary heap use
- stratum: Refactor work generation to do hex2bin conversions once, rather than every single header generated
- Implement bytes_t for generic binary data storage (including smart realloc-based resize)
- Bugfix: fpgautils: Only try to change baud rate when requested
- x6500: Provide manuf/product/serial to cgpu interface
- ztex: Provide manuf/product/serial to cgpu interface
- erupter: Use baud 115200 by default
- List valid baud rates once in iospeeds.h and standardize conversions
- TUI: Display device manufacturer/product/serial in Manage device screen, when available
- DevAPI: Store manufacturer/product/serial for each device
- fpgautils: detectone_meta_info to provide metainformation (manufacturer, product, serial) on devices to detectone functions
- Bugfix: fpgautils: Close product string file from sysfs (autodetect)
- erupter: New icarus-based driver to handle autodetection of Block Erupter devices
- Add --log-file option which redirects stderr to a file, but valid anywhere in the commandline or config file
- Detect staged work underruns and increase queue to avoid them
- Rewrite hex2bin to perform much faster (reduces minirig CPU usage by more than half!)
- README: Add condensed list of dependencies
- Enable "maintainer mode" by default
- Bugfix: opencl: TUI manage: "Change settings" must not be compiled in with no-ADL builds
- Bugfix: Detect whether the linker accepts -zorigin before attempting to use it
- opencl: ADL: ADL_Adapter_ID_Get fails with newer drivers, so tolerate its failure best we can
- opencl: Don't try to use BFI_INT patching with APP-SDK newer than 1084 (Catalyst 13.1), since it doesn't work
- fpgautils: Elaborate that bitstream open failures are probably due to missing bitstream package
- fpgautils: s/firmware/bitstream/
- Bugfix: Cleanup handling of complete device/driver failure
- Deprecate -C (enable CPU) and -G (disable GPU) options, now that -S drv:[no]auto can be used for the same purposes
- Bugfix: Since at least one of unix (or __APPLE__) or WIN32 is required by util.h, make sure unix is defined if WIN32 is not
- Bugfix: Set ELF rpath for bundled libblkmaker to use $ORIGIN so it can be run from other directories
- Bugfix: Cleanup needs to happen before printing the final quit message, or it gets lost in TUI mode
- Bugfix: fpgautils: Initialize my_dev_t instances with null bytes, to ensure random unused data cannot influence hash keys
- opencl: ManageTUI: Clear log cleanly for changing settings
- Remove "GPU management" TUI entirely
- opencl: Use new "Manage device" interface to do everything "GPU management" used to be used for
- DevAPI: Add interface for drivers to define custom "Manage device" options
- DevAPI: New function called to display additional processor information for "Manage devices"
- TUI: Add enable/disable commands to device management
- TUI: Implement beginnings of generic device management interface
- Bugfix: avalon: Fix LIFE_INIT2 setting
- Add LIFE_INIT2 status (safe to call functions, but not mining yet) for devices that want to report initialization status in their statline
- Bugfix: modminer: Only program once for --force-dev-init
- Bugfix: x6500: Only program once for --force-dev-init
- fpgautils: Workaround and document Xcode clang bug
- Bugfix: avalon: Correctly claim serial port
- Bugfix: -S all: Mac OS X needs to probe /dev/cu.*, not just /dev/cu.usb*
- cpu & opencl: Refuse to detect more than once
- cpu & opencl: Respect scan-serial auto/noauto instructions
- ft232r & libztex: Skip probe of claimed devices
- fpgautils: Check for devices being claimed before calling detectone from autodetectors
- x6500 & ztex: Claim USB devices
- fpgautils: Implement bfg_claim_usb for claiming devices by USB bus number and address
- fpgautils: Replace serial_claim with bfg_claim_serial using a more cleanly extensible interface and implementation
- fpgautils: serial_claim: Include a bus enum in hash key
- Add serial port claiming logic to avalon, bitforce, and modminer drivers
- RPC: "devscan" command to probe for new devices
- New (internal) scan_serial function to probe for new devices at runtime
- Split out per-cgpu temperature configuration code to load_temp_config_cgpu
- DevAPI: Modify add_cgpu to use temporary devices_new array, so detection can be done without touching live variables
- Move more cgpu initialization to allocate_cgpu
- Move devtype default assignment to allocate_cgpu
- Move cgpu startup routine to new start_cgpu function
- Move cgpu_info allocation to new allocate_cgpu function
- Move *.drv_detect calls to a new drv_detect_all function
- DevAPI: add_cgpu: There is no need to hold mutexes while creating devices
- Bugfix: cpu: Update device "kernel name" with auto-selected algorithm
- usbtest: Improve portability to at least 2.7 and 3.2
- usbtest: Avoid messing up the display by escaping weird bytes via repr()
- usbtest: Skip last 2 optional parameters, since we use the defaults and they are not in older versions of pyserial
- Bugfix: bitforce: ZOX limits results to 16 results per call, so repeat ZOX until there are fewer
- Bugfix: Initialization for bfgtls needs to be done in each thread
- Bugfix: stratum: Be patient with stratum lines that come in slower than we can process them
- Use bfg_strerror in locations previously just logging raw error numbers
- Bugfix: stratum: Log WSAGetLastError() for error number on recv failures on Windows
- Use bfg_strerror where it is already needed (for thread-safety)
- New thread-safe bfg_strerror function to portably stringify error codes
- Bugfix: bitforce_queue: Initialize buf2 so errors don't cause the work queue to flush
- TUI: Display percentage invalid of found nonces with hw errors
- Bugfix: modminer & x6500: Increment *->diff1 for all bad nonces
- percentf2 that takes t as precalculated total
- Keep track of bad nonces independently from generic hw errors
- inc_hw_errors: Resolve cgpu outside of mutex
- Use inc_hw_errors function at every site which increases hw_errors
|
|
|
|
I just got a couple USB Erupters and I am mining with them just fine. I would like to know if there is a command line argument I can use to disable my GPU from mining with BFGMiner.
using bfgminer -S all starts up both my USB Erupters and my GPU (shown as OCL 0). Then I have to go into GPU options and disable it.
How can I disable OCL 0 via command line when starting BFG Miner?
Up to 3.1.1: -G 3.1.2 and newer: -S opencl:noauto |
|
|
|
I do have a question though, couldn't i use the same software to go in and change what someone else put in? can it be write protected? IMO, people should have the right to do what they want with their own property: I would opt not to buy from a vendor who put any locks in place, just on principle, if there was an alternative. I can see both sides of this. Yes, it is yours to do with as you please. But branding implies more, an identification of source of origin. With out a lock, it is like buying a gun with the serial number ground off. I'd want my Ford to say "Ford" on it, Not Tata because the previous owner thought the company's name was cute. Without a lock, this is just a novelty. But maybe the guy you sold them to, decides to resell them himself down the road... Maybe I don't want my Ford to advertise the manufacturer, so I want to sand it off. |
|
|
|
Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?
IMO, not gonna happen. BFGMiner makes extensive use of variable-length arrays (standard C since 1999). Microsoft explicitly refuses to support variable-length arrays. I'll look at patches of course, but I'm doubtful it can be done without making the code much uglier or slower. |
|
|
|
My loyal USA customers: If you've been satisfied with my service thus far and want it to continue, I encourage you to contact ASICMiner and provide them with honest feedback about my business practices so they can make an informed decision regarding a re-seller partnership. It would take you 60 seconds to do just one of the following: - PM friedcat - tell him how your experience with me has been and your honest opinion about me becoming an exclusive US re-seller
- Email ASICMiner (asicminer.usb AT gmail.com) and tell them how your experience with me has been and your honest opinion about me becoming an exclusive US re-seller
Please see my OP ... TL:DR - I would love to continue serving you all, but only as an exclusive US re-seller with standard privileges and protections. Exclusivity is generally a bad thing, no matter who it is. good evening, These devices are classified as being part of our open source project. Do you have any way of contacting the outfit that is producing this hardware under the bitcoin logo? This for profit use has never been authorized by the foundation and goes against our mission statement...Ira - Bitcoin itself is not exclusively an open source project.
- I don't think you represent the Foundation (if you do, you should be fired for making stupid posts like this).
- I am relatively sure that neither the Foundation nor anyone you represent hold any trademarks to the BTC symbol.
- I don't see any way Bitfountain's consumer devices go against the mission statement of the Foundation.
|
|
|
|
|
Show Posts
