Bitcoin Forum
December 08, 2016, 06:28:22 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 245053 times)
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 21, 2012, 10:50:25 AM
 #441

mrb, seriously ... read:

https://bitcointalk.org/index.php?topic=14085.msg1349123#msg1349123

... and of course it is also way less traffic.

I dunno what bugs Luke-Jr was talking about he has in bfgminer, that he was mentioning in the cgminer thread, but try it all with stratum and cgminer and see for yourself.

Luke's already been told what the problems are with GBT and how to fix it but his response was along the lines of ... that's just an implementation issue ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
1481178502
Hero Member
*
Offline Offline

Posts: 1481178502

View Profile Personal Message (Offline)

Ignore
1481178502
Reply with quote  #2

1481178502
Report to moderator
1481178502
Hero Member
*
Offline Offline

Posts: 1481178502

View Profile Personal Message (Offline)

Ignore
1481178502
Reply with quote  #2

1481178502
Report to moderator
1481178502
Hero Member
*
Offline Offline

Posts: 1481178502

View Profile Personal Message (Offline)

Ignore
1481178502
Reply with quote  #2

1481178502
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481178502
Hero Member
*
Offline Offline

Posts: 1481178502

View Profile Personal Message (Offline)

Ignore
1481178502
Reply with quote  #2

1481178502
Report to moderator
1481178502
Hero Member
*
Offline Offline

Posts: 1481178502

View Profile Personal Message (Offline)

Ignore
1481178502
Reply with quote  #2

1481178502
Report to moderator
1481178502
Hero Member
*
Offline Offline

Posts: 1481178502

View Profile Personal Message (Offline)

Ignore
1481178502
Reply with quote  #2

1481178502
Report to moderator
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 21, 2012, 01:00:46 PM
 #442

Abstract: getblocktemplate more wasteful than getwork

As a solo miner, I switched one of my FPGA hosts to bfgminer 2.9.3 in order to mine with getblocktemplate against bitcoind 0.7.1. This particular host has 37 FPGA devices (mixture of bfl singles, cm1's, icarus's) and I notice that bfgminer is sub-optimal: every 2-3 minutes, it does about 20-40 getblocktemplate calls in a row (1 for each FPGA device?). These 20-40 getblocktemplate calls amount to about 3-4MB total. So on average, getblocktemplate generates about 1-2 MB of network traffic per minute.

On the other hand, when mining with getwork, these 37 FPGA devices amount to about 15 Ghash/sec, so it generates about 4 getwork calls per second, or about 600 kB/minute as measured by a packet sniffer.

Bottom line, getblocktemplate as it is implemented in bfgminer causes my host to generate more network traffic than getwork (but fewer RPC calls). I haven't taken the time to read the code yet, but, Luke, isn't there something trivial to optimize to reduce the number of getblocktemplate calls?
bitcoind is not intended for use of slow networks, and doesn't even attempt to minimize traffic. It also does not currently implement long-polling (though next-test has a patch to support it), so the template needs to be refreshed regularly in case of the old one being stale.

As you note, above matters with bitcoind aside, bfgminer does not implement GBT optimally at this time, since it is using code originally built around getwork; cgminer has bypassed the getwork paths for its GBT support, but also intentionally designed the GBT path to use more bandwidth (conman wants to make GBT look bad). Rewriting the pool networking code in bfgminer has been on my todo list for a while (mainly due to other problematic bugs in it), and hopefully I'll get to that before 3.0. But even without it, each template is still able to scale per device, so the problem of ASICs hashing much faster is still dealt with in practice.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 21, 2012, 01:37:27 PM
 #443

Abstract: getblocktemplate more wasteful than getwork

As a solo miner, I switched one of my FPGA hosts to bfgminer 2.9.3 in order to mine with getblocktemplate against bitcoind 0.7.1. This particular host has 37 FPGA devices (mixture of bfl singles, cm1's, icarus's) and I notice that bfgminer is sub-optimal: every 2-3 minutes, it does about 20-40 getblocktemplate calls in a row (1 for each FPGA device?). These 20-40 getblocktemplate calls amount to about 3-4MB total. So on average, getblocktemplate generates about 1-2 MB of network traffic per minute.

On the other hand, when mining with getwork, these 37 FPGA devices amount to about 15 Ghash/sec, so it generates about 4 getwork calls per second, or about 600 kB/minute as measured by a packet sniffer.

Bottom line, getblocktemplate as it is implemented in bfgminer causes my host to generate more network traffic than getwork (but fewer RPC calls). I haven't taken the time to read the code yet, but, Luke, isn't there something trivial to optimize to reduce the number of getblocktemplate calls?
bitcoind is not intended for use of slow networks, and doesn't even attempt to minimize traffic. It also does not currently implement long-polling (though next-test has a patch to support it), so the template needs to be refreshed regularly in case of the old one being stale.

As you note, above matters with bitcoind aside, bfgminer does not implement GBT optimally at this time, since it is using code originally built around getwork; cgminer has bypassed the getwork paths for its GBT support, but also intentionally designed the GBT path to use more bandwidth (conman wants to make GBT look bad). Rewriting the pool networking code in bfgminer has been on my todo list for a while (mainly due to other problematic bugs in it), and hopefully I'll get to that before 3.0. But even without it, each template is still able to scale per device, so the problem of ASICs hashing much faster is still dealt with in practice.

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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
TAiS46
Full Member
***
Offline Offline

Activity: 223



View Profile WWW
November 23, 2012, 02:14:02 PM
 #444

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
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 23, 2012, 07:16:06 PM
 #445

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

AmDD
Legendary
*
Offline Offline

Activity: 827



View Profile
November 24, 2012, 04:07:10 AM
 #446

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

BTC tip jar: 18EKpbrcXxbpzAZv3T58ccGcVis7W7JR9w
LTC tip jar: Lgp8ERykAgx6Q8NdMqpi5vnVoUMD2hYn2a
x12345
Sr. Member
****
Offline Offline

Activity: 266



View Profile
November 25, 2012, 08:24:15 AM
 #447

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

I thank you for any help.

Regards

Key GPG 92B7635F | jabber: bitcoin AT imbox.im | C/V de BTCs

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 27, 2012, 10:05:45 PM
 #448

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

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 27, 2012, 10:47:13 PM
 #449

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!  Tongue
You mean the block is actually being lost? That's not good :/
Can you open a github issue for this?

K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
November 28, 2012, 10:00:26 AM
 #450

Code:
Crashed with signal 11! Will attempt to restart--- Failed to restart, exiting nowing
latest version, x86_64 linux, build with -02 -Wall

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 29, 2012, 02:24:59 PM
 #451

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
Hero Member
*****
Offline Offline

Activity: 720



View Profile
November 30, 2012, 05:13:25 PM
 #452

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

1K4BacKKdssA5RGzaFx3D4LC9HVXjE2NvS
davecoin
Hero Member
*****
Offline Offline

Activity: 795


View Profile
November 30, 2012, 06:33:51 PM
 #453

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 30, 2012, 06:45:46 PM
 #454

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
Hero Member
*****
Offline Offline

Activity: 795


View Profile
November 30, 2012, 07:21:08 PM
 #455

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
Member
**
Offline Offline

Activity: 110


View Profile
December 03, 2012, 11:46:08 PM
 #456

Looks like bfgminer isn't working with bitminter anymore.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
December 04, 2012, 03:23:55 AM
 #457

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
Full Member
***
Offline Offline

Activity: 234



View Profile WWW
December 04, 2012, 03:48:55 AM
 #458

Thank you,

I will start testing with next test and 2.9.4

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
December 04, 2012, 03:53:37 AM
 #459

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?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
December 04, 2012, 03:56:46 AM
 #460

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!