Bitcoin Forum
December 11, 2016, 02:31:04 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 245137 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 20, 2013, 11:32:09 PM
 #601

Running into a noob problem: Your description said to use opkg to install BFG miner. DD-WRT uses ipkg?

is this still possible to do without to much knowledge?
opkg basically automates download and installation of ipkg software.
I'd think you could just download the .ipk manually and install it with ipkg...
On the other hand, this website seems to suggest it may be a bit more complicated!
If you manage to get it working, I'd appreciate some docs on how to do it Smiley

1481423464
Hero Member
*
Offline Offline

Posts: 1481423464

View Profile Personal Message (Offline)

Ignore
1481423464
Reply with quote  #2

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

Activity: 742



View Profile
February 20, 2013, 11:53:43 PM
 #602

Oh: I'm a windumb user, thats far out of my league .... I'll have a look at it but in general, i run into unexplainable problems when it comes to linux! I think it hates me Wink

jddebug
Sr. Member
****
Offline Offline

Activity: 424



View Profile
February 20, 2013, 11:58:13 PM
 #603

Oh: I'm a windumb user, thats far out of my league .... I'll have a look at it but in general, i run into unexplainable problems when it comes to linux! I think it hates me Wink

Brokk, you and me seem to have had the same Linux experiences. Smiley
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
February 22, 2013, 07:20:48 PM
 #604

Running 2.10.5 under Win7/64, my Singles occasionally get into a WAIT state in which they stop hashing or submitting shares. The software is still running because I can see the regular messages appear (longpoll detected, requested work restart, etc.), but the Singles don't seem to get out of WAIT unless I manually switch pools via the (p)(s) command. I've had this happen when mining on bitminter and eclipse, using Stratum as well as the regular vardiff/LP ... so there doesn't seem to be a common theme.

Anecdotally I started encountering this sometime after Stratum support was added (several months ago); it has happened in all of the past few versions since then. I seem to be able to avoid the WAIT state by using the --no-stratum flag. But since I'm not hearing of anyone else having this issue, I'm sure it must be something unique to my setup ... but I have 3 separate clusters running off 3 separate PCs and I've seen the WAIT behavior on all of them.

I have several backup pools configured, and I'm wondering why bfgminer doesn't switch automatically to one of the backup pools instead of putting the miners into a WAIT state. Or is there a way to configure it to do this (I don't see anything obvious in the readme, but perhaps I missed something).

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 22, 2013, 07:42:12 PM
 #605

Running 2.10.5 under Win7/64, my Singles occasionally get into a WAIT state in which they stop hashing or submitting shares. The software is still running because I can see the regular messages appear (longpoll detected, requested work restart, etc.), but the Singles don't seem to get out of WAIT unless I manually switch pools via the (p)(s) command. I've had this happen when mining on bitminter and eclipse, using Stratum as well as the regular vardiff/LP ... so there doesn't seem to be a common theme.

Anecdotally I started encountering this sometime after Stratum support was added (several months ago); it has happened in all of the past few versions since then. I seem to be able to avoid the WAIT state by using the --no-stratum flag. But since I'm not hearing of anyone else having this issue, I'm sure it must be something unique to my setup ... but I have 3 separate clusters running off 3 separate PCs and I've seen the WAIT behavior on all of them.

I have several backup pools configured, and I'm wondering why bfgminer doesn't switch automatically to one of the backup pools instead of putting the miners into a WAIT state. Or is there a way to configure it to do this (I don't see anything obvious in the readme, but perhaps I missed something).
The only change --no-stratum makes is disabling automatic switching from GBT/getwork to stratum. If it works with that option, this means your problem is stratum-specific.
A debug log of this occurring would help:
Code:
bfgminer YOUR OPTIONS FIRST --debuglog 2>debug.log

Failover is currently still managed by code inherited from cgminer, which is rather slow to react to problems.
I plan to rewrite it eventually, but haven't got around to that yet.

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
February 23, 2013, 12:53:37 AM
 #606

Running 2.10.5 under Win7/64, my Singles occasionally get into a WAIT state in which they stop hashing or submitting shares. The software is still running because I can see the regular messages appear (longpoll detected, requested work restart, etc.), but the Singles don't seem to get out of WAIT unless I manually switch pools via the (p)(s) command. I've had this happen when mining on bitminter and eclipse, using Stratum as well as the regular vardiff/LP ... so there doesn't seem to be a common theme.

Anecdotally I started encountering this sometime after Stratum support was added (several months ago); it has happened in all of the past few versions since then. I seem to be able to avoid the WAIT state by using the --no-stratum flag. But since I'm not hearing of anyone else having this issue, I'm sure it must be something unique to my setup ... but I have 3 separate clusters running off 3 separate PCs and I've seen the WAIT behavior on all of them.

I have several backup pools configured, and I'm wondering why bfgminer doesn't switch automatically to one of the backup pools instead of putting the miners into a WAIT state. Or is there a way to configure it to do this (I don't see anything obvious in the readme, but perhaps I missed something).
The only change --no-stratum makes is disabling automatic switching from GBT/getwork to stratum. If it works with that option, this means your problem is stratum-specific.
A debug log of this occurring would help:
Code:
bfgminer YOUR OPTIONS FIRST --debuglog 2>debug.log

Failover is currently still managed by code inherited from cgminer, which is rather slow to react to problems.
I plan to rewrite it eventually, but haven't got around to that yet.
Luke, I've managed to capture this WAIT state after 15 minutes of operation. Edited debug info here: http://pastebin.com/JYB7Lr9g

For this test run I used the following command line (windows .bat file; usernames and passwords obfuscated; 15 Singles in total):
Code:
bfgminer ^
-o http://us2.eclipsemc.com:8337 -u xxxxxxxx -p yyyyyyyy ^
-o http://mint.bitminter.com:8332 -u xxxxxxxx -p yyyyyyyy ^
-o http://us.ozco.in:3333 -u xxxxxxxx -p yyyyyyyy ^
-o http://api.bitcoin.cz:8332 -u xxxxxxxx -p yyyyyyyy ^
--disable-gpu --no-submit-stale ^
-S all ^
--debuglog 2>debug2.log
The run started at 13:51, and all of the Singles got into a WAIT state at around 16:07 from which they would not recover. At 16:06 they are all still happily mining at around 800mhps (search for the string "5s:"), but that starts to drop to 0 after 16:07.

I noticed that bfgminer was listing all of the Singles as 'WAIT' around 16:25 at which time I issued a (q) command to quite bfgminer and collect the debug info.

I hope this can help you track down where (and why) this situation happens. And as I also mentioned before, if I used the "--no-stratum" parameter, this situation never seems to occur.

Thanks in advance for the help.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 23, 2013, 03:25:55 AM
 #607

Luke, I've managed to capture this WAIT state after 15 minutes of operation. Edited debug info here: http://pastebin.com/JYB7Lr9g
It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity.
I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 23, 2013, 04:55:43 AM
 #608

I've uploaded some prerelease/alpha Windows builds of BFGMiner 3.0 for testing.
While they do support BitForce SC ASICs, this is completely untested so far (obviously).
There has been some major restructuring involved, so 3.0 will work differently both under and over the hood for FPGAs, especially BitForce and X6500 which have been ported to take advantage of the new device API.
 37 files changed, 4325 insertions(+), 2993 deletions(-)
Please verify your FPGAs/GPUs/pools/etc still work as expected.
Note the new --show-processors option to view your FPGAs at a more detailed level.

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
February 23, 2013, 03:11:38 PM
 #609

It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity.
I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it.
Appreciated, thanks. It doesn't take long for me to run into this state (no more than a few hours at most) so I will, at the very least, be able to see if your fix improves the situation quickly enough.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Bitsilver.us
Newbie
*
Offline Offline

Activity: 14



View Profile WWW
February 23, 2013, 04:53:10 PM
 #610

I've uploaded some prerelease/alpha Windows builds of BFGMiner 3.0 for testing. ... Please verify your FPGAs/GPUs/pools/etc still work as expected.
Note the new --show-processors option to view your FPGAs at a more detailed level.

bfgminer-2.99.00 Win-64 been up about an hour now, nothing to report, everything is running well.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 23, 2013, 07:03:57 PM
 #611

It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity.
I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it.
Appreciated, thanks. It doesn't take long for me to run into this state (no more than a few hours at most) so I will, at the very least, be able to see if your fix improves the situation quickly enough.
If you can test 2.99.0, that does include this change.

aeris
Newbie
*
Offline Offline

Activity: 17


View Profile
February 23, 2013, 07:34:57 PM
 #612

Hello everybody and thanks a lot to Luke for this awesome miner.

I have some trouble with bfgminer on bitminter pool.
I have a very low shares production compare to bfgminer on other pools:
- bitminter : 656 Work Request, 4 Shares -> 6‰
- 50btc : 761 Work Request, 20 Shares -> 26‰
- bitcoin.cz : 1513 Work Request, 43 Shares -> 28‰

On log, I see a lot of « Stratum from pool 0 requested work restart » for bitminter, and no such trace on other pools:
Code:
[2013-02-23 20:22:04] Stratum from pool 0 requested work restart
 [2013-02-23 20:22:36] Stratum from pool 0 requested work restart
 [2013-02-23 20:23:07] Stratum from pool 0 requested work restart
 [2013-02-23 20:23:38] Stratum from pool 0 requested work restart
 [2013-02-23 20:24:09] Stratum from pool 0 requested work restart
 [2013-02-23 20:24:40] Stratum from pool 0 requested work restart
 [2013-02-23 20:25:11] Stratum from pool 0 requested work restart
 [2013-02-23 20:25:43] Stratum from pool 0 requested work restart
 [2013-02-23 20:26:14] Stratum from pool 0 requested work restart
 [2013-02-23 20:26:45] Stratum from pool 0 requested work restart
 [2013-02-23 20:27:16] Stratum from pool 0 requested work restart
After activate debug, seems each work restart occurs just after a get_transactions, which is an unknown method on bitminter :
Code:
[2013-02-23 20:31:57] Unknown stratum msg: {"error": [-3, "Method 'get_transactions' not found for service 'mining'", null], "id": "txlist19ea", "result": null}
 [2013-02-23 20:31:58] Work stale due to work restart (32 != 33)
 [2013-02-23 20:31:58] Popping work from get queue to get work

So, am I good if I believe that this missing method is the source of bad performance ?
What I can do to regain perf on this pool ?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 23, 2013, 07:58:16 PM
 #613

Code:
[quote author=aeris link=topic=78192.msg1553650#msg1553650 date=1361648097]I have some trouble with bfgminer on bitminter pool.
I have a very low shares production compare to bfgminer on other pools:
- bitminter : 656 Work Request, 4 Shares -> 6‰
- 50btc : 761 Work Request, 20 Shares -> 26‰
- bitcoin.cz : 1513 Work Request, 43 Shares -> 28‰[/quote]These numbers aren't relevant in any meaningful way.
If your concern is shares, look at the 3rd hashrate
If your concern is bandwidth, look at E: (higher is better)

On log, I see a lot of « Stratum from pool 0 requested work restart » for bitminter, and no such trace on other pools:
Code:
[2013-02-23 20:22:04] Stratum from pool 0 requested work restart
 [2013-02-23 20:22:36] Stratum from pool 0 requested work restart
 [2013-02-23 20:23:07] Stratum from pool 0 requested work restart
 [2013-02-23 20:23:38] Stratum from pool 0 requested work restart
 [2013-02-23 20:24:09] Stratum from pool 0 requested work restart
 [2013-02-23 20:24:40] Stratum from pool 0 requested work restart
 [2013-02-23 20:25:11] Stratum from pool 0 requested work restart
 [2013-02-23 20:25:43] Stratum from pool 0 requested work restart
 [2013-02-23 20:26:14] Stratum from pool 0 requested work restart
 [2013-02-23 20:26:45] Stratum from pool 0 requested work restart
 [2013-02-23 20:27:16] Stratum from pool 0 requested work restart
After activate debug, seems each work restart occurs just after a get_transactions, which is an unknown method on bitminter :
Code:
[2013-02-23 20:31:57] Unknown stratum msg: {"error": [-3, "Method 'get_transactions' not found for service 'mining'", null], "id": "txlist19ea", "result": null}
 [2013-02-23 20:31:58] Work stale due to work restart (32 != 33)
 [2013-02-23 20:31:58] Popping work from get queue to get work
Pretty normal for stratum pools. You can use --no-stratum to avoid it.
BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
February 23, 2013, 08:09:32 PM
 #614

BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked.

I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise.

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

Activity: 2100



View Profile
February 23, 2013, 08:21:47 PM
 #615

BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked.

I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise.
Only blind stratum uses less bandwidth. Secured stratum uses more, since it doesn't support compression.
While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse.
Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment?

aeris
Newbie
*
Offline Offline

Activity: 17


View Profile
February 23, 2013, 08:38:23 PM
 #616

These numbers aren't relevant in any meaningful way.
If your concern is shares, look at the 3rd hashrate
If your concern is bandwidth, look at E: (higher is better)
Bandwidth is not a problem for me.
And I notice a problem because the bitminter java client produces a lot of shares for the same hashrate than bfgminer (~5× more).
Same problem with bfgminer in load-balance mode, 50btc and bitcoin.cz produces 4× more shares than bitminter for the same number of work request and hashrate.

Quote
Pretty normal for stratum pools.
bitcoin.cz is stratum too, and no such « work restart » on it…

Quote
You can use --no-stratum to avoid it.
Stratum is the new bitcoin way for mining, why avoid it Huh
Some pool give you more payback when you use stratum instead of gwork, like bitcoin.cz.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 23, 2013, 08:46:03 PM
 #617

These numbers aren't relevant in any meaningful way.
If your concern is shares, look at the 3rd hashrate
If your concern is bandwidth, look at E: (higher is better)
Bandwidth is not a problem for me.
And I notice a problem because the bitminter java client produces a lot of shares for the same hashrate than bfgminer (~5× more).
Same problem with bfgminer in load-balance mode, 50btc and bitcoin.cz produces 4× more shares than bitminter for the same number of work request and hashrate.
Is it possible BitMinter is vardiff and the others are not?

Quote
Pretty normal for stratum pools.
bitcoin.cz is stratum too, and no such « work restart » on it…
That would be very odd.. are you sure you're connecting to it with stratum? Maybe the messages are just not as noticable since you're finding more shares between them?

Quote
You can use --no-stratum to avoid it.
Stratum is the new bitcoin way for mining, why avoid it Huh
Some pool give you more payback when you use stratum instead of gwork, like bitcoin.cz.
The community-developed standard ("new bitcoin way") is getblocktemplate (GBT).
Stratum supports less functionality, was developed behind closed doors, and uses more bandwidth than GBT unless used in a way harmful to Bitcoin.
While it might with time become a new standard (slush recently started bringing it to the BIP standardization process), it still has a way to go before it can really compete with GBT.
Admittedly, knowing this doesn't do much for you while you mine on pools that force you to use stratum because they refuse to support standard GBT, but that is not the case with BitMinter Wink

jddebug
Sr. Member
****
Offline Offline

Activity: 424



View Profile
February 23, 2013, 08:50:12 PM
 #618

BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked.

I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise.
Only blind stratum uses less bandwidth. Secured stratum uses more, since it doesn't support compression.
While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse.
Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment?

My guess is that if you add the transaction data checking that there would be a number of miners who would like to use it just to be part of Bitcoin security. I'd want to check it out at least.
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
February 23, 2013, 09:12:06 PM
 #619

BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked.

I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise.
Only blind stratum uses less bandwidth. Secured stratum uses more, since it doesn't support compression.
While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse.
Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment?
So I was right. At this time, choosing GBT over Stratum is just wasting bandwidth, with no tangible advantages in the here and now. Sure, it has potential, but until that potential turns into an actual increase in network security, you can't really complain about pools not choosing GBT, can you?

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

Activity: 2100



View Profile
February 23, 2013, 09:14:36 PM
 #620

BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked.

I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise.
Only blind stratum uses less bandwidth. Secured stratum uses more, since it doesn't support compression.
While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse.
Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment?
So I was right. At this time, choosing GBT over Stratum is just wasting bandwidth, with no tangible advantages in the here and now. Sure, it has potential, but until that potential turns into an actual increase in network security, you can't really complain about pools not choosing GBT, can you?
It's already actual, since pools can't know who is or isn't verifying what.

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!