Bitcoin Forum
April 22, 2019, 03:21:25 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
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 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 259094 times)
Epoch
Legendary
*
Offline Offline

Activity: 917
Merit: 1000



View Profile
February 23, 2013, 10:31:15 PM
 #621

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.
2.99.0 crashed (simultaneously on 2 machines) when bitminter went down around an hour ago (both using stratum); bfgminer 2.10.5 on a 3rd machine did not crash (although it was pointed at ozcoin at the time). Will try 2.99.0 again to see if it improves the WAIT issue.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
1555946485
Hero Member
*
Offline Offline

Posts: 1555946485

View Profile Personal Message (Offline)

Ignore
1555946485
Reply with quote  #2

1555946485
Report to moderator
1555946485
Hero Member
*
Offline Offline

Posts: 1555946485

View Profile Personal Message (Offline)

Ignore
1555946485
Reply with quote  #2

1555946485
Report to moderator
1555946485
Hero Member
*
Offline Offline

Posts: 1555946485

View Profile Personal Message (Offline)

Ignore
1555946485
Reply with quote  #2

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

Posts: 1555946485

View Profile Personal Message (Offline)

Ignore
1555946485
Reply with quote  #2

1555946485
Report to moderator
1555946485
Hero Member
*
Offline Offline

Posts: 1555946485

View Profile Personal Message (Offline)

Ignore
1555946485
Reply with quote  #2

1555946485
Report to moderator
1555946485
Hero Member
*
Offline Offline

Posts: 1555946485

View Profile Personal Message (Offline)

Ignore
1555946485
Reply with quote  #2

1555946485
Report to moderator
kano
Legendary
*
Offline Offline

Activity: 2786
Merit: 1151


Linux since 1997 RedHat 4


View Profile
February 24, 2013, 12:18:13 AM
 #622

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?

It's already actual, since pools can't know who is or isn't verifying what.

Umm what? So you just said that there is no verification of the transaction data that GBT sends. So if there is no double checking, how is there an actual increase in security?

Say my boss installs a security camera by the vending machine, purposefully doesn't turn it on, and then leaves the room. We both know there's a security camera, but we both know it's not working. Is there an actual increase in security? Am I actually deterred from stealing? I would say no.
This is more like he installs a security camera, leaves it on, but "never" looks at the monitor/tape attached.
You really don't know if today might be the day he checks it...
You have yet ever to explain how having the transaction list is 'more' secure - other than to say "It is more secure" thus it must be ... LOL
Let alone how you could actually do anything with it.

The simple point is that if any pool does anything with 'bogus' transactions, you don't need a miner to see it ... any bitcoind can see it ... and the miner would need a bitcoind also ...
If the pool is giving you 'suspect' transaction to mine, it makes no difference until you find a block, but when you find a block those 'suspect' transaction will be there for everyone to see in the blockchain anyway.
But you have NO clear definition of what IS a 'suspect' transaction.

More the point, the reason why you haven't done anything with this data is simply that you cannot code up anything to actually do anything useful with it.

The check itself is a waste.

Basically it's some weird attack at pool ops - and we certainly know one ex-pool op who can't be trusted.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Epoch
Legendary
*
Offline Offline

Activity: 917
Merit: 1000



View Profile
February 24, 2013, 06:19:17 PM
 #623

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.
Just an update: I've been running 2.99.0 for 20 hours now, using the same settings (same pools, pool order, with stratum enabled) as before that led to the unrecoverable WAIT issue. So far the WAIT issue has not re-appeared for me; your extra check in 2.99.0 is looking good so far. I will keep running it.

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

Activity: 2436
Merit: 1012



View Profile
February 26, 2013, 07:43:29 AM
 #624

I'm coming up on 2 days uptime with BFGMiner 2.99.0 myself... pretty happy with how well it's working out so far - now I just hope the SC driver changes work without problems (haha).

In other news, it took about an hour to basically just merge Avalon's cgminer fork into BFGMiner. It doesn't work nicely yet (the whole thing appears as a single Processor), but should work. And since the new driver API is abstracted nicely, you can build an Avalon BFGMiner that supports all the other devices as well. I don't have a complete firmware image for it yet, but that may be right around the corner since we already have OpenWrt support. Too bad I don't have an Avalon to test on. Sad
I was actually surprised how simple merging it turned out to be. While the cgminer fork requires hacks, those ended up all being in code that I could just mirror inside the Avalon driver (since it's abstracted now).
The code is under the git branch "avalon" if anyone wants to give it a go or check it out...

JakeTri
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
February 26, 2013, 12:53:28 PM
 #625

Hi Luke,

I'm running 2.99.0 on multiple systems for several days (3 to be more exact) without any issue so far.
My setup use GPUs and BFL FPGA.

Jake

BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
February 28, 2013, 04:30:32 AM
Last edit: February 28, 2013, 09:33:20 AM by Luke-Jr
 #626

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
February 28, 2013, 09:34:05 AM
 #627

(above firmware seems to be fixed now; please note that if you symlink the BFGMiner OpenWrt Makefile directory, the symlink and directory names must be identical)

xvc
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
March 01, 2013, 07:07:32 AM
 #628

Hi thanks for Your work in developing BFGMiner.
I appreciate that.

I'm new user on bitcointalk and wish to report that the newest version runs smoothly on windows 7 64bit with 2 7970 cards and one ZTEX 1.15y module attached.

Good work !
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
March 04, 2013, 05:55:15 AM
 #629

Just a little early notice.. 3.0 alpha1 will not work correctly with BitForce SC devices.
So expect to upgrade to 3.0 final before your ASICs arrive.

JakeTri
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
March 04, 2013, 03:49:17 PM
 #630

Luke, do you have any new gentoo ebuild for 2.99.0 version ?

I manually patched the latest ebuild available on the bitcoin overlay (2.10.5) to account for the new file names used by the documentation and it build fine but I'm not sure if that was the only change needed.

It would be nice is the bitcoin overlay have a bfgminer-9999 version that build directly form git Smiley

BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
Blackasaurus
Newbie
*
Offline Offline

Activity: 56
Merit: 0



View Profile
March 06, 2013, 06:35:33 AM
 #631

is there a function similar to diablo miner's -f? What it did was it allowed me to game or do GPU semi intensive things on my computer while continuing to mine (of course not as fast)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
March 06, 2013, 06:46:08 AM
 #632

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.

mitty
Sr. Member
****
Offline Offline

Activity: 358
Merit: 250



View Profile
March 06, 2013, 11:36:48 PM
 #633

Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it.

Does anyone have a decent workaround for hanging stratum connections?
Already a known bug: https://github.com/luke-jr/bfgminer/issues/177

I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution.

Thanks!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
March 06, 2013, 11:55:40 PM
 #634

Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it.

Does anyone have a decent workaround for hanging stratum connections?
Already a known bug: https://github.com/luke-jr/bfgminer/issues/177

I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution.

Thanks!
You can workaround the issue by adding the stratum URI as one pool, and the getwork URI as another and --no-stratum to prevent the getwork from trying to auto-upgrade. This way, the stratum one will just die like normal, and then BFGMiner will failover to the next pool (getwork).

mitty
Sr. Member
****
Offline Offline

Activity: 358
Merit: 250



View Profile
March 07, 2013, 01:04:27 PM
 #635

Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it.

Does anyone have a decent workaround for hanging stratum connections?
Already a known bug: https://github.com/luke-jr/bfgminer/issues/177

I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution.

Thanks!
You can workaround the issue by adding the stratum URI as one pool, and the getwork URI as another and --no-stratum to prevent the getwork from trying to auto-upgrade. This way, the stratum one will just die like normal, and then BFGMiner will failover to the next pool (getwork).
Thanks!
Epoch
Legendary
*
Offline Offline

Activity: 917
Merit: 1000



View Profile
March 08, 2013, 12:41:11 AM
 #636

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.
Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.

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

Activity: 2436
Merit: 1012



View Profile
March 08, 2013, 01:15:54 AM
 #637

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.
Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.
What device(s), pool(s) etc? Can you post a debug.log somewhere?

Epoch
Legendary
*
Offline Offline

Activity: 917
Merit: 1000



View Profile
March 08, 2013, 01:48:05 AM
 #638

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.
Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.
What device(s), pool(s) etc? Can you post a debug.log somewhere?
I'm using the following command line (user and pass obfuscated):
Code:
bfgminer ^
-o http://us.ozco.in:3333 -u uuu -p ppp ^
-o http://mint.bitminter.com:8332 -u uuu -p ppp ^
-o http://us3.eclipsemc.com:3333 -u uuu -p uuu ^
-o http://api.bitcoin.cz:8332 -u uuu -p uuu ^
--disable-gpu --no-submit-stale ^
-S all
Debug output here: http://pastebin.com/gj9LnKid

Using the same command line, 2.99.0 uses 0% cpu but 2.99.1 uses 100%. The pastebin output is from bfgminer 2.99.1. This is a system with 2 BFL Singles only.

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

Activity: 2436
Merit: 1012



View Profile
March 08, 2013, 01:54:34 AM
 #639

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.
Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.
What device(s), pool(s) etc? Can you post a debug.log somewhere?
I'm using the following command line (user and pass obfuscated):
Code:
bfgminer ^
-o http://us.ozco.in:3333 -u uuu -p ppp ^
-o http://mint.bitminter.com:8332 -u uuu -p ppp ^
-o http://us3.eclipsemc.com:3333 -u uuu -p uuu ^
-o http://api.bitcoin.cz:8332 -u uuu -p uuu ^
--disable-gpu --no-submit-stale ^
-S all
Debug output here: http://pastebin.com/gj9LnKid

Using the same command line, 2.99.0 uses 0% cpu but 2.99.1 uses 100%. The pastebin output is from bfgminer 2.99.1. This is a system with 2 BFL Singles only.
Can you meet up with me on IRC for some more aggressive investigation?

twobitcoins
Full Member
***
Offline Offline

Activity: 144
Merit: 100


View Profile
March 08, 2013, 04:27:51 AM
 #640

The code in findnonce.c leaks the contents of work structures.  It seems that postcalc_hash() should call "clean_work(&pcd->work);" before "free(pcd);".  Also, postcalc_hash_async should use calloc instead of malloc, otherwise when it calls __copy_work which calls clean_work, there is a risk that clean_work will try to free uninitialized pointers.

This problem likely exists elsewhere in the code.  Several other source files use __copy_work but not clean_work, which is suspicious.  Perhaps it would be safer for all work structures to be allocated on the heap with make_work rather than embedded in other structures.
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 »
  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!