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

[Luke-Jr]

I have connected 8 BFL Singles.
With bitminter I can mine without any problems.
But if I use bfgminer, there will be only one of 8 used.

Also I cant access the menu of bfgminer.

any idea? running on ubuntu
bfgminer -o http://pool -u user -p password

Are you using the PPA, or did you build from source?
If from source, did you ensure you had installed all the dependencies mentioned in README before running autogen.sh/configure?
In particular, libudev-dev is needed for multiple FPGAs, and libncurses-dev is needed for the TUI (menu etc).

[1714042469]

1714042469

[1714042469]

1714042469

[AmDD]

I had tried installing from source on Ubuntu and failed hard. The PPA is 10x easier and the way to go...

[x12345]

HowTo mining on Ubuntu (bfgminer from PPA) and 5870 for Litecoin?

I thank you for any help.

Regards

[Luke-Jr]

1. Scantime defines upper boundary for scanning current work. Once GW gets data from pool, miner starts working on it for duration of scantime or until new block is announced by some pool. What happens is pool, especially local server (solo mining), accepts transactions after GW is complete? Does it informs miner about the change? What happens if miner finds valid hash for work which does not include mentioned transactions accepted by local server? Does valid hash becomes stale, e.g. upon miner submitting it to local server, hash is rejected? What are the negative consequences of using 30 seconds or less for scantime, and what becomes improved by reducing time?

When you're talking about localhost, you probably want to set scantime as low as possible to get the best benefit for the Bitcoin network. Pool mining is different, and usually the pool tells you how long to work on the job.

2. If there was no data change on pool since last GW, e.g. new GW gets same data as previous one, does it mean miner will start over or it will continue where it stopped (nonce), e.g. ignore data received by new GW?

Actually, this might very well be a bug.

3. Queuing less data than default (1) results in less stales and destroyed works, but it results in more requests per time sent to pool?

There is no harm to higher or lower scantime, so long as your bitcoind supports long polling to notify of new blocks. As of 0.7.1, it doesn't. More requests to localhost shouldn't hurt, except for the possible bug in (2).

4. Why miner does not switch to new block as soon as local server detects it? I'm solo mining without LP and looking at "Current number of blocks", which goes up at certain moment but miner does not changes block it's working on for < or = scantime seconds. Does it mean all those seconds miner is actualy working on previous block, which would result in hash becoming rejected if submitted?

If your bitcoind doesn't support long polling, yes.

In short = if I'm mining solo without LP and want to reduce number of stales (rejected), should I set queue=0 and scantime=few seconds?

In theory, yes. If the bug in (2) exists, it's a tradeoff.

[Luke-Jr]

Does bug at (2) exists or not I can't tell. I just wanted to know how miner should work. I tried "deciphering" stuff posted on screen by
miner when enabling debug and RPC debug but I can't really tell what's going on with nonce since data comes to screen way too fast,
even with window set to 80 chars x 80 lines. Even when I focus enough to filter-out everything but value for nonce, I'm not sure it is
what it should be, LOL!

I think bug at (2) doesn't exist since BFGMiner will roll time as possible (and it always is with bitcoind).

There is a problem I have with newer versions of both BFGMiner and CGMiner, those that show best share difficulty = on way too many
occassions, it happened that value shown was higher than current network difficulty but absolutely nothing happened, e.g. share was
neither accepted (it should solve block), nor rejected, nor some other message was shown (solo mining Terracoin, in case you wonder,
so it's scenario like "network difficulty 731 and my best share 755"). Miner version 2.8.3 does not seems to be having the issue.

It costs me hours to detect the issue, so don't ask me to check with 2.8.6 or some other version. I've lost way too many TRC already!  

You mean the block is actually being lost? That's not good :/
Can you open a github issue for this?

[K1773R]

Code:

Crashed with signal 11! Will attempt to restart--- Failed to restart, exiting nowing

latest version, x86_64 linux, build with -02 -Wall

[Luke-Jr]

Prior to 0.7.1 Bitcoin client actualy had LP support but than it's removed? LOL, what's next = disable ability to mine solo completely?

bitcoind has never supported LP. 0.8 might if enough people care to test/review the code.

[AndrewK]

Sorry, this may be noobish. But I'm having a hard time figuring out hot to mine litecoins with bfgminer... I downloaded the latest version (2.9.3) but I can't figure out how to enable scrypt.

I do not want to have to compile it myself and when I added -o --scrypt via command line.... BFGminer freezes and the display driver crashs. I also set my shaders to 1600 (mining with 5970s) intensity 13...

My conf file has diablo as the kernel? Maybe this is the problem? Should I use poclbm?

Thanks,
Andrew

[davecoin]

I have an x6500 with serial number AH01A895.  I see it on COM4. What is the correct syntax to recognize the fpga in Windows?

Thanks,
Dave

[Luke-Jr]

I have an x6500 with serial number AH01A895.  I see it on COM4. What is the correct syntax to recognize the fpga in Windows?

If you see it on COM4, then you don't have the driver installed. X6500s aren't serial-based.

[davecoin]

That was easy.  Thanks!  I was experiencing around 2.5% stales using mpbm and a hashrate around 380Mh/s.  Now it's humming along at 400 MH/s with no stales (so far at least). You should pm me your address so I can send you some nuts as a thank you!

-Dave

[mining4fun11]

Looks like bfgminer isn't working with bitminter anymore.

[Luke-Jr]

NEW VERSION 2.9.4, DECEMBER 4 2012

I hope 2.9.4 will be the first stable 2.9.x version, but I've also bumped the stable release to 2.8.7 just in case.

Note that BFGMiner 2.9.x and cgminer have diverged: cgminers recent changes are not included here unless they fix a bug. BFGMiner git is pre-2.10.0, and does include those changes if you really want them (there was nothing that stood out as particularly useful or important). The pre-2.10.0 in git also includes a new feature to limit stratum bandwidth use at the expense of Bitcoin security, per request of slush (why his fee pool can't handle the bandwidth many no-fee pools do, I don't know).

Human readable changelog:

• Documented solo mining in README.
• Lots of small bugfixes everywhere.

Full changelog

• Update libblkmaker to 0.2.1
• Count template number, and append it to the coinbase of templates without any cbtxn
• Bugfix: bitforce: Always increment global hw error counter when incrementing device hwe
• Bugfix: Correct order of printf-style arguments in cbappend fail
• Bugfix: Capitalize "MHz" correctly
• ztex: Correctly release mutex and reset FPGA if configuration fails
• ztex: Harmonize low-speed FPGA configuration code with high-speed code
• libztex: Silence warning: comparison between signed and unsigned
• Count longpoll decodes as queued work since the count otherwise remains static.
• Bugfix: Assign header-based rolltime before decoding work, so GBT expires overrides it properly
• Look for libusb_init in -lusb, since FreeBSD has it there
• Bugfix: Use pkgconfig for libusb when available, and try to guess the include path if not
• Bugfix: FPGA-README: Correct idVendor in example MMQ udev rule
• fixes target calc for mips openwrt
• Bugfix: clear_work: Whether the template is in fact being freed or not, the work reference to it needs to be
• libztex: Work around ZTEX USB firmware bug exposed by the FreeBSD libusb
• README: Document solo mining usage
• README: Update dependencies
• Bugfix: We should never roll stale work
• Ubuntu: Removing erroneous libssl dep again. GITHUB#94
• Bugfix: Clear out stratum share work before freeing it
• Provide rudimentary support for literal ipv6 addresses when parsing stratum URLs.
• Do not attempt to remove the stratum share hash after unsuccessful submission since it may already be removed by clear_stratum_shares.

[jborkl]

Thank you,

I will start testing with next test and 2.9.4

[crazyates]

Note that BFGMiner 2.9.x and cgminer have diverged: cgminers recent changes are not included here unless they fix a bug.

How do you plan on remaining competitive in the future with this sudden change?

[Luke-Jr]

Note that BFGMiner 2.9.x and cgminer have diverged: cgminers recent changes are not included here unless they fix a bug.

How do you plan on remaining competitive in the future with this sudden change?

2.10.0 (or 3.0 if ASICs hit first) will have the latest cgminer changes. I just wasn't comfortable with them being bug-free and they didn't seem to provide much (if anything) of value.

[kano]

Note that BFGMiner 2.9.x and cgminer have diverged: cgminers recent changes are not included here unless they fix a bug.

How do you plan on remaining competitive in the future with this sudden change?

Just means that for the ones where he isn't copying the code exactly, he can claim it's his code.
A lot of partial commits in there now that say he wrote the code he got from cgminer ...

His problem is that git shows he hardly wrote any of cgminer, so now to get around that he'll just copy the code and commit it under his name and then have a way to back up his lies about how so much of the code is his (which it isn't)

Interesting that his git now has all my new USB code, that I've written ready for ASIC, but he doesn't use it yet ...
No doubt he'll change an irrelevant line here or there and then claim he wrote it all also

[jborkl]

Luke,

I had reported the same work submission for 2.9.4

It clears up after a about a minute.

[DobZombie]

The reason I switched from cgminer to bfgminer was for --coinbase-sig "DobZombi"

I wanted some blocks named after me!

but...
I just tried using Stratum with BFGminer, and fuck-a-duck It CHEWED through 1GB of download in 10hrs! That's ridiculous!

I've switched back to cgminer for the use of stratum.  It's only using a few hundred bytes per second

[Luke-Jr]

The reason I switched from cgminer to bfgminer was for --coinbase-sig "DobZombi"

I wanted some blocks named after me!

but...
I just tried using Stratum with BFGminer, and fuck-a-duck It CHEWED through 1GB of download in 10hrs! That's ridiculous!

I've switched back to cgminer for the use of stratum.  It's only using a few hundred bytes per second

Use GBT. Not only will it work better, but it's also required for --coinbase-sig to work at all.