@luke-Jr: ante plans to compile/include the recently open sourced bitfury slx150 bitstream for fpga devices? Unfortunately, Bitfury posted the source on MEGA, which has stopped supporting/working on GNU/Linux, so I can't even download it. Even if I could, I'm afraid I'm so tied up with everything else, it will be a while before I get the chance to really do anything this in-depth for FPGAs. However, if anyone else wants to have a go at building a JTAG-I/O bitstream binary from it (and releases their source under GPLv3-compatible terms), I'd be glad to dedicate some time toward updating the code to upload and use it. |
|
|
|
Can we use BFGMiner on Avalon? BFGMiner does support Avalon boards. However, there is no premade firmware for the host router included with them. There is an avalonhost-raminst script bundled with BFGMiner that will install it to RAM, but I haven't taken the time to document this process yet. Additional notes are in the README.ASIC file. |
|
|
|
Weird, I would have thought LukeJR's pool would use his protocol(especially when using his miner software)...
There are two reasons stratum has become the preferred protocol: - GBT uses a fixed amount of bandwidth regardless of hashrate, and was designed for ASICs, not CPUs. For ASICs, fixed bandwidth is a pretty good thing: much less compared to getwork, but for CPUs, it's absurdly high! Unfortunately, the stupid botnets blindly adopted GBT and were creating major bandwidth issues for Eligius.
- GBT is not yet fully implemented. The server is currently expected to send every client a full set of transactions to put in blocks. This adds to the bandwidth needed for it. A full GBT implementation gets this transaction data from your local bitcoind, not the pool. I am working on getting full GBT support into Eloipool (or a rewrite) and BFGMiner, but it takes time to get everything just right.
I expect that when GBT is finished, it can once again become the preferred protocol. |
|
|
|
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. |
|
|
|
Yes if you can find some other device on the planet that accepts my specific Icarus work item and responds with the expected nonce, then cgminer will think it is indeed an AMU
Likelihood approximately zero. I was thinking more of some device that behaves poorly when it receives the specific Icarus work item used to probe it  Still pretty unlikely, but IMO very much non-zero. |
|
|
|
|
The old BFI_INT patching doesn't work with SDKs newer than the one included in Catalyst 13.1.
I'll have the next release of BFGMiner (3.1.2) disable the patching on newer SDKs, but note the bitselect implementation does not perform as well (about 6 Mh/s lost).
These drivers seem to also have some ADL issues (at least for me), so I'm adding a workaround for that too.
|
|
|
|
Does CGMiner using the WinUSB driver have this same problem? Just curious, here.
In theory, yes: there is (without this) no way to identify an Erupter distinct from another CP210x-based device. In practice, it's possible the cgminer developers have chosen to just probe anything CP210x-based regardless of whatever devices might be using it. I think their code does that, but I am not sure. If it does, one can only hope nothing bad comes of it (ie, don't put an explosive controller on a CP210x chip connected to a mining rig  ) BFGMiner can also do that, but I think it's safest not to make any assumptions, so it requires the -S all option. |
|
|
|
Block Erupters currently come from Bitfountain with the default USB strings of the CP210x UART chip they used: iManufacturer 1 Silicon Labs
iProduct 2 CP2102 USB to UART Bridge Controller
iSerial 3 0001 Since this can (and probably is) used by other, non-mining devices, BFGMiner cannot safely probe it for a miner. Future versions will look for the iProduct string "Block Erupter" to autodetect, and track statistics better with unique serials. (If you don't brand your device, it will still work just like it does now!) Even if you don't use BFGMiner, you might be interested in branding it just for fun, or to distribute to customers if you are a vendor. With a handy program for programming this chip, these can be branded. Since this program does not support changing the iManufacturer, I had to go to some extra effort for that. Here are two EEPROM "hex" files: Bitfountain and BTCGuildYou can use them like so: ./cp210x-program -w -F eeprom-content.Bitfountain.hex --set-product-string='Block Erupter Sapphire (Red)' --set-serial-number=ljr0001 Then you get: iManufacturer 1 Bitfountain
iProduct 2 Block Erupter Sapphire (Red)
iSerial 3 ljr0001 Editing the hex files for other vendors shouldn't be very hard, but if any vendors would like me to assist in that, send me a PM. Note: I had to apply a small patch to get cp210x-program to work for me: diff -r d852ade43170 cp210x/usb.py
--- a/cp210x/usb.py Fri Sep 10 17:14:59 2010 +0200
+++ b/cp210x/usb.py Fri Jul 05 03:45:45 2013 +0000
@@ -17,7 +17,7 @@
dll=cdll.LoadLibrary("libusb.dylib")
elif sys.platform == 'linux2':
PATH_MAX = 4096
- dll=cdll.LoadLibrary("libusb.so")
+ dll=cdll.LoadLibrary("libusb-0.1.so.4")
else:
raise NotImplementedError("Platform %s not supported by usb.py" % sys.platform)
except OSError: |
|
|
|
Just switched to bfgminer from cgminer and have an issue? with the reported diff on accepted share
Bug ?
diff was set auto by the pool on 96 when I'm used cgminer You're probably used to Ldiff (Litecoin difficulty). BFGMiner uses pdiff (pool difficulty) for everything to remain consistent. |
|
|
|
|
I tried out your pool while Eligius was down yesterday with my minirig for a few hours.
The website says I have ZERO work. What's up with that? :/
It does, however, show that my worker submitted the shares:
18779 at D2, 427 at D16, 213 at D64, and 1014 at D128.
Username is luke-jr
Edit: This seems to have been silently resolved.
|
|
|
|
Hi Luke,
how do I get the block height into the coinbase? Let's say, CoinbaserCmd is not really "well" documented ;-)
It's always in the coinbase. CoinbaserCmd controls payouts. |
|
|
|
I'm not missing the driver. Each time ubuntu updates it makes a new kernel version folder. each with a build and updates folder. The original kernel folder has all the drivers and etc....
I rebooted and ran bfgminer again with -S /dev/ttyUSB0 and it appears to still be using my GPU. What flags do I need to use to make it use the block erupter? I've googled all day and can't find any clear instructions for linux. Plenty for Windoze 7 though.
-S all is sufficient if the driver is in order. If I use -S all and --disable-gpu it says all devices are disabled cannot mine. If I just use -S all it still uses my GPU, and if I just use -S it says no URI supplied for pool. Then there is something wrong with your system. Did you by any chance run cgminer? It would mess it up until you unplug and re-plug the device. Otherwise, can you post the output from: bfgminer -D -T -d? -S all |
|
|
|
|
[18:25:08] <wizkid057> replication died for some reason
[18:25:11] <wizkid057> stats will update shortly
|
|
|
|
using bfgminer 3.1.1, I get around 11% HW-erros with my Jalapeno.
is this normal? I gander it's not.
what to do, what to do?
edit: I have 8 Erupters on another BFGminer instance. How are you proposing to measure hw error as a percentage? Not all hw errors are nonces returned, and not all nonces returned are shares, so there is really no percentage... HW / A is how I "measure" it. Question is if that's a normal rate. HW/A is meaningless. |
|
|
|
Why doesn't it detect my BFL device? Paste the output from Does -G also turn off ASIC devices? No. |
|
|
|
using bfgminer 3.1.1, I get around 11% HW-erros with my Jalapeno.
is this normal? I gander it's not.
what to do, what to do?
edit: I have 8 Erupters on another BFGminer instance. How are you proposing to measure hw error as a percentage? Not all hw errors are nonces returned, and not all nonces returned are shares, so there is really no percentage... |
|
|
|
I am trying to set up a BFL ASIC single for a friend. I have worked on it for maybe 4 or 5 hours now and can't figure out how to get it working. I have tried my best to find the answer on my own, but I've reached my limit. It's time to ask the community, so here it goes:
I am using Mac OSX 10.7
I invoke cgminer with the following command:
/Applications/MacMiner.app/Contents/Resources/bfgminer/bin/bfgminer -S /dev/cu.usbserial-00002026 -o stratum+tcp://stratum.mining.eligius.st:3334 -O MyBitcoinAddress
Running the command "ls /dev/cu.*" in terminal shows "/dev/cu.usbserial-00002026" as one of the devices.
I get the following error:
[2013-06-23 20:34:10] Error -54: Enqueueing kernel onto command queue. (clEnque
ueNDRangeKernel)
[2013-06-23 20:34:10] OCL 0 failure, attempting to reinitialize
[2013-06-23 20:34:10] Error -54: Enqueueing kernel onto command queue. (clEnque
ueNDRangeKernel)
[2013-06-23 20:34:10] OCL 0 failure, disabling!
[2013-06-23 20:34:10] OCL 0 (thread 0) being disabled
[2013-06-23 20:34:10] Error -54: Enqueueing kernel onto command queue. (clEnque
ueNDRangeKernel)
[2013-06-23 20:34:10] OCL 0 failure, attempting to reinitialize
[2013-06-23 20:34:10] OCL 0 (thread 1) being disabled
If I leave it running it gives me more of the same errors.
As I said before, I have spent hours trying to figure this out on my own, so I think I am clear of the accusation of being a help vampire. Someone with better Googleing skills could probably figure it out pretty quickly.
Thanks in advance for the help
OCL is the GPU stuff. Try disabling it with -G |
|
|
|
If you know of a second mini-rig delivery, please link to it. I know of 2 others, besides myself. Whether their owners care to take on the risk of publicly saying so, is another matter. Edit: And I know of those 2 not via BFL - in other words, there are probably more I don't know about. |
|
|
|
NEW VERSION 3.1.1, JUNE 22 2013Human readable changelog:- bitforce: Support for Little Single boards, and Jalapenos with 1.2 firmware.
- avalon: Support new overclocking speeds (325, 350 and 375).
- Fixed a bunch of bugs, including GPU mining and at least one stratum-related crash.
- Windows: Now compiled with debugging information and new backtrace.dll to print usable backtraces to stderr on crash.
Full changelog- stratum: Deliver exact socket-error within the debug error message
- Don't install docs for (compile-time) disabled functionality
- Bugfix: Handle make dependencies on subdirectory files properly
- Bugfix: Use EXTRA_*_DEPENDENCIES for Cygwin workaround, to fix program make dependencies
- Support new overclocking speeds for avalon: 325, 350 and 375
- Bugfix: logging: Since we are inlining snprintf, stdio.h is needed
- Bugfix: serial_autodetect_ftdi: Debuglog FTDI COM port mappings returned, fix type of FT_HANDLE
- Bugfix: Allow starting non-libusb devices if libusb_init fails
- Bugfix: Add missing newline to libusb_init failure message
- Bugfix: opencl: Remove unnecessary casts from rot() macro, which created type issues
- Bugfix: Remove unused variables
- Suspend stratum connections when we know they've failed and don't try to recv data from them once the socket no longer exists.
- applog/quit fix GPU errors created
- logging remove extra added <LF>
- remove varargs from logging/quit/in general as much as possible
- compile unix code on Mac OS X fixes not finding the config file in $HOME
- Create a pool_localgen bool function for testing when a pool can generate work locally.
- Use mining start time for device MH/U calculations
- Bugfix: Save start time for stats to correct "Elapsed" key on "stats" RPC request
- modminer: tidy up free in device detect function
- bitforce: RPC pgaset fanmode 9 for auto fan control
- Bugfix: usbtest: Correct obvious typos
- Initial import of usbtest.py script
- Include microseconds in log output with new --log-microseconds option
- bitforce: Workaround chip ids not necessarily being in order by choosing processor count based on expected chip ids rather than parallelization
- serial_autodetect_ftdi: Debuglog FTDI COM port mappings returned
- Bugfix: On stratum disconnect, clear stratum_active and stratum_notify atomically along with sock
- Windows: Use backtrace.dll to print usable backtraces to stderr on crash
- Bugfix: bitforce: parallelized: Properly handle parallelized protocol with only 1 chip
- Bugfix: bitforce: XLINK: Increment boardno when moving on to the next board
- bitforce: XLINK: Update to use actual length,xlinkid header order
- Bugfix: bitforce: XLINK: Avoid trying to send 0 bytes after each write
- Bugfix: opencl: Build fpgautils even if OpenCL is the only driver, now that it uses it for kernel-finding
- Bugfix: Do not try to call get_stats or get_statline* if device is still initializing
- Bugfix: opencl: Add missing include for fpgautils.h (needed for open_bitstream)
|
|
|
|
|
Show Posts
