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

[xyzzy099]

I have a handful of miscellaneous old mining hardware (10 block erupters, 1 Jalapeno, and 2 BE Blades) with a total of about 30GH running in one instance of BFGMiner (pulled from git a few days ago, version visible in the screenshot below), and this morning I noticed that the mining rate was displaying in TH, instead of the usual GH.  I have seen this before once, when I solo-mined a block with this same HW about 15 hours after starting to mine - but in this case, no block was mined.  I figured that maybe one of the devices had submitted a very high-diff share that got rejected, but this does not seem to be the case either.

In the screen shot below, taken some time after the 'event', you can see that the BES7 device is apparently the one that generated a high share (its rate is displayed in TH while all the others are in GH or MH), but looking at the log, I don't see ANY indication of that device generating a big share, neither accepted nor rejected:




LOG SNIPPET -  All it shows is a share of 55/32 by PXY 1 (a BE Blade), then the rate changes to EH from GH with no indication on any share generated by BES 7:

 [2014-07-31 05:45:19] 5s:25.49 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104175/3.9%
 [2014-07-31 05:45:24] 5s:25.24 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104175/3.9%
 [2014-07-31 05:45:29] 5s:29.01 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104176/3.9%
 [2014-07-31 05:45:34] 5s:27.39 avg:30.21 u:28.65 Gh/s | A:51983 R:926+15(1.3%) HW:104176/3.9%
 [2014-07-31 05:45:35] Accepted 049e34be PXY 1  pool 2 Diff 55/32
 [2014-07-31 05:45:39] 5s: 1.43 avg: 0.00 u: 0.00 Eh/s | A:51984 R:926+15(1.3%) HW:104177/3.9%
 [2014-07-31 05:45:44] 5s:873.2 avg: 0.05 u: 0.00 Ph/s | A:51984 R:926+15(1.3%) HW:104178/3.9%
 [2014-07-31 05:45:49] 5s:534.7 avg: 0.05 u: 0.00 Ph/s | A:51984 R:926+15(1.3%) HW:104180/3.9%
 [2014-07-31 05:45:52] Accepted 0325d931 PXY 0  pool 2 Diff 81/32
 [2014-07-31 05:45:54] Accepted 0083bd86 BFL 0  pool 2 Diff 497/32
 [2014-07-31 05:45:54] 5s:327.4 avg: 0.05 u: 0.00 Ph/s | A:51985 R:926+15(1.3%) HW:104182/3.9%
 [2014-07-31 05:45:59] 5s:200.5 avg: 0.05 u: 0.00 Ph/s | A:51986 R:926+15(1.3%) HW:104182/3.9%

Can anyone explain to me how this can happen?  Did I lose a potentially block-solving share due to a bug?

[1714172870]

1714172870

[1714172870]

1714172870

[1714172870]

1714172870

[1714172870]

1714172870

[wolf_miner]

Hi, I have a TP Link 703N (with LAv 3 Firmware) and I want to upgrade the firmware with the latest 703N BFGMiner 4.5 firmware, which firmware I have to load bfgminer-ar71xx-generic-tl-wr703n-v4.5-r1-squashfs-factory.bin or bfgminer-ar71xx-generic-tl-wr703n-v4.5-r1-squashfs-sysupgrade.bin.

Thanks in advance W_M

[nwoolls]

Hi, I have a TP Link 703N (with LAv 3 Firmware) and I want to upgrade the firmware with the latest 703N BFGMiner 4.5 firmware, which firmware I have to load bfgminer-ar71xx-generic-tl-wr703n-v4.5-r1-squashfs-factory.bin or bfgminer-ar71xx-generic-tl-wr703n-v4.5-r1-squashfs-sysupgrade.bin.

Thanks in advance W_M

The factory.bin is for doing an install of OpenWrt while the sysupgrade.bin is for upgrading an existing installation. If you are able to SSH into the 703n, you can SCP the sysupgrade.bin file into the /tmp directory and then run sysupgrade on it. More info here:

http://wiki.openwrt.org/doc/howto/generic.sysupgrade

If you are not able to SSH into the device you can follow these instructions to reset it:

http://wiki.openwrt.org/toh/tp-link/tl-wr703n

[wolf_miner]

Thanks nwoolls , i try to install the new firmware but the old firmware has ssh acces locked so the only way is to load the new firmware from the user interface but it isn't recognised as valid. This evening i will try with the serial interface to gain the boot sequence and force system access.

Thankds W_M

[suzukii]

Hi all.  

I'm still at it with the random no-hashing issue I keep having everyday with my Raspberry Pi & now 8 Gridseed G-blades, up from 6 G-blades, new 6FT USB Cables (down from 10 & 15 footers).  And again, I even replaced the hub with a new Turcom 24 Port USB 2.0 Monster USB HUB W/ac Adapter Power Station.

I'm still not sure if this is a BFGminer issue with too many G-blades or not.  
However, it works fine with up to 5 G-blades.

I updated BFGminer to the latest version, as of this writing, to v4.5.0.

I don't know what else to do.

I get the same thing using Multiminer with bfgminer.  It's always a different G-blade that stays stuck on zero, always & only using BFGminer since all I do is LTC mine with these.

Any suggestions?

I have only 2 g-blades running but i seen this often before, the only way i could get the 0 hashing away was after i turned power off on the failing one and power it back up.
But i am not sure if it would work for you, my gridseeds was from early batches and allways been a pain in the behind to get and keep them running.

I stopped buying from zeusminer and gridseed since i do not really like how these companies handle problems they caused.
A defect gridseed blade blew up a 1500 dollar pc and they simply stay silent nor respond to this issue.
Zeusminer send me some small miners which are crap because of the brutal handling by packaging or transport but they act exactly like minereu indeed nothing.

Hy Bronan.

I hear ya.  Unfortunately, unplugging the device only kills the hashing for me on the other board in the g-blade that is hashing away.  The funky stuff is that it happens randomly to other miners on every reboot.  It's never the same gridseed twice.
I've sort of settled with the idea that out of 8 G-blade miners I can live with 7.5 G-blades mining.

[Luke-Jr]

NEW VERSION 4.6.0, AUGUST 2 2014

Human readable changelog:

• avalonmm: New driver for both Avalon2 and Avalon3 rigs.

Full changelog:

• avalonmm: Even if no fans report speed, display set %
• Bugfix: avalonmm: Fix fan speed setting
• Bugfix: avalonmm: Actually read the result needed to get the correct module id
• README.ASIC: Document AvalonMM driver usage with Avalon 2/3 rigs
• Bugfix: Makefile.am: Remove reference to non-existent driver-avalonmm.h
• avalonmm: Safely handle an improper job id that is within the last 2 sent
• avalonmm: Include asserted fan speed in RPC
• avalonmm: Include asserted fan speed in ManageTUI
• avalonmm: Silence warning about detect ack at runtime
• avalonmm: Make fan speed an option (both RPC and TUI)
• avalonmm: Allow changing clock speed and voltage from Manage TUI
• Bugfix: avalonmm: Show proper units for fans & voltage
• avalonmm: Support for disabling the entire chain
• Implement broad_udevrules for avalonmm
• avalonmm: Show extranonce1, module id, temperatures, fans, clock, and voltage in Manage TUI
• avalonmm: Include Module Id and ExtraNonce1 in RPC devdetails
• avalonmm: Add Temperature0/1 and Fan Percent 0/1 to RPC
• avalonmm: Add Frequency and Voltage to RPC
• avalonmm: Add voltage setting (defaults to 0.6625 V)
• avalonmm: Add clock setting and try to autodetect it if not provided
• avalonmm: Implement hashmeter
• avalonmm: Adjust device target up to pdiff 32 when possible
• avalonmm: Update job when current pool changes
• Bugfix: avalonmm: MM flips the xnonce2, so we need to do the same
• avalonmm: Implement mining logic
• lowl-spi: Move bit order reverse to bitflip8 function in util
• avalonmm: Treat multiple chained modules as slaves rather than processors
• avalonmm: Probing for devices using Avalon Miner Manager (Avalon2/3 rigs)
• littlefury: Move crc16 logic to util
• Use BUILT_SOURCES to ensure version.h is always built first
• configure option --with-udevrules-group to allow customising the group name used
• Bugfix: zero_stats: Only call cgpu function if it exists
• Remove FPGA-only bitforce-firmware-flash tool (now located at https://github.com/luke-jr/bitforce-fpga-firmware-flash )

[zyberguy]

Oh look like I am in trouble. I just flash sysupgrade under openwrt web infterface (luci).
Now my wr703 cannot access via lan or wlan. How should I recover it?

[zyberguy]

Found the way to unbrick with serial console. Now try to start flashing your firmware

[zyberguy]

After sysupgrade to your firmware. I cannot find bfgminer (or I missing something?).
When revert back to openwrt and manually install bfgminer, it ran out of space.
Any advice?

[nwoolls]

After sysupgrade to your firmware. I cannot find bfgminer (or I missing something?).
When revert back to openwrt and manually install bfgminer, it ran out of space.
Any advice?

After you install the firmware BFGMiner is there. Not sure what went wrong:

Code:

root@OpenWrt:~# which bfgminer
/usr/bin/bfgminer

There's also some scripts to help get started:

Code:

root@OpenWrt:~# ls /usr/bin/mine*sh
/usr/bin/mine-scrypt.sh  /usr/bin/mine-sha2.sh

You'll want to edit the credentials in the shell scripts but they should be a starting point.

[zyberguy]

Thanks nwools, will try again

[v0n]

I'm still at it with the random no-hashing issue I keep having everyday with my Raspberry Pi & now 8 Gridseed G-blades, up from 6 G-blades, new 6FT USB Cables (down from 10 & 15 footers).  And again, I even replaced the hub with a new Turcom 24 Port USB 2.0 Monster USB HUB W/ac Adapter Power Station.

I have only 2 g-blades running but i seen this often before, the only way i could get the 0 hashing away was after i turned power off on the failing one and power it back up.

minerd written by siklon (cpuminer-gc3355 v1.0e) has by far the best and most reliable built in automatic method of soft resetting stale chips, it's controlled via --gc3355-timeout switch, you just specify number of seconds after no share is submitted before restarting chips, in my experience works every time and it has yet to let me down.

[nwoolls]

I'm still at it with the random no-hashing issue I keep having everyday with my Raspberry Pi & now 8 Gridseed G-blades, up from 6 G-blades, new 6FT USB Cables (down from 10 & 15 footers).  And again, I even replaced the hub with a new Turcom 24 Port USB 2.0 Monster USB HUB W/ac Adapter Power Station.

I have only 2 g-blades running but i seen this often before, the only way i could get the 0 hashing away was after i turned power off on the failing one and power it back up.

minerd written by siklon (cpuminer-gc3355 v1.0e) has by far the best and most reliable built in automatic method of soft resetting stale chips, it's controlled via --gc3355-timeout switch, you just specify number of seconds after no share is submitted before restarting chips, in my experience works every time and it has yet to let me down.

The problem with this is that there is no way to know ahead of time what the pool difficulty is and how long it should take to find a share (unless a non-vardiff pool and you are doing the math). You could be resetting the device too soon, or waiting too long.

There is a feature in the works for BFGMiner that does something similar, only it is based directly on the difficulty of the pool and works without additional arguments.

[v0n]

The problem with this is that there is no way to know ahead of time what the pool difficulty is and how long it should take to find a share (unless a non-vardiff pool and you are doing the math). You could be resetting the device too soon, or waiting too long.

There is a feature in the works for BFGMiner that does something similar, only it is based directly on the difficulty of the pool and works without additional arguments.

Neat approach, but maybe the issue doesn't really need that much over engineering - even at extreme pool difficulty, if the module/chip/serial (whichever is used to send jobs to the blade) doesn't produce anything in 120 or 180 seconds (or even extreme - 300 seconds), it can be safely assumed as dead, you kind of want it reset, right? Or am I misunderstanding the issue?     

[zyberguy]

After trouble with network configuration on openwrt (no luci is very difficult to manage).
Finally I can run wr703n bfgminer with 2 zeusminer blizzardX3 

https://dl.dropboxusercontent.com/u/14091495/Screen%20Shot%202557-08-07%20at%2003.50.52.png

Anywhere, how can I fixed the IP on openwrt firmware with gateway (I let DHCP solve this problem).
First time I config it in/etc/config/network with ip 192.168.3.3 and route 0.0.0.0 to gw 192.168.3.1
I cannot access the router via lan. Thanks for serial cable, I remove the setting,and back to original.
Now I use proto 'dhcp' on network configuration.

[patrike]

I'm currently working on adding support for BfgMiner in the Windows GUI application Awesome Miner (currently only Cgminer/Sgminer supported). I've been getting this request from several users, so I think BfgMiner is quite popular out there.

I've been reading the Readme.RPC file to try to figure out what the API differences are between CfgMiner and Cgminer, but I'm not sure if I have a full understanding yet.

What I can see is that instead of reporting GPU as a device type, it is reporting as PGA, with name "OCL". I can also see that several GPU commands (like gpudisable) are deprecated, but they are still working. ASIC commands like ascdisable doesn't exist. Is it that all devices (GPU, PGA, ASIC) are reported as PGA and that the PGA commands (pgadisable, ...) can be used on all of them?

Is GPU mining something that will be removed from future releases of BfgMiner, as commands like gpuengine are deprected without any replacements?

Unfortunately I don't have access to any ASIC running BfgMiner at the moment, so I can only do tests with GPU mining right now.

If there are additional documentation you recommend me to read, just let me know. Thanks!

[Luke-Jr]

What I can see is that instead of reporting GPU as a device type, it is reporting as PGA, with name "OCL". I can also see that several GPU commands (like gpudisable) are deprecated, but they are still working. ASIC commands like ascdisable doesn't exist. Is it that all devices (GPU, PGA, ASIC) are reported as PGA and that the PGA commands (pgadisable, ...) can be used on all of them?

Yes, "PGA" is at this point just a generic term for "device" for cgminer compatibility.
BFGMiner also support per-processor level details which you can get with the "proc*" commands instead of "pga*".

Is GPU mining something that will be removed from future releases of BfgMiner, as commands like gpuengine are deprected without any replacements?

No plans to remove GPU support, but gpuengine and similar were replaced with pgaset a while ago.

[patrike]

What I can see is that instead of reporting GPU as a device type, it is reporting as PGA, with name "OCL". I can also see that several GPU commands (like gpudisable) are deprecated, but they are still working. ASIC commands like ascdisable doesn't exist. Is it that all devices (GPU, PGA, ASIC) are reported as PGA and that the PGA commands (pgadisable, ...) can be used on all of them?

Yes, "PGA" is at this point just a generic term for "device" for cgminer compatibility.
BFGMiner also support per-processor level details which you can get with the "proc*" commands instead of "pga*".

Is GPU mining something that will be removed from future releases of BfgMiner, as commands like gpuengine are deprected without any replacements?

No plans to remove GPU support, but gpuengine and similar were replaced with pgaset a while ago.

Many thanks for your fast reply - I think I have all information needed to continue with the implementation.

[Regeth]

I was wondering, which version if any of BFGMiner that will allow me to mine SHA256 with a 5 chip Gridseed? I perfer BFGMiner over CGminer and I have it working at lest for scrypt. I'm currently using a Rasberry Pi, latest version of Wheezy and followed all the guides I can fine to compile BFG.

[Luke-Jr]

I was wondering, which version if any of BFGMiner that will allow me to mine SHA256 with a 5 chip Gridseed? I perfer BFGMiner over CGminer and I have it working at lest for scrypt. I'm currently using a Rasberry Pi, latest version of Wheezy and followed all the guides I can fine to compile BFG.

Not supported nor planned.
Patches welcome.