OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[flyonwall]

Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?

IMO, not gonna happen.

BFGMiner makes extensive use of variable-length arrays (standard C since 1999).
Microsoft explicitly refuses to support variable-length arrays.

I'll look at patches of course, but I'm doubtful it can be done without making the code much uglier or slower.

Wow, I never know MS's C compiler didn't support VLAs.  They recommend that you compile as C++ and use vectors from the STL.

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.

[flyonwall]

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.

[Luke-Jr]

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.

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

[Luke-Jr]

Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?

IMO, not gonna happen.

BFGMiner makes extensive use of variable-length arrays (standard C since 1999).
Microsoft explicitly refuses to support variable-length arrays.

I'll look at patches of course, but I'm doubtful it can be done without making the code much uglier or slower.

Wow, I never know MS's C compiler didn't support VLAs.  They recommend that you compile as C++ and use vectors from the STL.

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.

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

[bronan]

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

[RoboCoder]

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

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

[Krellan]

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:

Code:

#!/bin/sh
cd "YourDirectoryHere/bitcoin-0.8.3"
./bitcoin-qt -min -splash=0 -server -debug -printtoconsole

Code:

#!/bin/sh
cd "YourDirectoryHere/bfgminer-3.1.2"
/usr/local/bin/bfgminer \
--coinbase-addr 1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG \
--queue=0 \
--disable-gpu \
-S all \
-O P2Pool:P2Pool \
-o http://localhost:9332/

Code:

#!/bin/sh
cd "YourDirectoryHere/forrestv-p2pool-83256e8"
python run_p2pool.py -a 1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG --outgoing-conns 10

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

[bronan]

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

[RoboCoder]

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

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

[purelithium]

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

Here's the results:

Code:

872099f8ba6b2acf2b0c6a44b6987d0f46489f68 is the first bad commit
commit 872099f8ba6b2acf2b0c6a44b6987d0f46489f68
Author: Luke Dashjr 
Date:   Sun Jul 7 22:20:28 2013 +0000

    x6500: Provide manuf/product/serial to cgpu interface

:100644 100644 c03d63fab8bc27fd59f35540dfaf91ca9ba9de02 d1c7859a742fa053ada48593a798750a172a4d8e M	driver-x6500.c
:100644 100644 bc9d74fa40f22c2815dee3e19a0a5e00e10759f6 793b5d8ed673f6d134cef28f1052e97aae3c4af2 M	fpgautils.c
:100644 100644 b270c6dfd0ea7d273462d9288abea9c5e03b0635 8ef1dbe8447d58410dbd0980e145d7dc22aa4b3f M	fpgautils.h

Description of the problem in my previous post:

https://bitcointalk.org/index.php?topic=168174.msg2685683#msg2685683

[twobitcoins]

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.

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

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

[bronan]

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

[karijuana]

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

[Luke-Jr]

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

[purelithium]

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

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.

[karijuana]

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

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.

Totally forgot the fact that APUs have Northern Light GPU cores. Used to working with a standard CPU, I feel pretty stupid now haha, but thanks!

[altsay]

currently testing bfg 3.1.2 on 2 x 7970 and am getting staged work underrun;

What is your hashrate with 2 x hd 7970?

[fabrizziop]

Hey, I'm running 13.4 drivers on Ubuntu 13.04 amd64, I had the problem with the BFI_INT as LukeJr described, with CGMiner, it was fixed with BFGMiner with SHA-256, but I still have errors mining scrypt hashes. What could I do?. Thanks. Right now I have to decrease intensity a lot to make it work, it gives me half the windows hashrate.

edit: it was my own dumbness, I forgot to export gpu alloc 100.

[Taugeran]

hmmm cant seem to gpu mine on my fossilized Radeon 5450 but i have in the past

Output of bfgminer -n


are the call fails to adl a possible windows bug?

using latest 3.1.3 x32 build

[Luke-Jr]

are the call fails to adl a possible windows bug?

More likely a driver bug.