OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30

[ezimedia]

I am using a Gridseed 5chip orb ok on Bfgminer 3.10.0 all works fine mining scrypt with this pool config.

bfgminer.exe --scrypt -o stratum+tcp://us-east.multipool.us:7777 -u ezimedia.1 -p x -d gridseed -S gridseed:all --set-device gridseed:clock=800

But using the same config in Bfgminer 4.0 I get nothing but errors..

bfgminer.exe --scrypt -o stratum+tcp://us-east.multipool.us:7777 -u ezimedia.1 -p x -d gridseed -S gridseed:all --set-device gridseed:clock=800

I have also tried this config.. on both bfgminer 3.10.0 and v4.0

bfgminer.exe --scrypt -o stratum+tcp://multi.ghash.io:3333 -u ezimedia.workerGRIDmulti -p 1 -d gridseed -S gridseed:all --set-device gridseed:clock=800

and it works fine.. and also with other mining pool configs...

Bfgminer v4.0 will just not work with

bfgminer.exe --scrypt -o stratum+tcp://us-east.multipool.us:7777 -u ezimedia.1 -p x -d gridseed -S gridseed:all --set-device gridseed:clock=800

where as bfgminer 3.10.0 works just fine..

Any ideas..?

Also can Bfgminer 4.0 support Sha256 mining in duel mode for a gridseed 5chip orb at the same time while mining scrypt..



Also can you get Bfgminer to recognise other mining hardware at the same time.. because I have 9 Drillbit avThumb miners to mine sha256

Right now I am running cgminer for the Drillbit avThumb miners..

And Bfgminer 3.10.0 for scrypt mining with my Gridseed..

What I would love to do is use Bfgminer 4.0 to do the following..

Mine both sha256 & script from my Gridseed 5chip... to one pool mostly cex.io i guess

and also use bfg miner to run my 9 Drillbit avThumb miners for btc...

I was thinking something like this... from launching bfgminer in one instance

I would make a start.bat like this..

bfgminer.exe --scrypt -o stratum+tcp://multi.ghash.io:3333 -u ezimedia.workerGRIDmulti -p 1 -d gridseed -S gridseed:all --set-device gridseed:clock=800
bfgminer.exe -o stratum+tcp://uk1.ghash.io:3333 -u ezimedia.workerGridLbtc -p 1 -d gridseed -S gridseed:all --set-device gridseed:clock=800
bfgminer.exe -o stratum+tcp://uk1.ghash.io:3333 -u ezimedia.workerDRILLbtc -p 1 --drillbit-options AvThumb:int:700:1:850

Would this work... well just tried it and it looks like the first line is the only one that runs...

Is it even possible to run 3 lines as above from one loaded instance of Bfgminer

well will wait for the experts feedback..

Thanks.. for Bfgminer 4.0

[Anonymailer]

Awesome, thanks luke! I've updated MacMiner from 3.99 to 4.

Ah - just the person I was looking for! Time to put you on the spot 

As a fellow Mac dev and someone familiar with BFGMiner, if you could take a peak at this and see if there's anything you can crack that would be super:

https://github.com/luke-jr/bfgminer/commit/1c4821cbe814845c0c72530f3fba3b9040647648

This put Luke and I back a couple days on releasing 4.0 and, in the end, we still had to go with a work-around rather than finding a proper solution. It would be great to get someone else with the required resources and system taking a look.

I've actually always used my own compiled dependencies for the most part rather than using Homebrew and as a result that seems to have caused homebrew installations of bfgminer to fail for me for some time - that said none of the other homebrew scripts I've used have been failing for me - I'll take a look in a clean environment though and see how it goes!

[ManeBjorn]

HI Luke.
I have been having a show stopping bug since 4.0 came out.

I have a small setup that has 3x DualMiners, 2x Ant U1's/U2's, 1x RedFury, 2x HexFury's, 4x Block Eruptors and 1x BiFury.
When I upgraded to 4.0 they all stopped working together.  I have them in a Razorfish HUB and had no issues prior.

Now when it scans for miners it will find some of them but not all.  Some will not work that are detected.  Each time I scanned them different miners were found and left out.
I have tried leaving only one type in and it works ok.  I can no longer mix them.

Any ideas?  I am out of them.  I have went through so many things and re-installs and going back to previous versions.  I have no clue what to do.

On another note that is not bad just need info.
I have another setup that has OneString Miners.  Do you know which drivers to use for them in BFG and a link to them?  When testing I cannot get the driver setup correctly with what is there.

Thanks for the help.

[Sonicprince]

Hi All,

Some notes that might help others with NanoFury/Yellowjacket oddities when run with other devices.

I reinstalled WinXP today on my old laptop with a new harddisk to a) give me more room for BitcoinQT, and b) seemed like a good time anyway, it also rules out any other problems behind my problem with starting order of USB devices.

I've been having a problem with BFGMiner v3.10.x and now v4.0.0, If I simply plug all my USB devices in, and ensure that WinXP picks them all up in Device Manager, I end up with a mess, the BEE's (and sometimes the BIF) are never found by BFGMiner when its started with the NFY's already plugged in, and the NFY's are found very errratically.
I had BEE's, BPM's, NFY all plugged into one USB2 hub (no plugs, direct soldered leads to an excellent switchmode supply), and a BIF which I have plugged into a USB3 hub.

Turns out the NFY's don't like starting up at the same time as Block Eruptors (BEE's) and BPM's (that's right, not the BIF), so I've put BEE's, BPM's, and BIF on the USB3 hub, and put all my NFY's on the USB2 hub. For NFY's think NanoFury's/Yellowjackets.

Solution that works all the time.

Start BFGMiner with only the USB3 hub and all BEE's, BPM's and BIF are found and started, then I plug in the USB2 hub, 1 or 2 NFY's are automatically found, within a few minutes the rest of the NFY's are then found. (I normally do a "M + auto" in BFGMiner as I'm impatient)

I have tried different hubs, with the same results, I haven't looked further as I don't have any debug/trace tools for Windows, this is the only thing with windows on it in this house as we aren't windows people but at least it give the old laptop a reason for being.

Cheers

(edited, I deleted the wrong bit when originally writing this)

[chup]

Thx for the update, from the update logs I can see more changes made for dualminers and less for 5-chip gridseeds. I red all readme-files and tried --help with various parameters, but couldn't find syntaxes for parameters/commands specific for mentioned miners. Thank You in advance if such explanation/readme exists and can be pointed out or linked.

[OSAMan1]

 
I need help! Had to manually download both the Driver and BfgMiner from your Mega Website link. Driver worker but BfgMiner won't work.Extracted bfg.exe via WinRar to my desired folder still when it's ready to run it says : The program can't start becuase liburl-4.dll is missing from your computer try re-installing the program to fix the program. I've unistalled and re-installed all morning and afternoon long but still can't get bfgminer going due to libcurl-4.dll any clues as to what wrong or maybe a better link? Also did I create a bigger problem for myself by editing the startmining BAT file by opening it with NotePad? My problem seems to be that when clicked on this file after download and extract it didn't open so i did open with and chose NotePad program. Now the file can't be edited or at least I don't know how to reset the file back to a BAT - #Drowning50GHsMiner 

[TRN1062]

Luke,

Any update on the Rockminer R-box driver inclusion? I have 2 of them in route and would love to know I will be able to get them hashing when I get them. I am not much of a wiz on coding so I have to rely on your expertise and your code!!

I've been struggling to keep up or catch up with the difficulty increases so not a lot of crumbs in my wallet but I will certainly donate to the cause for your help!

T.

[nwoolls]

Thank you very much to X-Hash and GridSeed for providing a G-Blade for development. Support for this device (as well as the HEX16A2) will be coming ASAP.

[silverthornne]

I may be doing something weird in 4.0, but the script I used to use on version 3.10 for the proxy (I'm running 2 Block Erupter Cubes) doesn't seem to agree with the Cubes. BFGMiner is reporting a hash rate from them, but when I go to the Cube admin page they don't know their hash rates; it just reports 0. It's definitely hashing since the pool does report the miner as alive, but the hash rate that I'm getting is lower than expected and I notice the cube keeps switching automatically between both configured pools in a Primary/Backup configuration. It's not supposed to do that if the work is getting accepted.

Edit: Using the 32-bit Windows version on Windows 8.1. Just noticed that this version has the proxy on the 64-bit release but I haven't downloaded the 64-bit yet.

[nwoolls]

I may be doing something weird in 4.0, but the script I used to use on version 3.10 for the proxy (I'm running 2 Block Erupter Cubes) doesn't seem to agree with the Cubes. BFGMiner is reporting a hash rate from them, but when I go to the Cube admin page they don't know their hash rates; it just reports 0. It's definitely hashing since the pool does report the miner as alive, but the hash rate that I'm getting is lower than expected and I notice the cube keeps switching automatically between both configured pools in a Primary/Backup configuration. It's not supposed to do that if the work is getting accepted.

Edit: Using the 32-bit Windows version on Windows 8.1. Just noticed that this version has the proxy on the 64-bit release but I haven't downloaded the 64-bit yet.

I can confirm I'm seeing the same behavior with both a Cube and Blade v2.

[nwoolls]

Thank you very much to X-Hash and GridSeed for providing a G-Blade for development. Support for this device (as well as the HEX16A2) will be coming ASAP.

https://github.com/nwoolls/bfgminer/tree/feature/gridseed-blade-support
https://www.dropbox.com/s/8mzuje5y3mv1aju/bfgminer_gridseed_blade.7z

[fulanomengano]

After following the compilation instructions detailed in the file windows-build.txt included with the source, I was able to compile BFGMiner with Open CL support. I was wondering if there is an "appendix" on how to compile it for Windows 64 bits.

Thanks

FM

[Riley600]

Thank you very much to X-Hash and GridSeed for providing a G-Blade for development. Support for this device (as well as the HEX16A2) will be coming ASAP.

https://github.com/nwoolls/bfgminer/tree/feature/gridseed-blade-support
https://www.dropbox.com/s/8mzuje5y3mv1aju/bfgminer_gridseed_blade.7z

In some short testing, this version seems much more stable with my Gridseed 5 chip miners as well.

I have a quick question about support for the miningrigrentals.com service.  Gridseed forks for CGminer and BFGminer 3.10 seem to be able to connect to their stratum.  However, when I try BFGminer 3.99 or BFGminer 4.0 it just reports the miningrigrentals stratum as dead.  I see this in their FAQ:

• Make sure you're not using a mining client that has the "reconnect fix" added (currently only special versions of cgminer). Also check your config file for this line: no-client-reconnect : true, This line needs to be set to false.

I'm using command line flags only and the config file doesn't appear to have the "no-client-reconnect true".  So I'm at a bit of a loss...

[nwoolls]

Throwing out some examples of GridSeed support / performance in BFGMiner 4.1:

G-Blade on OS X:



Orbs on a Raspberry Pi:

[hurricandave]

I tried 4.0.0 windows 32-bit with 20 antminer U2+ and ST= started out at 22 then went to 24-28 after 3-4 hours as opposed to 3.10.0 starting out at ST=9 then adjusting after 3-4 days to 12-14. Now I only point this out because my reject rate skyrocketed. It seems that with the new version, ST= is much higher from launch than 3.10.0 and every time a new block is detected, I end up with about 20+ stales, followed by another 7-15 either stales or duplicates.
    I also had a deal where 4.0.0 stopped mining when my ethernet connection failed for a moment but the miner program just stopped, liked it didn't even try to continue or reconnect. Its hard to say for sure with that since it seems 4.0.0 is meant to be a bit quieter.
 

[TRN1062]

I tried 4.0.0 windows 32-bit with 20 antminer U2+ and ST= started out at 22 then went to 24-28 after 3-4 hours as opposed to 3.10.0 starting out at ST=9 then adjusting after 3-4 days to 12-14. Now I only point this out because my reject rate skyrocketed. It seems that with the new version, ST= is much higher from launch than 3.10.0 and every time a new block is detected, I end up with about 20+ stales, followed by another 7-15 either stales or duplicates.
    I also had a deal where 4.0.0 stopped mining when my ethernet connection failed for a moment but the miner program just stopped, liked it didn't even try to continue or reconnect. Its hard to say for sure with that since it seems 4.0.0 is meant to be a bit quieter.
 

I experienced similar problems with 4.0 producing more rejected shares and shutting down for no apparent reason. I went back to 3.99 for now until some wrinkles get ironed out and perhaps a r-box driver is available then I will try 4 again.

[BCwinning]

I tried 4.0.0 windows 32-bit with 20 antminer U2+ and ST= started out at 22 then went to 24-28 after 3-4 hours as opposed to 3.10.0 starting out at ST=9 then adjusting after 3-4 days to 12-14. Now I only point this out because my reject rate skyrocketed. It seems that with the new version, ST= is much higher from launch than 3.10.0 and every time a new block is detected, I end up with about 20+ stales, followed by another 7-15 either stales or duplicates.
    I also had a deal where 4.0.0 stopped mining when my ethernet connection failed for a moment but the miner program just stopped, liked it didn't even try to continue or reconnect. Its hard to say for sure with that since it seems 4.0.0 is meant to be a bit quieter.
 

I experienced similar problems with 4.0 producing more rejected shares and shutting down for no apparent reason. I went back to 3.99 for now until some wrinkles get ironed out and perhaps a r-box driver is available then I will try 4 again.

I don't have nearly that many u2's but mine are working fine in 4.0.0 or at least appear to be. Haven't noticed anything different
actually. Been running 4.0 since release pretty much.

[hurricandave]

I am trying to launch BFG Miner 3.10.0 on a Windows 7 Pro 32-bit Desktop and after using the file since Christmas it has now decided it can't launch the program "libplibc-1.dll is missing" is it something I can get from GitHub or do I need to ring the snot out of Avast for blocking something it should be leaving well enough alone?

[sciack]

Hello,

I use bfgminer with MinePeon, I'd like to have my miner's name instead ox PXY0, PXY1, etc... I use it as proxy and connect to it all my S1's. But it turned to be a mess since I can see PXY0 which is my S1 number 6, or PXY5 to be my AntS1 number 2. Can't be assigned a name used like the worker name set in the pool settings of the S1?

Thank you if you help me with this.

[Luke-Jr]

NEW VERSION 4.1.0, JUNE 6 2014

Human readable changelog:

• Stratum: Fix recovery of dead pools.
• gridseed: 80-chip G-Blade support.
• Stratum: Support for authenticated TLS with the CA model, using #tlsca URI parameter.

Full changelog:

• Bugfix: Ensure variables are declared even without ADL support
• RPC: Include a list of config files loaded in "config" reply
• Bugfix: Save a linked list of config files loaded so output makes sense (previously only the most recent config file was named, and errors were reported inconsistently)
• README.RPC: Document Coinbase-Sig in config reply
• Bugfix: Safely handle pool status line when no pools are alive
• bitforce: Refactor bitforce_vcom_gets slightly to be more sane
• Bugfix: initiate_stratum: Ensure extranonce2 size is not negative (which could lead to exploits later as too little memory gets allocated)
• Stratum: extract_sockaddr: Truncate overlong addresses rather than stack overflow
• Stratum: tlsca parameter to require CA validation of TLS certificate
• Bugfix: Avoid setting tv_idle before testing pool (it will be set if the test fails)
• restart_stratum: Make use of return_via
• return_via helper function family to assign a variable and goto
• Bugfix: restart_stratum: Release pool_test_lock on failure
• bfsb: Disable all banks before enabling the one we want, to avoid having two enabled at the same time (eg, when switching from bank 3 to bank 2)
• Interpret present "tls" parameter to require TLS
• uri_get_param_bool2 returning a tristate
• Tests for uri_find_param
• Split uri_find_param out of uri_get_param_bool
• gridseed: Allow specifying an arbitrary number of chips with --set gsd:chips=X
• gridseed: added support for the 80-chip (two blades of 40 chips) G-Blade Scrypt-only miner
• Bugfix: gridseed: use a signed integer so that returning -1 has defined behavior
• RPC: Return integer difficulties without decimal places
• Bugfix: Zero pool "Works"
• Bugfix: Set any listening sockets to close-on-exec/non-inheritable to avoid issues rebinding them on restart
• RPC: Explicitly shutdown communication on client sockets to avoid them being held open by forked processes
• RPC: Clean up mcast socket with tidyup_socket
• RPC: Move socket tidyup code to its own function
• Bugfix: RPC: Use pthread_exit rather than returning from the RPC thread, to ensure tidyup gets called
• Bugfix: bitforce: During initialisation, clear each XLink slave exactly once only