Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 149. (Read 1193364 times)

Poclbm was using the CPU cores and Bfgminer is using OpenCL and the GPU stream processors on the chip. Bfgminer doesn't have native CPU support on windows anymore.

NEW VERSION 3.1.3, JULY 11 2013

Special thanks to iongchun for bisecting, debugging, and fixing the 100% CPU issue.

Human readable changelog:

• Fix 100% CPU usage hang with GBT/getwork pools.
• Make staged work underrun detection less overly aggressive.
• Generate baud rate list from OS on *nix (fixes Mac/BSD build).

Full changelog

• Bugfix: Reset staged_full flag when discarding (stale) popped work, or increasing the queue minimum
• Bugfix: Only trigger staged work underrun if a mining thread was actually waiting for it (and do so sooner, before it has the work made)
• bytes_cpy: avoid malloc and memcpy when size is zero
• fix infinite loop in bytes_cpy when size is zero
• Bugfix: Generate iospeeds_local.h based on termios.h defines, and only try to use POSIX standard if that fails

Okay, this just seems totally weird to me. I'm screwing around with different miners on my AMD A10-4600m APU. I started using Poclbm and BFGMiner. Poclbm got me about 3 MH/s utilizing 100% APU power, which seemed normal to me. Now with BFGMiner, I get approx. 100 MH/s and only using 5% of my APU. This is totally mindfucking me, please explain? Haha, and I can tell this is true by looking at my mining pool account status, which I'm acutally giving shares too a lot faster than Poclbm. Is my APU really supposed to be this fast at 100%? My CPU monitor might just be screwing with me about the percentage.

**Edit: Well, the hashrate is slowly lowering,  but is still a lot faster than GUIMiner and looking at Task Manager, it's almost like BFGMiner isn't running.

http://gyazo.com/18ac57cb1322a4e05b97e2e9ed1a41d5

adding a queue size of 254 ultimately ends up the same in time bfg starts giving the messages as mentioned in my previous post
i got the jala running as well on bfgminer 3.1.2 and guess what lol after a day running fine it also started giving the same message even with a queue size of 254
however still not sure why bfg crashes sometimes without any message whats wrong

adding the following commands to the startup batch seems to helped me get it to run more stable but does not solve the underrun messages

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1

I see this hang.  It occurs in bytes_cpy.  A size of 0 results in an infinite loop.

Here's the results:


Description of the problem in my previous post:

https://bitcointalksearch.org/topic/m.2685683

I am seeing a similar speed increase if i fiddle with the queue as well.  I expect that the auto adjustment of the queue size is capped at some function of the hashpower - but yes - i find moving it upwards it helps - also when i increase the difficulty some and twiddle with it.

I have found it to stop trying to auto adjust enventually when i get the number big enough and it does seem to be based on the amount of hashing and possibly number of devices as well.

Whatever you did Luke - it is making a difference for me - thanks!  Donation coming your way shortly. 

Would like to be able to use it on my rigs with X6500's - (win7 x64) but 3.1.1 is working great for them as well..

well after adding the queue to 64 in the config i see it still fail [ staged work underrun error ] still given and constant

i wonder if its normal to need a buffer so big with just 2 x 7970 which do run on version 3.1.1 with a queue size of 0

anyway upped the queue to massive 254 to see how that runs

i get the feeling the program is slightly faster on these gpu's even while they are heavy underclocked

Works great for me, under Linux.  I haven't noticed any problems with bfgminer 3.1.2 crashing or taking 100% CPU.  Maybe the problem could be isolated to Windows?

Compiled my entire Bitcoin stack from source, on Gentoo:

bitcoin 0.8.3 (bitcoin-qt target)
p2pool 13.1 (no compilation needed, it's a Python program which is interpreted)
bfgminer 3.1.2

I rather like bfgminer, it follows the "configure" standard, and drops right in!  Rather impressive.

Even the Satoshi bitcoin client wasn't this cleanly written, as it still required a little tweaking before it would compile: http://forums.gentoo.org/viewtopic-p-7344252.html#7344252

Command lines I've been using for the stack, which mines on my little Erupter:


If scripting, be sure to change "cd" commands to the directories you are using on your system (it is critically important to start from the correct directory for p2pool).

And, you probably want to change your payout address accordingly

Josh

You can change it by using the Settings Menu, the Queue  and put in the number you want for queued work.

currently testing bfg 3.1.2 on 2 x 7970 and am getting staged work underrun; not automatically increasing above 14 after it kept increasing the number till 14
any paramater which i can set in the config to give it more headroom ?
weird enough can not get 3.1.2 to run with the small jala, switched back to 3.1.1 which seems to run flawless
might have set wrong parameters in the .conf since i saw one posting his jala runs fine with 3.1.2
Are you using .conf to run bfg or do you run it plain with command line startup
Anyway when i start 3.1.2 it instant crash on my x64 win8

Sounds like the -d option should work fine for this...?

My guess is the Jalapeno isn't booted when BFGMiner starts

Also, each bfgminer instance should be separately addressable in the RPC protocol/API.

Please PM me if you are interested in this multi-instance project. Thanks.

I didn't see that recommendation when I searched MSDN. Do you happen to have a link handy?

It may not be a bad idea to use STL, but I'm thinking if I do so, I might as well branch out to a full OO implementation. That would be quite an effort.

My only objective is to be able to spawn several instances of bfgminer on a system. Why would I want to do that? I am building a "Condo" system where miners are hosted in a remote location. I want to give each user full control of his mining unit, which may be only part of a boxed system. For example, an Avalon box can have as many as 4 hardware modules, and each module can have 8 hashing units. A user in the condo system can own as small as a single hashing unit, and I want her to be able to launch her own instance of bfgminer on the same box where other users are running their own instance of bfgminer. Each bfgminer instance is associated with a user ID, and that user ID is in turn associated with particular hashing unit(s). The association of a user ID to hashing unit(s) is done by another subsystem, so all that really needs to happen is to allow bfgminer to accept a command-line parameter that indicates which hashing unit(s) it will use exclusively.

I will give a hashing unit in the condo I am building to whoever can get this done, and yes, it's OK for it to be open source and GPL'd. If I were to do it, I would use VS, but if somebody else is willing to do it, it doesn't matter how it's done.

I'm trying to get bfgminer to autostart in a screen session automatically on reboot on a raspberry pi. I'm using something like:  su bfgmineruser -c "screen ....." in /etc/rc.local.

When I type these commands by hand, they work fine. When started automatically at boot, bfgminer starts in a screen session like it is supposed to, BUT it doesn't recognize the Jalepeno. It is not doing any GPU mining at all, there is only one device on it, the Jalepeno.

Any suggestions or ideas would be appreciated.

And if the first pool is not stratum, 3.1.2 will hangs on start.

I have also have 100% CPU usage problem with 3.1.2.
After doing some "git bisect", the problem seems caused by this commit: 9484dc1a468a1e5323abc0ea0666c353ba7678d6
The previous commit 75b58b16a546deb4bb7ca25ca7520ec8788ddf2a and before is fine,
after that all builds start with immediate 100% CPU usage.

I'll see what I can do after work tomorrow. It's just a pain because my Mining computer is headless.

Wow, shocked to see so many problems, it was working so well for me

Please everyone, help debug this:
1. Open http://luke.dashjr.org/tmp/code/webisect/webisect.php
2. Enter a unique session id (try your name and a random number; eg "Luke-Jr-4239042")
3. Change the versions to match what you know works and what doesn't work. eg "bfgminer-3.1.1" and "bfgminer-3.1.2"

This gets your bisect session started.
You will then be presented with a series of builds to test.
Depending on various factors, it may take a few minutes to produce each build (this is automated).

4. Download the build
5. Test the build
6. Click good, bad, or skip (see descriptions next to the buttons)

If you get another build, go back to step 4 and repeat with that one.

Eventually, you will hit an end (it should take about 6 builds between 3.1.1 and 3.1.2).
Post the final result here, along with a clear description of your problem.

Thanks,

Luke