which will be the best using the sticks as comm ports or using the other way as usb1 usb2 etc?
Same thing. \\.\COMn is Windows; /dev/ttyUSBn is Linux |
|
|
|
so i actually need 5A since each usb pulls 0.5A ? Plus a bit more for the hub itself... so how much does each erupter actually pull surely not 0.5A? bah. i'll get a 6A psu tomrrow or another usb hub Yes, they use the full 0.5A. ... and don't assume a hub that only includes a 1A power supply can handle more! |
|
|
|
i have 12 usb eruptors but bfg only seems to see 9...... restart then i only picks up 7, restart picks up 10 with 2 giving errors?!
what size are your usb hubs? If the psu is not big enough some erupters will not start mmm u might have a point there. its a 10port with a 1000ma power. 2 low? ed 2 running of pc no problems there 1000mA is good for 2 ports. |
|
|
|
Any idea with my issue luke?
Sounds like an OS issue. Check that your /etc/ld.so.conf is correct, maybe rerun ldconfig. If that doesn't help, mention here where the library is, the output of ldd bfgminer, and the content of /etc/ld.* |
|
|
|
Got 3.2.1 running on Windows 7 Enterprise x86 last night. As soon as the Blade connected to BFG, BFG just quit/disappeared. Upon reopening BFG everything worked perfectly. Connected the second Blade, and again BFG quits. I've rebooted etc several times, and BFG is happy now.
To me, it seems BFG quits on the very first instance on a Blade connecting to the HTTP port (perhaps something craps out creating the virtual device?).
3.2.1 works OK on Linux, on the same machine (Intel NUC DCCP847DYE) with 4GB RAM and 30GB Kingston SSD).
Scratch that. First time the Blade connects at each reboot, BFG quits. It runs perfectly every time until the next reboot. Blades aren't being restarted, just using the Switch Server function (the backup server are to a stratum_proxy running on my WHS. I'll likely need the crash report (printed to standard error, or log file if one is configured) to do anything. BFGminer is not really a Windows program, it is a DOS program. No, BFGMiner is a fully native Win32 and Win64 application. I don't think it's even possible to build it for DOS. |
|
|
|
when to expect stratum proxy enabled for OpenWRT?
After I decide to write stratum proxy support (or someone else contributes it), at least  i tought its already included in the general Linux and rPi source, is it so much different for OpenWRT? There is no stratum proxy support in BFGMiner at all right now, but it is a Planned Feature™. |
|
|
|
ok maybe i read this wrong can i disable the gpu but autoscan for all the usb eruptors?
-S opencl:noauto -S erupter:all |
|
|
|
Yep, same setup.
Can you try 3.1.4 on the same PC that 3.2.0 has the issue on? |
|
|
|
Nope, typo'd slightly on the post. Everything runs fine on the OTHER PC with 3.1.4.
Same hub? |
|
|
|
This keep happening to me on this PC, I'm on 3.2.1. Everything runs fine on PC with 3.1.4.  Any idea what might be wrong? Likely overheating or defective unit. |
|
|
|
Any news on BFG supporting the RedFury USB (2.5GH) miners, Luke? Andreas has provided some code, but I don't have a unit to test with. Just pushed a "bigpic" branch based on Andreas's code merged up, if you want to try it out. It looks like there's a lot of code in there that will be redundant with the metabank/littlefury code, so I should probably merge the two before it'll be 3.3-ready. |
|
|
|
You have 3 hash speeds. First one is probably 5 second or so average... One would probably be all time average but what is the reaming one? The third one is utility, but measured in hashes/sec instead of shares/min. (README) |
|
|
|
NEW VERSION 3.2.1, SEPTEMBER 19 2013Human readable changelog:- Win32 (but not Win64) binaries now support the getwork server/proxy (for Block Erupter Blades).
Does this mean I still need the slush proxy program or can it support it natively? You don't need any other software. Check out README.ASIC. |
|
|
|
By the way, if anyone has ASIC blades on their network, since you really don't need the rPi to control them unless you're doing a stratum proxy. I've made a php add-on for MinePeon to scrub the stats of each blade and display it. Working on having it bring it into the main area with the other devices at the moment.
BFGMiner supports blades natively as of 3.2.0, FYI. |
|
|
|
NEW VERSION 3.2.1, SEPTEMBER 19 2013Human readable changelog:- Win32 (but not Win64) binaries now support the getwork server/proxy (for Block Erupter Blades).
- Support for Windows Embedded Standard (excluding X6500 and ZTEX).
- Allow startup with no devices, even if RPC and HTTP server are disabled, so long as the user can add new ones via the curses TUI.
Full changelog:- Only show long-poll message in pool summary if it's not using stratum.
- README.ASIC: Clarify syntax of --scan-serial usage for USB Erupters
- Bugfix: RPC: Defer allocation of apisock until after we check for --api-listen
- make-release: Only try to include libmicrohttpd if bfgminer.exe depends on it
- Bugfix: make-release: Include libplibc-1.dll if available
- SGW: For Windows builds, include winsock2.h instead of POSIX networking headers
- configure: Display getwork proxy server support in summary
- Bugfix: SGW: Pass actual cgpu_info to prune_worklog_thread instead of silently casting one from getwork_client
- Bugfix: Get total_staged with lock for TS stat, before getting console lock
- Bugfix: bitforce: Correct fanmode RPC help
- bitforce: Hide fan control when disabled in firmware
- Bugfix: bitforce: Correct fanspeed TUI setting
- Bugfix: logging: Allow up to 4 KB for log lines
- Bugfix: icarus: Ensure last2_work exists before trying to check nonces fit it
- README.OpenWrt: Include serialusb drivers
- README: Include OpenWrt serialusb driver package names
- Bugfix: Initialise notifier (as invalid) for no-thread devices (SGW)
- Bugfix: Free temporary kernel path copy when writing config file
- Bugfix: Put kernel path on the (main) stack after initialisation from commandline/config, to avoid appending an argv or jansson string
- Bugfix: Always allow startup with curses enabled (since the user can use Manage devices to add new ones, and display Ctrl-C for text-only quit help
- Bugfix: Ignore/reject libmicrohttpd before 0.9.5, which introduced symbols we need
- README: Elaborate on format of BW
- Bugfix: Try to initialise libusb later, so any mutexes applog might need are initialised
- Bugfix: Implicitly initialise timer_set_now when it is first called
- util: Eliminate unsafe const-removing casts
- configure: Cleanup CFLAGS/LDFLAGS display
- Show RT_LIBS in ./configure output.
|
|
|
|
This is for block erupter USB. This is for pretty much everything else (exception being the original Icarus). How this two relate? Both say virtual COM (USB to COM). Totally different protocols/chips, though. USB has a standard, but so far only ModMiner and LittleFury use it. GREAT software Luke, Thank You! You're welcome. |
|
|
|
|
Anyone stuck on BFGMiner 2.10 still?
I think it's time to retire it and promote 3.0 to stable...
Please speak up if 3.0 doesn't work at least as well as 2.10 for you.
|
|
|
|
Luke-Jr can you comment if the difference I see in blade interface it due to proxy not detecting HW error and BFGMiner do? It is hard to say from pool data since difference is not that big... It's possible. I'm not sure if slush's proxy handles hw errors. |
|
|
|
Why is engine 0 always disabled? It doesn't work on RevA chips. On RevB chips, they run 300 MHz faster, so with engine 0 they can get up to 71 Gh/s. But due to the higher heat producted, this was damaging chips, so engine 0 is disabled. |
|
|
|
I found an odd behavior when you use different blockchains and block erupters. I have a merged mining Bitcoin pool set as main pool and a PPCoin pool as a failback pool. When the main pool fails, it switches without problems to the PPCoin pool and keeps on mining. When the main pool comes back to life, it switches back to pool 0 but stops mining. My block erupters are turned off. If I manualy switch back to pool 1 they start working again. If I now manualy switch to pool 0, bfgminer ignores this and keeps mining on pool 1. I have to restart bfgminer to get it working on pool 0 again.
I also tried manualy switching on my GPU rig. Here most of the time switching between the pools is no problem (It only gets very few times stuck at the PPCoin pool), even balancing as pool strategy works without problems. Load balancing doesnt work, it keeps mining on the pool with the highest priority.
Sounds like it's working fine, given the circumstands. Multiple blockchains at the same time has never been supported. |
|
|
|
|
Show Posts
