Pages:
Author

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

sr. member
Activity: 246
Merit: 250
Team Heritage Motorsports
Look at them temp, very obvious
newbie
Activity: 8
Merit: 0
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.
legendary
Activity: 2576
Merit: 1186
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?


This suggests an ADL mapping problem. Check out README.
newbie
Activity: 8
Merit: 0
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
sr. member
Activity: 359
Merit: 250
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:

Code:
echo -n summary | netcat localhost 4028 | cut -d\| -f 2 | cut -d, -f16 | cut -d= -f2

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

Awesome, thanks.  I didn't think about doing it that way before.
hero member
Activity: 896
Merit: 1000
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:

Code:
echo -n summary | netcat localhost 4028 | cut -d\| -f 2 | cut -d, -f16 | cut -d= -f2

I use it to monitor the hashrate and warn me if there is a noticeable drop.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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.
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.
sr. member
Activity: 359
Merit: 250
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.
xvc
newbie
Activity: 9
Merit: 0
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.
legendary
Activity: 2576
Merit: 1186
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!

Perfectly normal on sratum pools
sr. member
Activity: 364
Merit: 250
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!
.m.
sr. member
Activity: 280
Merit: 260
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 Sad
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)

newbie
Activity: 11
Merit: 0
Hi Luke,

I just cobbled together a new miner and I'm getting the following errors constantly:
Code:
OCL 0: invalid nonce - HW error

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:
Code:
libGL: AtiGetClientDriverName: 9.1.11 fglrx (screen 0)

...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.
legendary
Activity: 922
Merit: 1003
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.
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.
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.
legendary
Activity: 2576
Merit: 1186
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.
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.
legendary
Activity: 922
Merit: 1003
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
Looks like a real bug, thanks. Will fix it upstream.
legendary
Activity: 2576
Merit: 1186
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);".
Good find.

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.
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).

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.
The Icarus/ModMiner usage never frees the structure containing the work, so they're cleaned implicitly whenever __copy_work goes to replace them.
full member
Activity: 144
Merit: 100
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.
legendary
Activity: 2576
Merit: 1186
I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.
Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.
What device(s), pool(s) etc? Can you post a debug.log somewhere?
I'm using the following command line (user and pass obfuscated):
Code:
bfgminer ^
-o http://us.ozco.in:3333 -u uuu -p ppp ^
-o http://mint.bitminter.com:8332 -u uuu -p ppp ^
-o http://us3.eclipsemc.com:3333 -u uuu -p uuu ^
-o http://api.bitcoin.cz:8332 -u uuu -p uuu ^
--disable-gpu --no-submit-stale ^
-S all
Debug output here: http://pastebin.com/gj9LnKid

Using the same command line, 2.99.0 uses 0% cpu but 2.99.1 uses 100%. The pastebin output is from bfgminer 2.99.1. This is a system with 2 BFL Singles only.
Can you meet up with me on IRC for some more aggressive investigation?
Pages:
Jump to: