BFGMiner 5.5.0: CPU/GPU/FPGA/ASIC mining software, GBT+Stratum, RPC, Linux/Win64

[Mikestang]

• Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.

Could you please explain how to use this command?  I do not see it in the readme and it does not appear to be a command line option.  Thank you!

[Mikestang]

BTW, anyone want to go and update README with all these tips I've been dropping on the forum thread(s)? :p

I added info to the U3 section of your readme-asic:

Code:

ANTMINER U3
-----------

The U3 does not support autodetection, so you will want to use --scan-serial to
manually probe it. For example, to scan all devices, you can use:

-S antminer:all --set antminer:chip=BM1382

Additionally, for optimal performance you will need to set voltage, clock, and
timing. Voltage format for the U3 is not documented by the manufacturer, thus
must be provided as hexadecimal configuration codes. Timing is provided in the
number of nanoseconds each hash takes at the given configuration. A
known-working configuration is:

--set antminer:voltage=x800 --set antminer:clock=237.5
--set antminer:timing=0.022421

To set different frequency and voltage settings for multiple U3 miners on a
single BFGMiner process use:

--set antminer@\\.\COM10:voltage=xNNNN

or

--set antminer@/dev/ttyUSB1:voltage=xNNNN

Another option is to program the CP2102 chip so they have unique serial numbers;
this method would avoid problems with the device showing up on different tty/COM
locations after reboot/hotplug:

/cp210x-program -w -F eeprom-content.AntU3-custom.hex --set-product-string='Antminer U3' --set-serial-number=myveryown0001

Then you can use --set antminer@myveryown0001:voltage=xNNNN

I also added the RPC command to adjust frequency to the compac part or readme-asic:

Code:

COMPAC
------

These USB sticks are based on Bitmain's BM1384 chip, and use the antminer
driver. You can set the clock frequency with

--set compac:clock=200

You can also adjust the clock real-time while the stick is hashing using RPC's pgaset:

bfgminer-rpc "pgaset|0,clock,x0982"
		     |       ^^^^^ hex frequency
		     ^ device number

Added a few more suggested uses for --set-device from readme:

Code:

--set-device|--set <arg> Set default parameters on devices; eg, NFY:osc6_bits=50, bfl:voltage=<value>, compac:clock=<value>

[xyzzy099]

• Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.

Could you please explain how to use this command?  I do not see it in the readme and it does not appear to be a command line option.  Thank you!

I believe you add "/#cksuggest" to the end of the pool URL.

[toptek]

• Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.

Could you please explain how to use this command?  I do not see it in the readme and it does not appear to be a command line option.  Thank you!

I believe you add "/#cksuggest" to the end of the pool URL.

That's how but what does it do ? .  I Don't see were it did any thing on CKpool .

[toptek]

Can I change the voltage of Gridseed orbs and Zeus Blizzards(Gaw Fury) using the new BFGMiner or do I have to actually go in and put new resistors in them?

for that i believe it has no software adjustment that would be on the hardware not bfg sadly so yea you would have put new resistors to adjust it or up or down I'm guessing you want down for less power usages ?.


I saw a guide some place on how to for both Zeus miner and Grindseed   .




read me in 5.4 if you missed it   .

GRIDSEED
--------

Gridseed units, at the present time, come in two versions: Blade - a 40 chip
unit and Orb - a 5 chip unit. Orb units can be used to mine both SHA256d and
scrypt based coins whereas the Blade is scrypt only, although BFGMiner only
supports scrypt mode at this time.

BFGMiner allows a miner to connect both types of units to a single miner
instance and provides for granular control of the clock frequencies for each
device and each chip on each device. The basic use of this feature is to use the
--set option on from the command line:

bfgminer --scrypt -S gridseed:all --set gridseed@<serial_number>:clock=825

for multiple devices, add multiple --set arguments.

Additionally, these can be added to the bfgminer.conf file for persistence like
this:

"set" : [
        "gridseed@<serial_number>:clock=825",
        "gridseed@<serial_number>:clock=850",
        "gridseed@<serial_number>:clock=875"
]

To find the device serial number, start bfgminer and press <M> to manage
devices, then <Page Down> or <down arrow> through the list of devices and take
note of the device serial number in the device information shown.

...
Select processor to manage using up/down arrow keys
 GSD 0a:       |  74.4/ 72.9/ 10.2kh/s | A:  1 R:0+0(none) HW:0/none
  STM32 Virtual COM Port from STMicroelectronics
Serial: 6D85278F5650
Clock speed: 875
...

So for example, an entry would look like this:
        gridseed@6D85278F5650:clock=875


ZEUSMINER
---------

Zeusminers do not support autodetection, so you will need to use --scan to probe
for them:

-S zeusminer:\\.\COM3

You should also configure the driver for your specific device:

    --set zeusminer:clock=N        Clock frequency (default: 328)
    --set zeusminer:chips=N        Number of chips per device
        Blizzard    :  6          Cyclone     :  96
        Hurricane X2: 48 (2*24)   Hurricane X3:  64 (2*32)
        Thunder   X2: 96 (4*24)   Thunder   X3: 128 (4*32)
Note: if you set this option incorrectly, the device may underperform and/or
      misreport hashrate.

For example:

bfgminer --scrypt -o stratum+tcp://pool:port -u user -p pass -S zeusminer:\\.\COM3 --set zeusminer:clock=328 --set zeusminer:chips=128

---

[xyzzy099]

• Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.

Could you please explain how to use this command?  I do not see it in the readme and it does not appear to be a command line option.  Thank you!

I believe you add "/#cksuggest" to the end of the pool URL.

That's how but what does it do ? .  I Don't see were it did any thing on CKpool .

It causes the difficulty request set by '--request-diff' to be sent in the format expected by ckpool, I would imagine.  I have not tried it, but that's what I would expect it to do.

[toptek]

• Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.

Could you please explain how to use this command?  I do not see it in the readme and it does not appear to be a command line option.  Thank you!

I believe you add "/#cksuggest" to the end of the pool URL.

That's how but what does it do ? .  I Don't see were it did any thing on CKpool .

It causes the difficulty request set by '--request-diff' to be sent in the format expected by ckpool, I would imagine.  I have not tried it, but that's what I would expect it to do.

I know what it does and how to use it . what I don't know is how to test it to see if it works maybe i should say, i did use it but didn't see any improvement, if its meant to . i should be more clear, i never really had a issue to start with . . my issue with compact and bFG and CK pool is on start up any version OF BFG that's works with compac, i get maybe 20 rejects then it kicks  in and works great, i haven't seen any one say or complain about that so i take it as normal and thought maybe that might fix it, if my issue is even a issue . I don't get that with CGmiiner made by novak .I don't get it, on any other pool with BFG and that stick miner .

[Luke-Jr]

The startup rejects are because they never difficulty for the first job, and don't send a new job for some seconds after you login.
But then they reject shares that meet the initial difficulty (1).

What cgminer does, is to apply the first set_difficulty retroactively to any jobs received without a known share difficulty.
I considered making this change in BFGMiner also, but decided against it, because for a compliant stratum pool (where the initial difficulty is in fact valued as 1), this would result in losing credit for all the shares found against that first job.
On the other hand, for CKPool-based servers, the only downside of BFGMiner's stratum-compliant behaviour is that it counts those shares as rejects.
Unless your pool is penalising you for rejected shares, this shouldn't matter (and if they are, especially when they're at fault for those rejects as is the case here, I suggest using another pool!).

As an aside, CKPool appears to have a bug in stratifier.c line 3112-3114:

Code:

	/* Accept the lower of new and old diffs until the next update */
	if (id < client->diff_change_job_id && client->old_diff < client->diff)
		diff = client->old_diff;

This will cause miners which strictly comply with the stratum spec to have shares at the new difficulty valued only at the old one.
So if the share difficulty adjusts from 1024 to 512 (for example), stratum says shares for the old job should continue to be submitted only if they meet difficulty 1024.
However, CKPool will only "count" those shares as if they were difficulty 512, at half their proper value.
This is a potential loss for miners, but probably insignificantly small.
Given their history of ignoring and/or trolling bug reports from me, I have not bothered to report it. But please feel free to do so if it matters to you.

[Mikestang]

• Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.

Could you please explain how to use this command?  I do not see it in the readme and it does not appear to be a command line option.  Thank you!

I believe you add "/#cksuggest" to the end of the pool URL.

That's how but what does it do ? .  I Don't see were it did any thing on CKpool .

It causes the difficulty request set by '--request-diff' to be sent in the format expected by ckpool, I would imagine.  I have not tried it, but that's what I would expect it to do.

Would someone be able to provide a complete command line example of the proper syntax?  I am unlcear if I need to use --request-diff in concert with /#cksuggest?

Or maybe I'll take a shot and let me know if this is correct?  Using bfgminer to solo mine on cksolo pool would this be correct?

Code:

bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333/#cksuggest -u <user> -p <pass> -request-diff 7

[toptek]

The startup rejects are because they never difficulty for the first job, and don't send a new job for some seconds after you login.
But then they reject shares that meet the initial difficulty (1).

What cgminer does, is to apply the first set_difficulty retroactively to any jobs received without a known share difficulty.
I considered making this change in BFGMiner also, but decided against it, because for a compliant stratum pool (where the initial difficulty is in fact valued as 1), this would result in losing credit for all the shares found against that first job.
On the other hand, for CKPool-based servers, the only downside of BFGMiner's stratum-compliant behaviour is that it counts those shares as rejects.
Unless your pool is penalising you for rejected shares, this shouldn't matter (and if they are, especially when they're at fault for those rejects as is the case here, I suggest using another pool!).

As an aside, CKPool appears to have a bug in stratifier.c line 3112-3114:

Code:

	/* Accept the lower of new and old diffs until the next update */
	if (id < client->diff_change_job_id && client->old_diff < client->diff)
		diff = client->old_diff;

This will cause miners which strictly comply with the stratum spec to have shares at the new difficulty valued only at the old one.
So if the share difficulty adjusts from 1024 to 512 (for example), stratum says shares for the old job should continue to be submitted only if they meet difficulty 1024.
However, CKPool will only "count" those shares as if they were difficulty 512, at half their proper value.
This is a potential loss for miners, but probably insignificantly small.
Given their history of ignoring and/or trolling bug reports from me, I have not bothered to report it. But please feel free to do so if it matters to you.

TY luke kind thought that was why i don't normally use CK pools at all but sense the compac club does i will , no I'm ting my best to not start shit, I'll hate later on and why i said normal so everyone is cool with everyone else. but ty I kind thought what you said is why but for reason i stated i want no hassle from any one . Ive found in my all most 60 years of living some times silence it best .


now one more question  can you or anyone point me in the right direct that can or will explain to me how to add to a firm ware image with updates, it gets old, compiling BFG  after two or three reboots some times after one reboot . no idea why it some times holds thu  2 to 3 reboots then wipes it on the forth or 5 th reboot .  i know it has to be saved to a image and then uploaded as a firmware up date for it to hold but how or were do i look i can't find to much on it . i know i will sooner or later find it , but till then maybe some one can share that ? .
  

[Luke-Jr]

Bitmain published instructions for building firmware images somewhere (sorry, it's been too long; I don't have the link anymore), but I was unable to get them to work on my 32-bit Gentoo system (you may have better luck on a 64-bit Ubuntu).

[toptek]

Bitmain published instructions for building firmware images somewhere (sorry, it's been too long; I don't have the link anymore), but I was unable to get them to work on my 32-bit Gentoo system (you may have better luck on a 64-bit Ubuntu).

I think i found it


btw got BFG working on A s1 and S3 now using openDrt . .

[Luke-Jr]

Bitmain published instructions for building firmware images somewhere (sorry, it's been too long; I don't have the link anymore), but I was unable to get them to work on my 32-bit Gentoo system (you may have better luck on a 64-bit Ubuntu).

I think i found it


btw got BFG working on A s1 and S3 now using openDrt . .

Great news. What is the hashrate like? Same as the original firmware? Better? Worse?

[philipma1957]

BTW, anyone want to go and update README with all these tips I've been dropping on the forum thread(s)? :p

I added info to the U3 section of your readme-asic:

Code:

ANTMINER U3
-----------

The U3 does not support autodetection, so you will want to use --scan-serial to
manually probe it. For example, to scan all devices, you can use:

-S antminer:all --set antminer:chip=BM1382

Additionally, for optimal performance you will need to set voltage, clock, and
timing. Voltage format for the U3 is not documented by the manufacturer, thus
must be provided as hexadecimal configuration codes. Timing is provided in the
number of nanoseconds each hash takes at the given configuration. A
known-working configuration is:

--set antminer:voltage=x800 --set antminer:clock=237.5
--set antminer:timing=0.022421

To set different frequency and voltage settings for multiple U3 miners on a
single BFGMiner process use:

--set antminer@\\.\COM10:voltage=xNNNN

or

--set antminer@/dev/ttyUSB1:voltage=xNNNN

Another option is to program the CP2102 chip so they have unique serial numbers;
this method would avoid problems with the device showing up on different tty/COM
locations after reboot/hotplug:

/cp210x-program -w -F eeprom-content.AntU3-custom.hex --set-product-string='Antminer U3' --set-serial-number=myveryown0001

Then you can use --set antminer@myveryown0001:voltage=xNNNN

I also added the RPC command to adjust frequency to the compac part or readme-asic:

Code:

COMPAC
------

These USB sticks are based on Bitmain's BM1384 chip, and use the antminer
driver. You can set the clock frequency with

--set compac:clock=200

You can also adjust the clock real-time while the stick is hashing using RPC's pgaset:

bfgminer-rpc "pgaset|0,clock,x0982"
		     |       ^^^^^ hex frequency
		     ^ device number

Added a few more suggested uses for --set-device from readme:

Code:

--set-device|--set <arg> Set default parameters on devices; eg, NFY:osc6_bits=50, bfl:voltage=<value>, compac:clock=<value>

mike I have not run bfgminer for the compac sticks can you write a bat file I could cut and paste to get started?

okay I am running 5.4   but I have a repeating error   I am getting hash at the pool but I could use a peek at a bat file for compac sticks

[Mikestang]

My bfg batch file for the compac sticks is:

Code:

bfgminer.exe --api-listen --api-allow W:127.0.0.1 -o <pool> -u <user> -p <pass> -o <failover> -u <failuser> -p <failpass> --set compac:clock=x0982

Adjust the clock value based on the hub you are using.  The api commands are there so I can use RPC to adjust clock real-time.

You can find posts by me earlier in this thread having the same comms error, both with the compac stick and the U3.  I'm not sure what causes it or how to make it go away, I posted more in the compac club thread.

[Mudbankkeith]

If you have ever used CGminer then you will have to "Un-Zadig" your PC

Here is a quick .bat file:-

bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u (user) -p (password) -S antminer --set cbm:clock=x0783

[bmoscato]

The request difficulty still isn't working for me against CK Pool.

bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333 -u 1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.bmoscatosticks -p x -S rockminer:all --set rockminer:clock=280 --set compac:clock=250 --request-diff 48 --api-listen --api-allow W:10.0.0/24

The pool starts at 1k and takes about 5 minutes to normalize and then starts from a low number.  At 7 minutes I went from 1k to 23 and right now at 8 minutes I'm still at a difficulty of 23, not the 48 that I specified.  CG Miner is up and running in less than 15 seconds when I specify a difficulty, it doesn't wait for the ASIC to get to 1000 a few times.

[xyzzy099]

The request difficulty still isn't working for me against CK Pool.

bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333 -u 1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.bmoscatosticks -p x -S rockminer:all --set rockminer:clock=280 --set compac:clock=250 --request-diff 48 --api-listen --api-allow W:10.0.0/24

The pool starts at 1k and takes about 5 minutes to normalize and then starts from a low number.  At 7 minutes I went from 1k to 23 and right now at 8 minutes I'm still at a difficulty of 23, not the 48 that I specified.  CG Miner is up and running in less than 15 seconds when I specify a difficulty, it doesn't wait for the ASIC to get to 1000 a few times.

I think you just need this little change:

bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333/#cksuggest -u 1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.bmoscatosticks -p x -S rockminer:all --set rockminer:clock=280 --set compac:clock=250 --request-diff 48 --api-listen --api-allow W:10.0.0/24

[Edit: Need a '/' before '#cksuggest' actually, I think.]

[bmoscato]

The request difficulty still isn't working for me against CK Pool.

bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333 -u 1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.bmoscatosticks -p x -S rockminer:all --set rockminer:clock=280 --set compac:clock=250 --request-diff 48 --api-listen --api-allow W:10.0.0/24

The pool starts at 1k and takes about 5 minutes to normalize and then starts from a low number.  At 7 minutes I went from 1k to 23 and right now at 8 minutes I'm still at a difficulty of 23, not the 48 that I specified.  CG Miner is up and running in less than 15 seconds when I specify a difficulty, it doesn't wait for the ASIC to get to 1000 a few times.

I think you just need this little change:

bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333#cksuggest -u 1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.bmoscatosticks -p x -S rockminer:all --set rockminer:clock=280 --set compac:clock=250 --request-diff 48 --api-listen --api-allow W:10.0.0/24

Cool, thanks.

[toptek]

Hey  luke

I do have it working on a S1 and S3 but not hashing because it's not enabled by default the problem I'm having not entry sure its the problem , i can't enable it over openWRT, i think that is the only way to get the S1 and S3 enabled and work with all drivers is over openwrt ? like the S5 ? the S5 needs openwrt stuff to work but that controller has tons of space ,but the problem again is the S1/3 controller are not big enough to compile on . it does download all the drivers with openwrt, i did check it shows the bitmain controller with all drivers etc but I can't get it to enable --enable-bitmain on that controller in the BFGMINER file, due to the space on the S1 and S 3 controllers and CPing over the bfgminer file that has it enabled doesn't work it still shows it as not enabled using cp but that file works , is there any way you could enable it for openwrt , i do have a openwrt router coming, i tried to set up a pi as a openwrt file server but that's a pain, it seems routers them self work best,I'm still working on it.



IF that is how to, if not . I will figure it out .


IF im right here is what i get once I use openWRT and it's on the S1/3.

Configuring terminfo.
Configuring libevent2.
Configuring libncurses.
Configuring libmicrohttpd.
Configuring libusb-1.0.
Configuring bfgminer.

the Driver are there ?

but when I do a bfgminer --version  i get  


bfgminer 5.4.0
  Lowlevel: ftdi pci pci:uio spi usb vcom
  Drivers: antminer avalon avalonmm bfx bifury bigpic bitforce bitforce:pci bitury cairnsmore cointerra compac
  drillbit dualminer erupter gridseed hashbusterub hashfast icarus klondike littlefury modminer
  proxy proxy:getwork proxy:stratu rockminer twinfury x6500 zeusminer ztex
  Algorithms: SHA256d scrypt
  Options: ncurses


Shouldn't bitmain be in there some place for it work ? I know it's off by default and has to be complied to enabled. The rest is explained above.

 just making sure the above is why, I'm on the right track .