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

[jeezy]

Anyone having any luck getting Gridseeds and ZeusMiner/GAWminer running on the same rig/instance of BFGminer 4.4. So far I can get them both to Detect but BFGminer see the Fury as another Gridseed.

Just let them run in different instances? There is no drawback and everything is more stable and if one of em hangs you  don't have to restart everything just the one...

[nwoolls]

Anyone having any luck getting Gridseeds and ZeusMiner/GAWminer running on the same rig/instance of BFGminer 4.4. So far I can get them both to Detect but BFGminer see the Fury as another Gridseed.

I run them in the same instance without issues on a few machines. I'm at a loss for how BFGMiner would confuse one for the other. What is your command line?

[Zeronic]

I've got them working in separate instance for the time being. Example of my current config file, I don't do anything in the command line other than load the config setup for each mining group.

"api-port" : "4028",
"expiry" : "120",
"expiry-lp" : "3600",
"failover-only" : true,
"failover-switch-delay" : "300",
"log" : "20",
"no-pool-disable" : true,
"no-client-reconnect" : true,
"no-show-processors" : true,
"no-show-procs" : true,
"queue" : "1",
"quiet-work-updates" : true,
"quiet-work-update" : true,
"scan-time" : "60",
"scrypt" : true,
"skip-security-checks" : "0",
"submit-stale" : true,
"temp-hysteresis" : "3",
"shares" : 0,
"kernel-path" : "/usr/local/share/bfgminer",
"scan" : "gridseed:all",
"set-device" : "gridseed:clock=850",
"api-allow" : "127.0.0.1,192.168.1/24"
}

Also

#gridseed
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"
#zeusminer
ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"

[ManeBjorn]

I'm with you on the not wanting to run it from a power hungry windows system.  I right now run most of miners from my GPU rig using MM.  I do have a 2nd windows system that I use as a test and reviewing system.  The third system is netbook to run some miners.  Low power and heat and runs MM great.
That being said I run my other miners from 5 different Pi setups a mixture of MinePeon, Minera, ZenController, Testing newer Zeus Controller Images and now a StarMiner setup.  Soon to migrate more miners to a MinePeon setup and some others to a Minera setup.
I am getting there.  I have to sell off a bunch of my mining gear though.

Use the MultiMiner.  It uses BFG and there is a check box for restarting suspect miners.  So far it keeps mine running consistently and happily.
Nwoolls is the creator too so same great support.

Now, all I have are my gridseed g-blades dropping off after 2-3 hours (this didn't happen with v4.2.0) & not all will hash anymore.  Out of the 3 g-blades, each consisting of two boards, only 5 1/2 boards will hash, which randomly changes to another board not hashing, every time I restart bfgminer v4.3.0 or v4.4.0.

While I'd encourage you to try v4.2 again, there are known issues where GridSeed devices (DualMiners, Blades, Orbs, etc) stop generating nonces / shares. It's there in other drivers as well, for CPUMiner and CGMiner.

The next version of BFGMiner will include a new feature of the current watchdog to watch for nonces found by devices and compare those to pool difficulty. Basically if a device isn't generating shares anymore, it will be caught by the watchdog. In addition the GridSeed drivers (DualMiner and GridSeed) will reinitialize the device when this happens.

That sounds promising.  




Doh!!!! ...there goes one of my G-blades zero hashing again.  

Hi ManeBjorn.  I used to use Multiminer.  I love, except that I no longer leave my power hungry Windows PC up anymore than I have to.  That's the plus with the Raspberry Pi 4.5 watts & the Beaglebone Black about 2.5 watts.  They use very little wattage to run compared to my 500 watt PC.

[Sonya]

Hi, I've got 2 Rock Miner R-Boxes running on BFG miner 4.4.0. I tried over clocking them but it doesn't seem to work. They've been running for well over an hour one is staying at a consistent 32 ghs, while the other one hasn't hit 30 yet (29.32.. could be the hub I'm using for it?). Anyway I was hoping someone might have a fix for the over clock issue?


Edit:
Well, I've managed to find my own work around I don't know if this will prove useful to anyone else. So far I am able to achieve 34GHs by unplugging and replugging the power to the r-boxes

[suzukii]

Give this branch a shot and let me know if it helps:

https://github.com/nwoolls/bfgminer/tree/feature/reinit-hung-gridseed

You should see something like this when it kicks in:

 [2014-07-14 19:47:35] DMU 0: Expected nonce after 658.337158 secs (5108 secs elapsed)
 [2014-07-14 19:47:35] DMU 0: Attempting to restart

Hi Nwoolls.  I'm a dunce when it comes to Linux commands.

This is what I typed:
git clone https://github.com/nwoolls/bfgminer/tree/feature/reinit-hung-gridseed

(it's probably wrong)

Here's the proper syntax - I keep this link handy for myself  

http://stackoverflow.com/a/4568323/33112

Note - you'll need to escape backslashes, e.g. the branch is feature\/reinit-hung-gridseed

Hi Nwoolls.
Sorry I can't get it.  I'm a total ID10T when it comes to this stuff.  I tried though.

git clone -b feature\/reinit-hung-gridseed https://github.com/nwoolls/bfgminer.git

Thanks for the help there.

Hi Nwoolls.  I applied the bfgminer v4.4.0 from your branch.  Thanks for the assist on that.
But, (there's always a but) I still I have no change.  Also, I don't get the error message,
[2014-07-14 19:47:35] DMU 0: Expected nonce after 658.337158 secs (5108 secs elapsed)
 [2014-07-14 19:47:35] DMU 0: Attempting to restart, you indicated.

I have Gridseed G-blades that randomly won't start hashing when I reboot unless I do it about 20 times.
I watched my RPi rig with the 6 G-blades all day today.  I noticed my hashing was down to 17MH/s via remote SSH for about 3 hrs.  I rebooted & the hashing went up to 27Mh/s because one of the g-blades was only working at 50% (only one board active).  If I reboot as I mentioned before, on the next reboot a different G-blade will have a 1 of the 2 boards hashing & the other at a zero hashing state as I showed in the pics above on my previous posts.  I don't know what it is.


UPDATED 7/17/2014
I've tried a whole new & different RPi.
I've tried short USB cables, I've tried 3ft & 6ft USB cables.
I've also tried 10ft USB cables.  I don't mean cheap ones either.
I've change the cables to different ports on the USB hub.
I've tried plugging in 1 gridseed at a time, watching & waiting to see at what point the BFGminer starts the none-hashing on half of a Gridseed G-blade.
It's random.  Sometimes it'll just not hash on half aboard by the time I plug int the third Gridseed G-blade or the 5th or the 6th. RANDOMNESS sucks!!!  

No change.

The last thing I can think of is changing out the 28 port USB 2.0/3.0 USB hub.
Does anyone know of a good & proven USB HUB with at least 14 ports on it?

[7queue]

blkmk_append_coinbase_safe2, https://gitorious.org/bitcoin/libblkmaker/commit/9f5e949f7e1e0bb49bfe8eab1d99107b3114b4c7

What do I need to copy besides bfgminer from a linux build system to a target system so I don't get undefined reference to the above?

I've tried building with/without system libblkmaker, backed down to bfgminer-3.5.x for now.

8 )

[Luke-Jr]

blkmk_append_coinbase_safe2, https://gitorious.org/bitcoin/libblkmaker/commit/9f5e949f7e1e0bb49bfe8eab1d99107b3114b4c7

What do I need to copy besides bfgminer from a linux build system to a target system so I don't get undefined reference to the above?

I've tried building with/without system libblkmaker, backed down to bfgminer-3.5.x for now.

Undefined reference would mean you're trying to use a BFGMiner compiled with a newer version of libblkmaker, on a system that only has an older version of it.
Copying the newer libblkmaker should work (it's backward compatible with stuff using older versions).

[7queue]

blkmk_append_coinbase_safe2, https://gitorious.org/bitcoin/libblkmaker/commit/9f5e949f7e1e0bb49bfe8eab1d99107b3114b4c7

What do I need to copy besides bfgminer from a linux build system to a target system so I don't get undefined reference to the above?

I've tried building with/without system libblkmaker, backed down to bfgminer-3.5.x for now.

Undefined reference would mean you're trying to use a BFGMiner compiled with a newer version of libblkmaker, on a system that only has an older version of it.
Copying the newer libblkmaker should work (it's backward compatible with stuff using older versions).

Found them, did the trick!

Thanks

[nwoolls]

git clone -b feature\/reinit-hung-gridseed https://github.com/nwoolls/bfgminer.git

Thanks for the help there.

Hi Nwoolls.  I applied the bfgminer v4.4.0 from your branch.  Thanks for the assist on that.
But, (there's always a but) I still I have no change.

I'd stick with v4.4 for now. There are a couple of things I am looking at.

Another user alerted me to an issue that, while rare, can cause hangs with a GridSeed depending on the speed of the device and amount of work being sent to it (easier to see with G-Blades and P2Pool). That is only in the changes after v4.4.

I have a fix for that along with a planned fix for another hang for the GridSeed devices. I've talked to the maintainer of one of the CPUMiner forks for GridSeed and he's suggested a fix that I'll be testing.

[ManeBjorn]

Great news Nate.
Thanks for the hard work as always.

git clone -b feature\/reinit-hung-gridseed https://github.com/nwoolls/bfgminer.git

Thanks for the help there.

Hi Nwoolls.  I applied the bfgminer v4.4.0 from your branch.  Thanks for the assist on that.
But, (there's always a but) I still I have no change.

I'd stick with v4.4 for now. There are a couple of things I am looking at.

Another user alerted me to an issue that, while rare, can cause hangs with a GridSeed depending on the speed of the device and amount of work being sent to it (easier to see with G-Blades and P2Pool). That is only in the changes after v4.4.

I have a fix for that along with a planned fix for another hang for the GridSeed devices. I've talked to the maintainer of one of the CPUMiner forks for GridSeed and he's suggested a fix that I'll be testing.

[chup]

It's random.  Sometimes it'll just not hash on half aboard by the time I plug int the third Gridseed G-blade or the 5th or the 6th. RANDOMNESS sucks!!! 

No change.

If I would be in Your place (and I'm not, because I'm poor small miner that moves very slowly and now up to the R-box and Gridseed 5-chip miners  ) I would have made CGWatcher+BFGminer instance started for each half of the blade. Setup could be done in minutes, not so elegant, but solves frustration of undefined restarts and babysitting unreliable gridseed hardware.

[suzukii]

It's random.  Sometimes it'll just not hash on half aboard by the time I plug int the third Gridseed G-blade or the 5th or the 6th. RANDOMNESS sucks!!! 

No change.

If I would be in Your place (and I'm not, because I'm poor small miner that moves very slowly and now up to the R-box and Gridseed 5-chip miners  ) I would have made CGWatcher+BFGminer instance started for each half of the blade. Setup could be done in minutes, not so elegant, but solves frustration of undefined restarts and babysitting unreliable gridseed hardware.

Thanks for the heads up. Since I'm not a Linux person I wouldn't begin to know how to do this. Also, for some strange reason my G-blade miners have been working great for the last 72 hours with no problems. I didn't do a thing to them to make this happen. All of a sudden I guess the gremlins decided to leave my equipement alone. Go figure.

[jeezy]

Anyone got this 4.4.0 with Zeusminer Blizzards running and care to share startup parameters and config file? Cheers!

[jedimstr]

It's random.  Sometimes it'll just not hash on half aboard by the time I plug int the third Gridseed G-blade or the 5th or the 6th. RANDOMNESS sucks!!!  

No change.

If I would be in Your place (and I'm not, because I'm poor small miner that moves very slowly and now up to the R-box and Gridseed 5-chip miners  ) I would have made CGWatcher+BFGminer instance started for each half of the blade. Setup could be done in minutes, not so elegant, but solves frustration of undefined restarts and babysitting unreliable gridseed hardware.

Thanks for the heads up. Since I'm not a Linux person I wouldn't begin to know how to do this. Also, for some strange reason my G-blade miners have been working great for the last 72 hours with no problems. I didn't do a thing to them to make this happen. All of a sudden I guess the gremlins decided to leave my equipement alone. Go figure.

The CGWatcher+BFGminer combo isn't a Linux thing... it's a Windows thing.  For Linux, you'd only need BFGMiner and maybe some shell scripts.

Just search for CGWatcher.  Or use Multiminer which will do some of the same stuff.

[nwoolls]

Anyone got this 4.4.0 with Zeusminer Blizzards running and care to share startup parameters and config file? Cheers!

Code:

bfgminer --scrypt -S zus:all -o host:url -O user:pass

[jeezy]

Anyone got this 4.4.0 with Zeusminer Blizzards running and care to share startup parameters and config file? Cheers!

Code:

bfgminer -S zus:all -o host:url -O user:pass

Yeah thanks, but I already copied the string that MultiMiner generates and copied a config from somewhere and edited it to my needs. Works pretty well.

Code:

bfgminer --scrypt --scan noauto -S zeusminer:\\.\COM10 -d zeusminer@\\.\COM10 -S zeusminer:\\.\COM11 -d zeusminer@\\.\COM11 -S zeusminer:\\.\COM3 -d zeusminer@\\.\COM3 -S zeusminer:\\.\COM4 -d zeusminer@\\.\COM4 -S zeusminer:\\.\COM6 -d zeusminer@\\.\COM6 -S zeusminer:\\.\COM7 -d zeusminer@\\.\COM7 -S zeusminer:\\.\COM8 -d zeusminer@\\.\COM8 -S zeusminer:\\.\COM9 -d zeusminer@\\.\COM9 --set zus:chips=6 --set zus:clock=328 --set zus:ignore_golden_nonce=1 -c miner.conf

Code:

{
"pools" : [
	{
		"url" : "stratum+tcp://stratum.nicehash.com:3333",
		"user" : "...",
		"pass" : "d=512",
		"pool-priority" : "0"
	},
	{
		"url" : "stratum+tcp://eu2.multipool.us:7777",
		"user" : "jeezy.512",
		"pass" : "x",
		"pool-priority" : "1"
	},
	{
		"url" : "stratum+tcp://us-east2.multipool.us:7777",
		"user" : "jeezy.512",
		"pass" : "x",
		"pool-priority" : "2"
	}
],
"expiry" : "120",
"expiry-lp" : "3600",
"failover-only" : true,
"failover-switch-delay" : "120",
"log" : "20",
"no-pool-disable" : true,
"no-client-reconnect" : true,
"no-show-processors" : true,
"no-show-procs" : true,
"no-unicode" : true,
"queue" : "9999",
"quiet-work-updates" : true,
"quiet-work-update" : true,
"scan-time" : "20",
"scrypt" : true,
"submit-stale" : false,
"temp-hysteresis" : "3",
"shares" : 0,
"kernel-path" : "C:/mining/bfgminer-4.4.0-win64/bfgminer"
}

[bmoscato]

Can I use BFGMiner with 2 different types of ASIC devices at the same time?  Currently I’m running 10 AntMiner U2’s, I just ordered a few Rockminer R-BOX units.  I’d like to run all from 1 instance of BFG.

[jeezy]

Can I use BFGMiner with 2 different types of ASIC devices at the same time?  Currently I’m running 10 AntMiner U2’s, I just ordered a few Rockminer R-BOX units.  I’d like to run all from 1 instance of BFG.

Sure. There was a config some pages back I think that did the same thing, might just read through the last couple pages. Hope that helps.

[Sonya]

Can I use BFGMiner with 2 different types of ASIC devices at the same time?  Currently I’m running 10 AntMiner U2’s, I just ordered a few Rockminer R-BOX units.  I’d like to run all from 1 instance of BFG.

Yep, Currently have 3 NanoFurys (F1/F2), 23 Antminer U1/U2 and 6 r-boxes all running.

I could use some help writing a config file, mine seems to only save pools.