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

[Inaba]

What would I need to do that on Windows?

[1714295808]

1714295808

[Luke-Jr]

What would I need to do that on Windows?

Time with me on IRC

[burger]

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.  :/

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:

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

[ssateneth]

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

[purelithium]

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?

[Luke-Jr]

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]

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

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

[purelithium]

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!

[Luke-Jr]

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.

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

The -G option will inhibit using GPUs.

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]

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

[burger]

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?

[Luke-Jr]

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

[Luke-Jr]

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

[burger]

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]

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]

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]

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

[meebs]

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.

[weirdgod]

Any update on the #112 Event system ticket? It was meant for 2.9.0 if i read it correctly
Cant wait to see it in action!

cheers,
W

[Luke-Jr]

Any update on the #112 Event system ticket? It was meant for 2.9.0 if i read it correctly

Perhaps I should change the milestone labels I use

Right now, anything that's a bugfix or trivial is milestone'd for 2.8.2, any minor enhancements are 2.9.0, and major stuff is 3.0.0.
When I get to releasing 2.8.2, I'll then move anything that didn't make it to a new 2.8.3 milestone, etc.