Bitcoin Forum
December 09, 2016, 07:41:16 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 245090 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 08, 2013, 01:15:54 AM
 #641

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?

1481312476
Hero Member
*
Offline Offline

Posts: 1481312476

View Profile Personal Message (Offline)

Ignore
1481312476
Reply with quote  #2

1481312476
Report to moderator
1481312476
Hero Member
*
Offline Offline

Posts: 1481312476

View Profile Personal Message (Offline)

Ignore
1481312476
Reply with quote  #2

1481312476
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481312476
Hero Member
*
Offline Offline

Posts: 1481312476

View Profile Personal Message (Offline)

Ignore
1481312476
Reply with quote  #2

1481312476
Report to moderator
1481312476
Hero Member
*
Offline Offline

Posts: 1481312476

View Profile Personal Message (Offline)

Ignore
1481312476
Reply with quote  #2

1481312476
Report to moderator
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
March 08, 2013, 01:48:05 AM
 #642

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 08, 2013, 01:54:34 AM
 #643

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?

twobitcoins
Full Member
***
Offline Offline

Activity: 144


View Profile
March 08, 2013, 04:27:51 AM
 #644

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.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 08, 2013, 05:47:30 AM
 #645

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.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 09, 2013, 04:09:08 AM
 #646

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
March 10, 2013, 06:52:19 PM
 #647

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 10, 2013, 07:20:48 PM
 #648

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.

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
March 10, 2013, 08:10:33 PM
 #649

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
edison
Newbie
*
Offline Offline

Activity: 9


View Profile
March 10, 2013, 09:48:11 PM
 #650

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.
.m.
Sr. Member
****
Offline Offline

Activity: 266



View Profile
March 13, 2013, 01:38:27 PM
 #651

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)



███████████████████████████████████████
███████████████████████████████████████
█████████████████████████████
██████████████████████████
████████████████████████
███████████████████████
█████████████████▐████
███████████████████████
████████████████████████
██████████████████████████
█████████████████████████████
███████████████████████████████████████
███████████████████████████████████████
DECENT
FOUNDATION



██
██
██
██
██
██
██
██
██

██
██
██


[D]ecentralized application
[E]liminated third parties
[C]ontent distribution



██
██
██
██
██
██
██
██
██

██
██
██


[E]ncrypted & secure
[N]o borders
[T]imeless reputation



██
██
██
██
██
██
██
██
██

██
██
██



██
██
██
██
██
██
██
██
██

██
██
██

deadweasel
Sr. Member
****
Offline Offline

Activity: 364



View Profile
March 15, 2013, 01:31:27 PM
 #652

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!

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 15, 2013, 06:33:16 PM
 #653

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

xvc
Newbie
*
Offline Offline

Activity: 9


View Profile
March 16, 2013, 07:10:13 AM
 #654

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.
mitty
Sr. Member
****
Offline Offline

Activity: 363



View Profile
March 21, 2013, 11:07:40 PM
 #655

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.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 21, 2013, 11:15:11 PM
 #656

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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
March 21, 2013, 11:30:52 PM
 #657

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.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
mitty
Sr. Member
****
Offline Offline

Activity: 363



View Profile
March 22, 2013, 12:11:49 AM
 #658

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.
jcdem
Newbie
*
Offline Offline

Activity: 8


View Profile
March 22, 2013, 02:56:46 AM
 #659

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
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 22, 2013, 05:08:45 AM
 #660

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!