Bitcoin Forum
December 09, 2016, 05:43:54 PM *
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 245086 times)
aeris
Newbie
*
Offline Offline

Activity: 17


View Profile
February 23, 2013, 09:16:32 PM
 #621

Is it possible BitMinter is vardiff and the others are not?
Could be a clue. I will check it.
But I have a low hashrate (<50MH), IMO even if vardiff, I can't be on a higher diff…

Quote
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.
Oh, sorry for my mistake, this is bitcoin.cz which confusing me, because they push all the pool to stratum.

Ok for GBT, but is there any way in bfgminer to enable stratum only on some pools ?
--no-stratum disable it for all pools, but some need it (bitcoin.cz e.g.) !
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481305434
Hero Member
*
Offline Offline

Posts: 1481305434

View Profile Personal Message (Offline)

Ignore
1481305434
Reply with quote  #2

1481305434
Report to moderator
1481305434
Hero Member
*
Offline Offline

Posts: 1481305434

View Profile Personal Message (Offline)

Ignore
1481305434
Reply with quote  #2

1481305434
Report to moderator
1481305434
Hero Member
*
Offline Offline

Posts: 1481305434

View Profile Personal Message (Offline)

Ignore
1481305434
Reply with quote  #2

1481305434
Report to moderator
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 23, 2013, 09:23:24 PM
 #622

Is it possible BitMinter is vardiff and the others are not?
Could be a clue. I will check it.
But I have a low hashrate (<50MH), IMO even if vardiff, I can't be on a higher diff…
Hmm, yeah, it would be strange for 50 Mh to hit a higher diff.
Can you get it to behave more as expected by using older versions and/or --no-stratum? Maybe try --no-gbt --no-stratum both as well?

Quote
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.
Oh, sorry for my mistake, this is bitcoin.cz which confusing me, because they push all the pool to stratum.

Ok for GBT, but is there any way in bfgminer to enable stratum only on some pools ?
--no-stratum disable it for all pools, but some need it (bitcoin.cz e.g.) !
--no-stratum only disables automatic switching from getwork/GBT.
You can still specify the stratum URI manually. eg stratum+tcp://host:port

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
February 23, 2013, 09:25:13 PM
 #623

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.

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

Activity: 2100



View Profile
February 23, 2013, 09:29:51 PM
 #624

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

Epoch
Legendary
*
Offline Offline

Activity: 917



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

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

Activity: 1932


Linux since 1997 RedHat 4


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

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

Activity: 917



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

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: 2100



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

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


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

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: 2100



View Profile
February 28, 2013, 04:30:32 AM
 #630

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: 2100



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

(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


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

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: 2100



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

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


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

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

Activity: 56


Rawr!


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

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: 2100



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

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

mitty
Sr. Member
****
Offline Offline

Activity: 363



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

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: 2100



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

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: 363



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

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



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

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
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!