Luke, BFL's updated protocol document 2.2.0 (March) added ‘Z0X’ to ‘Z5X’ FAN control commands. Any plans to support these in BFGMiner? Run-time fan speed control for these devices would be a nice feature.

Achieving stable and efficient mining should, of course, be a primary focus. Fan control is secondary, but keep it on your radar. Users operating in noise-sensitive environments would find this a useful and more practical alternative to replacing the stock fans. Ideally BFL's 'smart' fan control will turn out to be quiet enough but, if not, I'll bring this up again.

The simplest initial implementation might be a command-line parameter that sets the fans to all BFL SC devices at launch (to Z0, Z1, Z2, Z3, Z4, or Z5). Fancier per-device control during run-time and/or API can always come later.

Hi, after some time I am testing mining again - similar setup, new GPU.
I am not able to lower gpu mem clock, it always jumps to 1200 when I enter a different value (and it hungs soon).
Another guy mentioned, he achieves around 300Mh/s with 1050 MHz gpu eng and 600 gpu mem clk with GUIminer(windows)-and his temps are around 55 C(two fans).
Would anybody have an idea what can I do to improve hash speed ?
Thanks a lot !
.m.

Linux Fedora Core 16 x64, MSI 7850 (only one fan
bfgminer from git:

 bfgminer version 2.99.1 - Started: [2013-03-12 17:30:29] - [  0 days 20:59:22]
--------------------------------------------------------------------------------
 5s:233.0 avg:228.6 u:228.2 Mh/s | A:4014 R:48 S:0 HW:0 U:3.2/m
 ST: 1  DW: 25  GW: 994  LW: 99863  GF: 0  NB: 138  AS: 0  RF: 18  E: 0.15
 Connected to mining.eligius.st diff 1 with LP as user 12jNbMzoBGLcKa7qY45gbcDfG
 Block: ...285b47c2 #225650  Diff:4.37M  Started: [14:25:53]  Best share: 5.02k
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [ S ] ettings [D]isplay options [Q]uit
 OCL 0:  68.0C 2039RPM | 233.2/228.6/228.2Mh/s | A:4014 R:48 HW:0 U:3.19/m
--------------------------------------------------------------------------------

Driver reports success but check values below
Temp: 67.0 C
Fan Speed: 45% (1988 RPM)
Engine Clock: 1120 MHz
Memory Clock: 1000 MHz
Vddc: 1.210 V
Activity: 63%
Powertune: 0%
Fan autotune is enabled (0-85)
GPU engine clock autotune is disabled (900-1120)

Perfectly normal on sratum pools

Sorry if this is a dumb question because it seems like I must be missing something obvious but...
Is there a way to query the overall 5s speed average via the API?  I want to write a script that periodically queries bfgminer to make sure it's still mining, and restart it if not.  Right now I'm sending the "summary" command and making sure the work utility is over a predefined threshold.  I'd like to just make sure the 5s average speed isn't 0, and restart if it is.  Any field that gives a (relatively) instantaneous status of mining/waiting would work but I couldn't seem to find it.

Also sort of related but... does anyone running BFL singles have issues where some units don't show up after killing and restarting bfgminer?  Power cycling the BFLs then restarting bfg seems to work but I sadly don't yet have a network controlled outlet.

I use cgminer but I assume bfgminer provides the information I parse too (I think it forked after I configured my monitoring scripts).

You can check the total hashes produced by your miner with:


I use it to monitor the hashrate and warn me if there is a noticeable drop.

Been seeing this problem come up a couple times per day for a couple months now. Either one of my cards will get stuck in a "REST" state and seemingly won't come out of it until I restart the miner. Any idea what's going on here? Also, why does the card opposite of the one in REST mode have the idle temperature?

http://i45.tinypic.com/a40k83.png

Thanks, I think I got them swapped to the correct order now with --gpu-map 0:1,1:0

I am guessing the REST issue is the card shutting down due to the overclocking and/or intensity level set to 5 on a computer that I actually use constantly. Weird that it's been fine for almost a year until now.

The REST was because it saw the temperature too high and was trying to cool it off - but since it had the mapping wrong, it actually shut off the wrong card, and the overheating one never cooled...