Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 20. (Read 308659 times)

Thanks for the quick reply.

That's just a fact of life with R-Boxes

I don't seem to have too big of an issue with HW errors.  I am holding steady at .81%.  My biggest concern is that when the Task error appears, my hashrate drops significantly.  The issue seems to crop up every 20 minutes or so.  I am on Ghash as well.  I wonder if it is a network based issue?

-B

I have the same issue on 4.5.0, U1 and U2s run fine, RBOX has a lot of errors.

bfgminer version 4.5.0 - Started: [2014-08-02 20:23:13] - [  7 days 20:04:47]
[M]anage devices [P]ool management [ S ]ettings [D]isplay options  [H]elp [Q]uit
Pool 0: uk1.ghash.io        Diff:32  +Strtm  LU:[16:27:39]  User:bmoscato.worke
Block: ...0def05ee #314950  Diff:19.7G (141.2Ph?)  Started: [16:26:31]
ST:16  F:15  NB:1224  AS:0  BW:[ 42/ 48 B/s]  E:273.15  I:55.18uBTC/hr  BS:6.95
11/14  37.0C | 54.12/54.63/51.98Gh/s | A:255935 R:335+4(.17%) HW:76097/.85%
-------------------------------------------------------------------------------
AMU 0:       |  1.99/ 2.01/ 1.80Gh/s | A:  8846 R:  7+0(.08%) HW:    0/none
AMU 1:       |  2.01/ 2.01/ 1.80Gh/s | A:  8754 R: 10+0(.11%) HW:    0/none
AMU 2:       |  2.02/ 2.01/ 1.80Gh/s | A:  8824 R:  4+1(.41%) HW:    0/none
AMU 3:       |  2.01/ 2.01/ 1.80Gh/s | A:  8847 R:  7+0(.08%) HW:    0/none
AMU 4:       |  2.02/ 2.01/ 1.80Gh/s | A:  8763 R:  9+0(.10%) HW:    0/none
AMU 5:       |  1.99/ 2.01/ 1.80Gh/s | A:  8971 R:  4+0(.04%) HW:    0/none
RKM 0: 37.0C | 33.82/34.52/33.98Gh/s | A:167412 R:272+1(.18%) HW:76097/1.3%
AMU 6:       |  1.98/ 2.01/ 1.79Gh/s | A:  8954 R:  4+1(.40%) HW:    0/none
AMU 7:       |  2.02/ 2.01/ 1.80Gh/s | A:  8866 R:  5+1(.07%) HW:    0/none
AMU 8:       |  2.02/ 2.01/ 1.81Gh/s | A:  8963 R:  7+0(.08%) HW:    0/none
AMU 9:       |  2.03/ 2.01/ 1.80Gh/s | A:  8738 R:  6+0(.07%) HW:    0/none
-------------------------------------------------------------------------------
[2014-08-10 16:27:55] RKM 0c: No task request? Probably lost, resending task 1
[2014-08-10 16:27:56] RKM 0d: No task request? Probably lost, resending task 1
[2014-08-10 16:28:00] Accepted 026f8d71 AMU 4  Diff 105/32
[2014-08-10 16:28:04] Accepted 05fb5b9e RKM 0b Diff 42/32
[2014-08-10 16:28:05] Accepted 0716e8c7 AMU 4  Diff 36/32
[2014-08-10 16:28:05] Accepted 01226e64 AMU 5  Diff 225/32

I am running a R-Box with BFGMiner and getting an error pretty frequently:

"No task Request? Probably lost, Resending task X"    where X can be a 0 or 1. 

I am running 4.6.0 on Windows 7.  I am running a second instance of BFG which is mining with Antminer U2s and I have yet to see the error with those.  Just seems to happen with the R-Box. 

I did some searching and couldn't come up with any fixes.  Any ideas?

-B

Ok, thank you for the quick reply!

Not supported nor planned.
Patches welcome.

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.

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

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*".

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

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!

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.

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?     

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.

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.

Thanks nwools, will try again

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


There's also some scripts to help get started:


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

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?

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

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?