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

[ManeBjorn]

There has got to be some way to have it exclude it.  I cannot find one so far though.

Havent tried but even if it does work, it would be pointless as I cannot leave it off all the time.

Does it keep doing it even if you disable and then use the program?

I wish I had an answer for you.
I know that for some reason many of the mining software packs cause the anti virus programs to lock them.

Currently running a scan so I can't do anything to try and exclude it until it's done but MBAM jus logged the exe file from the 3.5.10 (Latest Stable) as Trojan.BitcoinMiner

Edit: Scans been done but keeps getting quarantined by MBAM ;-(

I like the inherent minimal OC out of the box and want to give BFG a shot for a while, currently using CGM and the two requests I made asking for help on how to OC have gone unanswered.

Anyone ?

Doesn't do it to CGM but this is kind of sucking for me.

[ManeBjorn]

HI Nate.
I am just getting ready to test this now in windows 7 64 bit.
Same way as usual?  Replace the BFG folder with the new version? 
Have the miner arguments been working ok for the zeus miners?  I have them running stable at 350.
Thanks Nate.

There is now a branch available for folks who want to start testing ZeusMiner support and giving feedback:

https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support

Available options are:

Code:

--set zus:chips=X
--set zus:freq=XXX
--set zus:cores=X
--set zus:nocheck_golden=1

While the first three are self explanatory, the fourth is apparently required to work around a small (but significant) number of buggy HW/FW revisions. These ASICs do not return a proper response to the detect command sent to them. As such, you must tell the driver to ignore the "golden nonce" returned by the device.

It is recommended you do not use this unless you are sure you need to. Also, if you must use it, I recommend you target a specific device by its path, e.g.:

Code:

--set zus@/dev/ttyUSB2:nocheck_golden=1

If you have the time / ability to test this on OpenWRT that would be awesome. There were some work-arounds in the reference driver code from ZeusMiner that I left out until I can verify it is necessary.

[hurricandave]

Some of the anti-virus programs have a buried option that you must find which specifically address (.exe) files and the exclusion must be enabled then the excluded (.exe file) name must be repeated there as well.

[nwoolls]

Here's an updated ZeusMiner branch that I've submitted in a pull request to BFGMiner:

https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support-clean

This is basically the same code found in zeusminer-support but cleaned up into nicer commits.

There are quite a few changes (to both branches) so I'd encourage folks to test this new code.

At this point I've tested the code with both 6-chip and 60-chip ZeusMiner ASICs on OS X and a Raspberry Pi. I've also had users report success on Windows.

The driver defaults to 6 chips. You can specify chips, frequency, cores using the --set argument:

Code:

--set zus:chips=60
--set zus:freq=330

etc. If you have a buggy ZeusMiner unit that is not recognized, you can try using the following argument:

Code:

--set zus@/path/to/zeus:ignore_golden_nonce=1

Note that you should not use the above unless needed, and you should specify the path to the affected device. Otherwise other cp210x ASICs will be recognized as a ZeusMiner.

[hurricandave]

   Just out of curiosity, ST (staged work) and AS (active submissions)  is this data utilizing/staging on system Ram or CPU cache or HDD cache in the case of USB ASICS like Antminer U2's ?

[Qu4k3r]

Hi there.

I used to run a BFL jalapeño with bfgminer, and a block erupter blade with miningproxy.

Now I'm running both (BFL jalapeño + BEB) with bfgminer as follows:

Code:

bfgminer --http-port 8332 -o stratum.btcguild.com:3333 -u Qu4k3r_A -p mypass

After begin to run bfgminer it shows both devices (BFL 0, PXY 0) but few minutes later a third device (PXY 1) shows up which is sick most of time and a little bit later is dead. Sometimes bfgminer shows three devices at once.

http://i930.photobucket.com/albums/ad148/qu4k3ro4ts/bfg.jpg?t=1403282389

¿Is this normal, should I worry about it?

Thanks in advance.  

[xyzzy099]

Hi there.

I used to run a BFL jalapeño with bfgminer, and a block erupter blade with miningproxy.

Now I'm running both (BFL jalapeño + BEB) with bfgminer as follows:

Code:

bfgminer --http-port 8332 -o stratum.btcguild.com:3333 -u Qu4k3r_A -p mypass

After begin to run bfgminer it shows both devices (BFL 0, PXY 0) but few minutes later a third device (PXY 1) shows up which is sick most of time and a little bit later is dead. Sometimes bfgminer shows three devices at once.



¿Is this normal, should I worry about it?

Thanks in advance.  

I don't know if this is what is causing your problem, but port 8332 is the default port for the bitcoin daemon - so anything trying to connect to bitcoind may instead connect to your BFGMiner instance.

Just as an experiment, try using port 8330 instead and see if the problem persists.

[Qu4k3r]

I don't know if this is what is causing your problem, but port 8332 is the default port for the bitcoin daemon - so anything trying to connect to bitcoind may instead connect to your BFGMiner instance.

Just as an experiment, try using port 8330 instead and see if the problem persists.

Port 8332 is what I used in BEB config page.
BFGminer 4.0.0 runs ok using port 8332. Only shows BFL 0 + PXY 0, and PXY 1 doesn't appear.

I tried port 8330 with bfgminer 4.2.0 but shows BFL 0 only, PXY 0 does not appear.
Then I tried port 8330 with bfgminer 4.0.0 but does not shows both devices, BFL 0 only.

[xyzzy099]

I don't know if this is what is causing your problem, but port 8332 is the default port for the bitcoin daemon - so anything trying to connect to bitcoind may instead connect to your BFGMiner instance.

Just as an experiment, try using port 8330 instead and see if the problem persists.

Port 8332 is what I used in BEB config page.
BFGminer 4.0.0 runs ok using port 8332. Only shows BFL 0 + PXY 0, and PXY 1 doesn't appear.

I tried port 8330 with bfgminer 4.2.0 but shows BFL 0 only, PXY 0 does not appear.
Then I tried port 8330 with bfgminer 4.0.0 but does not shows both devices, BFL 0 only.

Don't forget to aim the blade at port 8330 also.

[Qu4k3r]

Don't forget to aim the blade at port 8330 also.

I switch to port 8330 on BEB and seems to be working fine so far.
BFGminer 4.0.0 and 4.2.0 shows both devices: BFL 0 and PXY 0.

Thanks!



EDIT:

The problem seems to be something related with user:pass
If I set the BEB with same user:pass used in BFGminer, then PX1 shows up.

I used to mine BFL jalapeño with bfgminer pointing to worker1:pass1, and BEB with minigproxy pointing to worker2:pass2.

Now BFL + BEB with bfgminer pointing to worker1:pass1, but worker2:pass2 at BEB config page, then works fine.
If change to worker1:pass1 at BEB config page, then PXY 1 appears.

[utdrmac]

Simple question: can I run multiple/both scrypt and sha256 miners at the same time with bfgminer? I have 2 Gridseeds, 4 Rockminers and 1 RasberryPi. Can I plug all 6 devices in to 1 USB hub and run 1 instance of bfgminer? If yes, how would I configure bfgminer to use one pool for the Gridseeds and a separate pool for the rockminers?

Or do I need to run two instances of bfgminer, one for the gridseeds and one for the rockminers?

[Oldminer]

Is there any way bfgminer can be configured to 'reset' if it detects some of my gridseed miners have a low effective hashrate and/or are accepting few or zero shares (after say a given amount of time), rather than having to do this manually? I commonly have this issue with random gridseeds using multiminer despite having 'restart suspect/orphaned miners' checked in the program



Other times its fine, but its entirely random

[worldlybedouin]

Here's an updated ZeusMiner branch that I've submitted in a pull request to BFGMiner:

https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support-clean

This is basically the same code found in zeusminer-support but cleaned up into nicer commits.

There are quite a few changes (to both branches) so I'd encourage folks to test this new code.

At this point I've tested the code with both 6-chip and 60-chip ZeusMiner ASICs on OS X and a Raspberry Pi. I've also had users report success on Windows.

The driver defaults to 6 chips. You can specify chips, frequency, cores using the --set argument:

Code:

--set zus:chips=60
--set zus:freq=330

etc. If you have a buggy ZeusMiner unit that is not recognized, you can try using the following argument:

Code:

--set zus@/path/to/zeus:ignore_golden_nonce=1

Note that you should not use the above unless needed, and you should specify the path to the affected device. Otherwise other cp210x ASICs will be recognized as a ZeusMiner.

nwoolls huge thanks for this!  I'll give it a try tomorrow on my 7 Blizzards and let you know how it works out.

One more thing, I noticed in GitHub you've got what looks to be a newer branch:  https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support-cleaner

Is this the latest one I should test?  Or should I try the one you've provided in your post above?

Thanks!!!!

[Luke-Jr]

nwoolls huge thanks for this!  I'll give it a try tomorrow on my 7 Blizzards and let you know how it works out.

One more thing, I noticed in GitHub you've got what looks to be a newer branch:  https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support-cleaner

Is this the latest one I should test?  Or should I try the one you've provided in your post above?

Please test the "zeusminer" branch in my GitHub repo.
This is nwoolls' latest code with some minor cleanups (and a fix for big endian).
Windows builds here

[ManeBjorn]

For some reason this commit will not find my Blizzards in Win 64.
There are no errors just not found.  The previous version Nate put up found them.
I will dig though to make sure it is not something on my end.

nwoolls huge thanks for this!  I'll give it a try tomorrow on my 7 Blizzards and let you know how it works out.

One more thing, I noticed in GitHub you've got what looks to be a newer branch:  https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support-cleaner

Is this the latest one I should test?  Or should I try the one you've provided in your post above?

Please test the "zeusminer" branch in my GitHub repo.
This is nwoolls' latest code with some minor cleanups (and a fix for big endian).
Windows builds here

[Hektek]

Hey there,

ARCH is not working for me :

[minepeon@minepeon ~]$ sudo pacman -S bfgminer
resolving dependencies...
looking for inter-conflicts...

Packages (2): lm_sensors-3.3.5-1  bfgminer-3.9.0-1

Total Download Size:    0.43 MiB
Total Installed Size:   1.88 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
error: failed retrieving file 'bfgminer-3.9.0-1-armv6h.pkg.tar.xz' from mirror.a                        rchlinuxarm.org : The requested URL returned error: 404 Not Found
warning: failed to retrieve some files
error: failed to commit transaction (download library error)
Errors occurred, no packages were upgraded.


Any clue what i have done wrong ?

best regards

Hektek

[worldlybedouin]

nwoolls huge thanks for this!  I'll give it a try tomorrow on my 7 Blizzards and let you know how it works out.

One more thing, I noticed in GitHub you've got what looks to be a newer branch:  https://github.com/nwoolls/bfgminer/tree/feature/zeusminer-support-cleaner

Is this the latest one I should test?  Or should I try the one you've provided in your post above?

Please test the "zeusminer" branch in my GitHub repo.
This is nwoolls' latest code with some minor cleanups (and a fix for big endian).
Windows builds here

Thanks lukejr...I'll currently building this on Rasbian Wheezy for the Pi.  I'll let you know how it works with 7 Blizzards connected to it.

[giveen]

Could someone help me with the batch file for the zeus branch? I would like to be able to run my Gridseed and my ZM Blizzard in the same bfgminer instance

Currently running on Darkwinde's bfgminer I have

Code:

bfgminer.exe --scrypt -o stratum+tcp://stratum.rapidhash.net:3256 -u  -p 1234 --expiry 30 --queue 0 --scan-time 30 --zeus-cc 6 --zeus-clk 340 -S zeus:\\.\COM10

and my gridseed is on

Code:

cgminer.exe --scrypt -o stratum+tcp://multi.pandapool.info:3032 -u  -p gridseed --gridseed-options=baud=115200,freq=850,chips=5 --hotplug 0

I would really appreciate the help

[JoeGruff]

Hey there,

ARCH is not working for me :

[minepeon@minepeon ~]$ sudo pacman -S bfgminer
resolving dependencies...
looking for inter-conflicts...

Packages (2): lm_sensors-3.3.5-1  bfgminer-3.9.0-1

Total Download Size:    0.43 MiB
Total Installed Size:   1.88 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
error: failed retrieving file 'bfgminer-3.9.0-1-armv6h.pkg.tar.xz' from mirror.a                        rchlinuxarm.org : The requested URL returned error: 404 Not Found
warning: failed to retrieve some files
error: failed to commit transaction (download library error)
Errors occurred, no packages were upgraded.


Any clue what i have done wrong ?

best regards

Hektek

Maybe look here and uncomment lots of stuff:
/etc/pacman.d/mirrorlist

[ThomasMuller]

There is now a branch available for folks who want to start testing ZeusMiner support and giving feedback:

I love to test in Windows if there is a build.

I don't know anything about coding so bear with me but is this necessary in BFGMiner:

Code:

	int chip_clk = freq;

//max clock 381MHz, min clock 200MHz
if (chip_clk > 381)
chip_clk = 381;
else if (chip_clk < 200)
chip_clk = 200;

earlier code from Zeus looked like this:

Code:

uint32_t clk_reg;
	uint64_t golden_speed_percore;
	if(opt_chip_clk>(0xff*3/2)){
		opt_chip_clk = 0xff*3/2;
	}
	else if(opt_chip_clk<2){
		opt_chip_clk = 2;
	}

	
	clk_reg= (uint32_t)(opt_chip_clk*2/3);

I'd like to try freq or clk 383 as explained by kramble here: https://bitcointalk.org/index.php?topic=644921.msg7380726#msg7380726 but I think the BFGMiner code will only allow 381.
Can I set 382.5 clk?

I know, tiny gains, but already running at 381 clk with low HW errors.

uint32_t  is an unsigned 32 bit variable so you can only store up to 32 bit numbers no signal allowed only positive numbers. you cannot set 382.5 you would need a floating pointing variable and without getting into the differences between the two and the impact of floating point in a 'C' code the answer is NO you can only set integers for clock either 382 or 383!

change the code to the following

Code:

int chip_clk = freq;
//max clock 383MHz, min clock 200MHz
if (chip_clk > 383)
chip_clk = 383;
else if (chip_clk < 200)
chip_clk = 200;

You do this at your own risk, I don't know if the hardware can work overclocked. My answer is just to educate you on changing the min and max clock limits.

I hope this helps a bit.