Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 4. (Read 260061 times)

Look at them temp, very obvious

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.

This suggests an ADL mapping problem. Check out README.

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

Awesome, thanks.  I didn't think about doing it that way before.

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.

The 'devs' - 'Last Valid Work' is the best measure of a working device.
It represents the last time the device returned a valid nonce (independent of difficulty or anything else that may ignore valid work)
But ... you need to use the original to get that.

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.

Hi

I'm using 2.99 with Asus 7970 and one Ztex.
In configuration I have 0-80 % fan speed for gpu.
I've noticed that after start of bfgminer fans run on 80 %.
But if i change manually in bfgminer fans speed for the same value (0-80) - fans slow.

Perfectly normal on sratum pools

Hi Folks, I'm not sure if this is an issue or not.  I get a lot of "Stratum from pool 0 requested work restart" when on us.ozco.in:3333.  Here's a screen:

http://imgur.com/b6p3NKN



I'm using a  ATI 6770 @ .95 volts, reduced engine and memory to keep my temp around 68C.  BFGminer is a wonderful tool, but I'm not sure I am using it correctly.

Does anyone have any input?

Thanks!

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)

Hi Luke,

I just cobbled together a new miner and I'm getting the following errors constantly:

While the GPU's obviously working on something, it's not generating any (useful) hashes. I'm running bfgminer 2.10.5 on Ubuntu 12.04.2 LTS Precise Pangolin with a single Radeon 6950.

fglrxinfo reports:

...and I'm using APPSDK v2.8.

Is this an actual hardware error, or a driver/SDK issue? The FAQ recommends SDK v2.4. Will 2.4 work with the latest drivers?

Thanks.

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.

I wasn't planning on acting on these commands until after the 3.0 release (to avoid delays needed for testing properly), but maybe I can expose a simple "change the fans" in the RPC.

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.

Looks like a real bug, thanks. Will fix it upstream.

Good find.

Immediately before __copy_work, it initializes *pcd. Per the C standard, any unnamed field is initialized to 0 this way (and calloc has some potential portability problems, since it initializes byte-for-byte; eg, null-byte floats might not be zero on some platforms).

The Icarus/ModMiner usage never frees the structure containing the work, so they're cleaned implicitly whenever __copy_work goes to replace them.

The code in findnonce.c leaks the contents of work structures.  It seems that postcalc_hash() should call "clean_work(&pcd->work);" before "free(pcd);".  Also, postcalc_hash_async should use calloc instead of malloc, otherwise when it calls __copy_work which calls clean_work, there is a risk that clean_work will try to free uninitialized pointers.

This problem likely exists elsewhere in the code.  Several other source files use __copy_work but not clean_work, which is suspicious.  Perhaps it would be safer for all work structures to be allocated on the heap with make_work rather than embedded in other structures.

Can you meet up with me on IRC for some more aggressive investigation?