(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 5.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: Luke-Jr on March 07, 2013, 08:15:54 PM

Quote from: Epoch on March 07, 2013, 07:41:11 PM

Quote from: Luke-Jr on March 06, 2013, 01:46:08 AM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Epoch on March 07, 2013, 07:41:11 PM

Quote from: Luke-Jr on March 06, 2013, 01:46:08 AM

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

Activity: 922

Merit: 1003

Quote from: Luke-Jr on March 06, 2013, 01:46:08 AM

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.

mitty

sr. member

Activity: 359

Merit: 250

Quote from: Luke-Jr on March 06, 2013, 06:55:40 PM

Quote from: mitty on March 06, 2013, 06:36:48 PM

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!

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: mitty on March 06, 2013, 06:36:48 PM

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

Activity: 359

Merit: 250

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

Activity: 2576

Merit: 1186

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

Blackasaurus

newbie

Activity: 56

Merit: 0

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)

JakeTri

full member

Activity: 154

Merit: 100

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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.

xvc

newbie

Activity: 9

Merit: 0

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

Activity: 2576

Merit: 1186

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

JakeTri

full member

Activity: 154

Merit: 100

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: Luke-Jr on February 23, 2013, 02:03:57 PM

Quote from: Epoch on February 23, 2013, 10:11:38 AM

Quote from: Luke-Jr on February 22, 2013, 10:25:55 PM

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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Luke-Jr on February 23, 2013, 04:29:51 PM

Quote from: crazyates on February 23, 2013, 04:25:13 PM

Quote from: Luke-Jr on February 23, 2013, 03:21:47 PM

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?

Quote from: Luke-Jr on February 23, 2013, 04:14:36 PM

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.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: Luke-Jr on February 23, 2013, 02:03:57 PM

Quote from: Epoch on February 23, 2013, 10:11:38 AM

Quote from: Luke-Jr on February 22, 2013, 10:25:55 PM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: crazyates on February 23, 2013, 04:25:13 PM

Quote from: Luke-Jr on February 23, 2013, 03:21:47 PM

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?

Quote from: Luke-Jr on February 23, 2013, 04:14:36 PM

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

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: Luke-Jr on February 23, 2013, 03:21:47 PM

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?

Quote from: Luke-Jr on February 23, 2013, 04:14:36 PM

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.

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