(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 24.

meebs

hero member

Activity: 616

Merit: 500

Quote from: purelithium on September 22, 2012, 01:17:30 PM

Luke-Jr: I'm seeing high CPU usage with BFGMiner. I use it on my system with my 6870 and 7770. I thought it was high before when I was using the IGP, but since I've turned that off, the CPU usage is still at 50%. I use Win7 64bit. Any ideas?

don't put intensity any higher than 9.

on cgminer it had the same issue, using cpu at intensities above 9, but it would drop mhash about 10-15% when dropping intensity down to 9

on bfgminer I noticed I still get full mhash but 0-1% cpu usage when using intensity 9.

give that a try, it should work. This was an issue for me and the above trick worked.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: burger on September 27, 2012, 09:09:35 AM

Quote from: Luke-Jr on September 27, 2012, 06:12:04 AM

Quote from: burger on September 27, 2012, 05:59:06 AM

Quote from: Luke-Jr on September 27, 2012, 01:17:22 AM

Quote from: burger on September 27, 2012, 01:10:35 AM

Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?

You can do that from the GPU menu as well...

Thanx!

Is there a way for BFGMiner to do all the queued work (and not pulling more work) and then quit when done?

Not right now... open an Issue with a use case if this is important to you

It's not important to me, but maybe to pool operators that are maybe waiting (I dunno for how long till it sends the work to another miner) for the queued work while the miner is using the gpu for gaming or other stuff.

I don't think any pools have any expectation that all work issued will be used...

burger

full member

Activity: 195

Merit: 100

Quote from: Luke-Jr on September 27, 2012, 06:12:04 AM

Quote from: burger on September 27, 2012, 05:59:06 AM

Quote from: Luke-Jr on September 27, 2012, 01:17:22 AM

Quote from: burger on September 27, 2012, 01:10:35 AM

Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?

You can do that from the GPU menu as well...

Thanx!

Is there a way for BFGMiner to do all the queued work (and not pulling more work) and then quit when done?

Not right now... open an Issue with a use case if this is important to you

It's not important to me, but maybe to pool operators that are maybe waiting (I dunno for how long till it sends the work to another miner) for the queued work while the miner is using the gpu for gaming or other stuff.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: burger on September 27, 2012, 05:59:06 AM

Quote from: Luke-Jr on September 27, 2012, 01:17:22 AM

Quote from: burger on September 27, 2012, 01:10:35 AM

Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?

You can do that from the GPU menu as well...

Thanx!

Is there a way for BFGMiner to do all the queued work (and not pulling more work) and then quit when done?

Not right now... open an Issue with a use case if this is important to you

burger

full member

Activity: 195

Merit: 100

Quote from: Luke-Jr on September 27, 2012, 01:17:22 AM

Quote from: burger on September 27, 2012, 01:10:35 AM

Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?

You can do that from the GPU menu as well...

Thanx!

Is there a way for BFGMiner to do all the queued work (and not pulling more work) and then quit when done?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

NEW VERSION 2.8.1, SEPTEMBER 27 2012

2.8.0 worked out pretty well, but there's always more to do...

Cairsmore owners, please help test BFGMiner with Glasswalker's latest "HashVoodoo" firmware: it should frequency scale sanely, and the RPC API's new "identify" function should make its LED blink for 5 seconds. But there hasn't been much testing, so be prepared to switch back to another firmware if it doesn't work. Either way, please let me know how it goes.

Windows binaries have been updated to use stripped, self-compiled libraries; this should reduce the disk size a little and shut up broken antivirus software that doesn't like the official pdcurses.dll build.

Human readable changelog:

Many improvements for Enterpoint's Cairsmore, ~~including (experimental) support for Glasswalker's dynamic frequency bitstream.~~
New --coinbase-sig option that lets you embed a short tidbit in any blocks you personally find (only on GBT-enabled pools).
Generic dynamic clocking framework based on the Ztex driver's (written by nelisky), now used by ModMiner and (Glasswalker) Cairnsmore.
New RPC "identify" command to flash LEDs on some FPGAs (currently BitForce and GW Cairnsmore).
Include share difficulty information in log and RPC.
Lots of other various bugfixes and small improvements.

Full changelog

cairnsmore: Implement "identify" for supported firmware
Adjust identify_device API to return a bool whether supported or not, for runtime capability detection
Bugfix: cairnsmore: Fix invalid share detection on LE
Bugfix: icarus: Fix logging message to not assume "Icarus" always, and use device driver name
Bugfix: cairnsmore: Correct frequency scaling detection logic
cairnsmore: When changing frequency, adjust Hs expectations accordingly
cairnsmore: Detect availability of frequency scaling, and only enable it when supported
cairnsmore: Implement dynamic clocking support for Glasswalker's bitstream
Update libblkmaker to 0.1.1
Advertise BFGMiner in blocks found by default (without --coinbase-sig)
RPC: Add "Coinbase-Sig" to config/setconfig
New --coinbase-sig option to add arbitrary data to blocks you generate (GBT only)
opencl: Defer nonce validity checking to submit_nonce
scrypt: Implement test_nonce2 and submit_nonce hw error check
Bugfix: modminer: Convert nonce to native endian
Interpret any attempts to submit a H-not-zero nonce as a hardware error
make-release: Strip DLLs and EXE in Windows binary
dynclock: Use consistent messages for frequency changes
modminer: Port to dynclock
dynclock: Split dynamic clocking algorithm out of Ztex driver
Bugfix: When changing GPU memclock, adjust internal variable so it is correctly saved to config file
Bugfix: Re-probe longpoll header for each pool alive check, including retries when a preferred protocol fails
Bugfix: modminer: Bitstream binary filenames are *.bit
modminer: Start frequency off at 200 Mhz
Reorder libztex header include order to fix missing struct definition.
Display share difficulty on log with a shortened hash display on submission.
API stats add some pool getwork difficulty stats
Ignore any pings pushed to the worker threads if the thread is still paused to prevent it being enabled and disabled repeatedly.
Test for sequential getwork failures on a pool that might actually be up but failing to deliver work as we may end up hammering it repeatedly by mistake.
reduce windows compile warnings
util.c - bug - proxy - no data end condition
API don't change 'Diff1 Shares' - backward compatability FTW
miner.php highlighting correctly handling difficulty
API - Add last share difficulty for devices and pool
Store and report Accepted,Rejected,Stale difficulty in the summary and API
WorkTime - display prevblock for scrypt
api.c remove compile warnings
Calculate work difficulty for each getwork and display with WorkTime debug
FPGA - allow long or short device names in detect code + style police
WorkTime - multiple nonce per work and identify the work source
Optional WorkTime details with each Accepted/Rejected work item
Icarus - ignore hardware errors in timing mode
miner.php oops - mistype
API pgaidentify - unsupported message should be a warning
API/BFL identify a device - currently only BFL to flash the led
BFL add throttle count to internal stats + API
BFL: missing device id in log message
Bugfix: ztex: Clear device_ztex before freeing it
Bugfix: ztex: statline existence depends on whether the libztex structure exists, not whether the cgpu is enabled
Bugfix: README: Make usermod commands consistent, including important -a option
Bugfix: Address a couple of rare TQ leaks, and improve logging a bit
Bugfix: Properly quote configure options

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: burger on September 27, 2012, 01:10:35 AM

Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?

You can do that from the GPU menu as well...

burger

full member

Activity: 195

Merit: 100

Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?

purelithium

hero member

Activity: 504

Merit: 500

Ahh thanks! I misunderstood the usage of that flag, then.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: ?? on ??

Is there a way I can throttle back the GPU mining for times when I am gaming,

The GPU menu has options to change intensity. As purelithium mentioned, there is also dynamic intensity mode.

Quote from: ?? on ??

and/or just let the BFL singles run without accessting the graphics card's GPU?

The -G option will inhibit using GPUs.

Quote from: purelithium on September 26, 2012, 06:01:10 PM

Also, Luke-Jr: I'm using some flags and it appears they are conflicting.

I have 1 7970, the Integrated 6550D, and a MMQ on the same system. BFGMiner lists them as OCL 0, OCL 1, and MMQ 0 respectively. I want to disable OCL 1, as it's not worth the electricity to mine on it.

I execute bfgminer.exe -d 0 -S modminer:\\.\COM3

In my mind, this should result in BFGMiner using OCL 0 and MMQ 0 and disabling OCL 1. In reality, this results in MMQ 0 and OCL 1 being disabled, with only OCL 0 enabled and mining. What's the fix to get the OCL devices and MMQ to play nice?

-d 0 selects only the 0th device: OCL 0. If you want OCL 0 and MMQ 0, you need -d0 -d2; you can easily see the device numbers at a glance with -d?

purelithium

hero member

Activity: 504

Merit: 500

Quote from: ?? on ??

Is there a way I can throttle back the GPU mining for times when I am gaming, and/or just let the BFL singles run without accessting the graphics card's GPU?

thank you

Using an intensity of "d" should accomplish this. This dynamically adjusts the intensity based on your usage of the device other than mining. If this doesn't work well, then you'll just have to manually shut down your miner whenever you want to game.

Also, Luke-Jr: I'm using some flags and it appears they are conflicting.

I have 1 7970, the Integrated 6550D, and a MMQ on the same system. BFGMiner lists them as OCL 0, OCL 1, and MMQ 0 respectively. I want to disable OCL 1, as it's not worth the electricity to mine on it.

I execute bfgminer.exe -d 0 -S modminer:\\.\COM3

In my mind, this should result in BFGMiner using OCL 0 and MMQ 0 and disabling OCL 1. In reality, this results in MMQ 0 and OCL 1 being disabled, with only OCL 0 enabled and mining. What's the fix to get the OCL devices and MMQ to play nice?

Thanks!

purelithium

hero member

Activity: 504

Merit: 500

https://github.com/luke-jr/bfgminer/issues/131

That is the same issue I've seen after doing a little testing.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: purelithium on September 22, 2012, 01:17:30 PM

Luke-Jr: I'm seeing high CPU usage with BFGMiner. I use it on my system with my 6870 and 7770. I thought it was high before when I was using the IGP, but since I've turned that off, the CPU usage is still at 50%. I use Win7 64bit. Any ideas?

Can you open an issue with the full details of your setup (hardware, config, BFG version, etc)?

purelithium

hero member

Activity: 504

Merit: 500

Luke-Jr: I'm seeing high CPU usage with BFGMiner. I use it on my system with my 6870 and 7770. I thought it was high before when I was using the IGP, but since I've turned that off, the CPU usage is still at 50%. I use Win7 64bit. Any ideas?

ssateneth

legendary

Activity: 1344

Merit: 1004

Did you ever think it was a false positive? Whitelist the file and move on.

burger

full member

Activity: 195

Merit: 100

Quote from: burger on September 20, 2012, 05:07:51 PM

Quote from: Luke-Jr on July 27, 2012, 12:31:29 PM

Quote from: cdhowie on July 27, 2012, 09:15:52 AM

Quote from: cdhowie on July 27, 2012, 01:42:44 AM

I have sent it in already... though in my experience they usually don't do much without contact from someone involved in the production or compilation of the software. :/

Quote

AVG Research Lab has analyzed the file(s) you have sent from your AVG Virus Vault. Below you can find the results for each file. The final verdict on the file is either a correct detection or a false positive detection.

Further information about the verdicts are available at our website:
http://www.avg.com/faq-1184

"c:\Users\Chris Howie\Desktop\bfgminer-2.5.1-win32\pdcurses.dll" - detection is correct

Yeah, that's more or less what I expected.

Actually, on further thought, it is possible that file could be infected (though very unlikely). It is an exception to my general "compile everything" policy - I just used their official DLL binary.

Anyhow, here's what I sent to AVG:

Quote

One of my users is reporting that AVG insists my software is a virus, even after sending to you for review. Please correct your procedures to actually do proper checking and not flag innocent software.

The flagged file is pdcurses.dll, which I am using the official Windows binary distributed at:

http://voxel.dl.sourceforge.net/project/pdcurses/pdcurses/3.4/pdc34dllw.zip

If this official binary is indeed infected, please provide evidence so that it is removed from SourceForge (a highly respected software website).

In the meantime, want to see if it detects one I compile myself?
http://luke.dashjr.org/tmp/code/pdcurses.dll
e8bc66188d8f0503a5850bb11340e0eb8d60491a827ce27add2b460b65096780 pdcurses.dll

I still get the virus warning from AVG when I downloaded 2.8.0. But your compiled version didn't have the virus.

I uploaded the file to https://www.virustotal.com/file/94995b0560d2ccda7951252397eb152b499454746b75d03479bbfa551def41e4/analysis/ and 9/41 found the virus.

I tried downloading http://voxel.dl.sourceforge.net/project/pdcurses/pdcurses/3.4/pdc34dllw.zip and scanned it with AVG and no virus found... hmm...

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Inaba on September 20, 2012, 07:40:55 PM

What would I need to do that on Windows?

Time with me on IRC Wink

Inaba

legendary

Activity: 1260

Merit: 1000

What would I need to do that on Windows?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Inaba on September 20, 2012, 07:15:23 PM

It's happened as far back as 2.7.5 or 2.7.4 I believe

Yeah, I was thinking more in terms of "compile 50% of the code, see if it complains" Wink

Inaba

legendary

Activity: 1260

Merit: 1000

It's happened as far back as 2.7.5 or 2.7.4 I believe

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