Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 125. (Read 1193219 times)
September 19, 2013, 12:30:47 PM
Yep, same setup.
September 19, 2013, 12:25:20 PM
Nope, typo'd slightly on the post. Everything runs fine on the OTHER PC with 3.1.4.
Same hub? September 19, 2013, 12:23:04 PM
Nope, typo'd slightly on the post. Everything runs fine on the OTHER PC with 3.1.4.
September 19, 2013, 12:07:29 PM
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 idea what might be wrong?
September 19, 2013, 12:07:07 PM
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.
September 19, 2013, 12:00:50 PM
This keep happening to me on this PC, I'm on 3.2.1. Everything runs fine on my second PC with 3.1.4.
Any idea what might be wrong?
Any idea what might be wrong?
September 19, 2013, 11:34:47 AM
Any news on BFG supporting the RedFury USB (2.5GH) miners, Luke?
September 19, 2013, 11:03:30 AM
The third one is utility, but measured in hashes/sec instead of shares/min. (README)
I must of missed that in README... I did looked at it... But it was a glancing look after first 50%. If it help to improve README I can tell you why I missed it. I was looking for something like you see not line by line... And I was sure it will be at the start not the end... But I must say I was missing that in cgminer. Hashrate that is reported by pool... Nice...EDIT: definitely some donations coming your way when I stop investing everything into COINTAMINATION
September 19, 2013, 10:20:45 AM
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) 
September 19, 2013, 06:48:51 AM
Thanks Luke. BFG is my favourite miner by far. Everything just works. Major props for getting a proxy within it too.
September 19, 2013, 05:38:59 AM
Nice... Windows... Bye Bye Linux VM... BTW you don't need to run just a blade from it... I'm now running all miners from different machines from it 
Central control
But I do have a stupid question since I coming from CGminer camp. 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?
Central control But I do have a stupid question since I coming from CGminer camp. 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?
September 19, 2013, 03:33:07 AM
Thanks Luke-Jr
You have been very busy, 3.2.0 was nice, but 3.2.1 looks the dream version for blade users.
when my blade arrives I will send you some of the first coin.
You have been very busy, 3.2.0 was nice, but 3.2.1 looks the dream version for blade users.
when my blade arrives I will send you some of the first coin.
September 19, 2013, 02:47:05 AM
The proxy running under Win32 is a godsend. Thanks, Luke. Looks like my little NUC mining machine will be turning in to a Windows box this evening. 
September 19, 2013, 02:08:19 AM
NEW VERSION 3.2.1, SEPTEMBER 19 2013
Human readable changelog:
Human 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?
September 19, 2013, 02:03:29 AM
NEW VERSION 3.2.1, SEPTEMBER 19 2013
Human readable changelog:
Human 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?
Thanks[/list]
September 19, 2013, 12:25:14 AM
NEW VERSION 3.2.1, SEPTEMBER 19 2013
Human readable changelog:
Full changelog:
Human 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.
September 18, 2013, 08:24:19 AM
After running this getwork functionality for some time I would say it it working as good as proxy server if you look at speed only. The only difference is that proxy is just proxy but BFGMiner is not. So it doesn't send out garbage. That is why you see less shares and lower speed and efficiency in Blade interface. So if anyone is worried don't be. It works!
I also found this: https://bitcointalksearch.org/topic/bounty-5btc-cgminer-add-getwork-proxy-functionality-251224 and this one explains all https://bitcointalksearch.org/topic/m.3078019
I also found this: https://bitcointalksearch.org/topic/bounty-5btc-cgminer-add-getwork-proxy-functionality-251224 and this one explains all https://bitcointalksearch.org/topic/m.3078019
September 18, 2013, 01:34:06 AM
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.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.
Multiple blockchains at the same time has never been supported.
September 18, 2013, 12:25:15 AM
The average BFGMiner is showing is pretty much what Eligius is reporting.
Nice so is it more, less or the same as it was? And idea? I would say blade interface is reporting less but that doesn't mean that you are getting less since we don't know how it get hash rate... September 17, 2013, 11:46:03 PM
I know drivers subject is coming back all the time but I'm lost between two drivers suggested:
1. http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx
When I install this one I get "Silicon Labs CP210x USB to UART Bridge" under COMs listed and all is working fine in BFG
This is for block erupter USB.1. http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx
When I install this one I get "Silicon Labs CP210x USB to UART Bridge" under COMs listed and all is working fine in BFG
2. http://www.ftdichip.com/Drivers/VCP.htm
When I install this one I get devices under USB tree and BFG does not recognize my [BES].
This is for pretty much everything else (exception being the original Icarus).When I install this one I get devices under USB tree and BFG does not recognize my [BES].
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. Jump to: