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

Luke,

I had reported the same work submission for 2.9.4

It clears up after a about a minute.

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

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.

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

Thank you,

I will start testing with next test and 2.9.4

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.

Looks like bfgminer isn't working with bitminter anymore.

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

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

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

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

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

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

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

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

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.

Actually, this might very well be a bug.

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

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

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

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

I thank you for any help.

Regards

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

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

Hey,

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

As per the discussion we had in #btcfpga not long ago where you already know the truth, yet you still try to spread lies ...

Spreading lies about people I guess is the only way you'll be able to get people to accept your piece of shit, crappy protocol that's worse than the old getwork in it's network usage and certainly no better performance for mining compared to getwork with any single device up to at least a few 100GH/s

What ckolivas did was make sure the GBT piece of shit was getting the same number of work requests as Stratum is receiving.

If that is called "intentionally designed the GBT path to use more bandwidth" then you seriously should not be allowed to go anywhere near the bitcoind software.
You already put botnet support in bitcoind 0.7.x so no doubt I'm not surprised at you telling people to make BTC transaction confirms worse.
You made transaction confirm times worse with your piece of crap pool for 5 months so the pool would make more BTC, so yeah it's not surprising.

Your above statement directly implies that using GBT means you negatively affect transaction confirm times and using Stratum is better for transaction confirm times since you are directly implying that GBT should be doing fewer work requests than Stratum sends the miner.

BTC is about transactions - go read Staoshi's paper if you are so stupid as to not understand that.
If no one confirms transactions, then BTC is dead.

Since you are directly implying that the GBT implementation in your clone miner negatively affects transaction confirm times compared to Stratum, then you are seriously saying that people SHOULD NOT be using it.
Though the argument itself is worse, since you are saying that the GBT protocol requires fewer work requests and thus negatively impacts transaction commit times compared to Stratum, and thus the protocol itself is to blame.