for bfgminer -o http://localhost:8332 -u username -p password --generate-to 1and_so_on i am getting [2014-11-23 23:31:27] bfgminer: --generate-to: unrecognized option Am I using it wrong? Are you using the latest git or one of the 4.99.x prereleases? If not, then your version is too old for that parameter... The stable equivalent is --coinbase-addr |
|
|
|
it is possible to get an old bitburner miner working with bfgminer? i try a few drivers but nothing it doest get detected.
BitBurner never sent us anything to work with, so was never supported... So I guess you're stuck with cgminer's fork unless you want to take the effort to port their driver. |
|
|
|
Help needed, please.
I've got Avalon2 220GH miner. It worked very well but I decided to upgrade the FW and SW. Firstly, I downloaded and flashed the last Avalon2 .bin - no success. Then I found somewhere that this version of ASIC should be updated with FW for Avalon1. Done, but again no success. I don't remember if I messed with cgminer (I was going to), it was months ago.
Eventually I can't access the miner's interface to fix this problem. I get into failsafe mode (rapid LED blinking) but this doesn't help. Advanced IP Scanner sees the router as a 'dead' host. No ping, no telnet, no ssh.
Any chance to help me? Thanks.
If you plug the modules into a PC, you can just run BFGMiner and it should work fine. |
|
|
|
KnCMiner Neptune support is finally shaping up, so 5.0 will include a new "kncasic" driver. Additionally, I have implemented support for the Keccak proof-of-work algorithm in BFGMiner for two reasons: It is NOT in any way intended as an endorsement of whatever altcoin(s) might be using it. Finally, this also has the changes so far discussed between nicehashdev and myself following 4.99.0. DRAFT Human readable changelog:- Multi-blockchain support: BFGMiner can now be told which pools use the same "mining goals", and will track the blockchain independently for ones that don't. This allows you to mine multiple cryptocurrencies concurrently using any pool strategy (including balance and load-balance).
- Multi-algorithm support: BFGMiner is now capable of hashing on both scrypt and SHA256d work at the same time, and you can assign the mining algorithm to use on a per-goal basis. As with multi-blockchain support, this works even in balancing strategies. Note that at this time, only CPU, OpenCL, and Proxy drivers actually support multiple algorithms at the same time (DualMiner must be preconfigured for only one, and GridSeed remains scrypt-only).
- Stratum extensions for mining goals: New experimental methods mining.capabilities and mining.set_goal for Stratum allow you to expose control of the mining algorithm to the pool. These extensions are considered draft and may be changed based on the needs of multiblockchain pool operators.
- RPC: Also extended for multiple mining goals/algorithms. Interface is subject to change.
- kncasic: New driver for KnCMiner Neptune (and 2nd-gen Jupiter modules).
- Titan: Work flushing optimisations from KnCMiner.
- Keccak: Support for the SHA-3 winner hash as a proof-of-work algorithm.
The code is in git under the bfgminer branch (and tagged bfgminer-4.99.1). OpenWrt and Windows downloads are available from http://luke.dashjr.org/programs/bitcoin/files/bfgminer/4.99.1/ |
|
|
|
|
Hm, actually, benchmarking might be difficult in general since we don't know we're comparing apples to oranges.
For example, consider the following setup (remember, all within a single BFGMiner instance):
4 CPU cores (any algorithm)
4 GPUs (SHA256d, scrypt, Keccak)
2 DualMiners (SHA256d, scrypt)
2 ZeusMiners (scrypt only)
2 NanoFurys (SHA256d only)
In this case, what is the "performance" of each algorithm?
There's probably a number of different ways a multipool might want to react to this. :/
|
|
|
|
Performance means hashrate. What is important to give proper ratios - how much is algo1 faster than algo2, but you can clearly replace it pure speed. Measuring speed on pool side is out of the question, because miner has to be connected for a while, thus meaning that every restart of miner would cause pool first to "test" all algorithms for the miner (in case of having 10 algorithms this means 50 minutes of testing for speed). Makes sense why the pool can't measure it, but most pools/miners only use one algo, and it isn't fair to waste 1 minute doing benchmarks of 60 algos when they only really want one... Perhaps another solution is to add some way I can tell you the precise hashrate regardless of shares? Yes, using performance parameter when sending mining.capabilities. The pool can then calculate exactly, which algorithm gives best profit according to provided performance ratios and current earnings for each algorithm. I meant like stratum's (undocumented, maybe unspecified?) mining.get_hashrate method. If BFGMiner supports 294234 different algorithms, it doesn't make sense to benchmark them all (wasting electricity) before we even know what the pool might possibly use. Makes much more sense to let the pool do the benchmarking as needed... then the miner gets some credit (even if not ideal) during the benchmarking, and only benchmarks algorithms the pool will actually use. |
|
|
|
Performance means hashrate. What is important to give proper ratios - how much is algo1 faster than algo2, but you can clearly replace it pure speed. Measuring speed on pool side is out of the question, because miner has to be connected for a while, thus meaning that every restart of miner would cause pool first to "test" all algorithms for the miner (in case of having 10 algorithms this means 50 minutes of testing for speed). Makes sense why the pool can't measure it, but most pools/miners only use one algo, and it isn't fair to waste 1 minute doing benchmarks of 60 algos when they only really want one... Perhaps another solution is to add some way I can tell you the precise hashrate regardless of shares? |
|
|
|
only accepting shares from pool 0 what am i doing wrong ?!  Sorry, I just now noticed you're using the stratum proxy feature. Stratum doesn't support this kind of thing, so the proxy ends up not doing any balancing at all right now... |
|
|
|
Regarding mining.capabilities:
The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])
In this case, for set_multialgo, we would use parameter list as following:
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])
This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner. Isn't this something you can have users configure on your website? I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs. I suppose it makes sense to tell the pool as well, so it can try to offer the best deal... Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm. How about we take your idea, but with some minor changes to these options? mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}) This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option. Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point  As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together. So maybe: mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}}) Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm". Well, that wouldn't work. Most of the time (at least right now, all of the time), cost and performance are unknowns - so BFGMiner has nothing to send for those. In practice, I was thinking of sending: mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":[],"SHA256d":[]}}) Another thing maybe we need to consider is how you would want to handle rigs that have a set of scrypt+SHA256d devices (CPU, OpenCL, maybe DualMiner in the future), and also SHA256d-only devices... Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already. Yes, this is already the case. If you send empty parameters without performance and costs, then pool cannot know what kind of performance of each algorithm is reached, thus cannot make decision which algorithm work to provide. Giving performance parameter is mandatory. I suggest to get performance by doing "benchmarking" of each algorithm prior actual connection to the pool - this is good also because people don't have to do manual measurements any more as they have to do it now. Cost should be still just optional and by default 0 - rare people actually set cost factors (looks like most GPU miners use free electricity). Benchmarking prior to pool connection is IMO not reasonable. What does "performance" even mean here, anyway? If it's just hashrate, why not just measure it pool-side based on shares submitted? When it comes to multiple miners that are capable of mining more algorithms at the same time; certain resource (let's assume GPU) is in most cases saturated 100% - if it is not, algorithm is not well coded. I suggest to simply run multiple instances of miners (one that takes CPU resource, one takes GPU resources,...) and establish multiple connections - of course, with each one having own list of supported algorithms with proper performance factors. BFGMiner aims to support everything within one miner instance  Also note that generally, "memory-hardish" algorithms like scrypt can be run in parallel with SHA2, with only a minor performance hit on the SHA2 hashing... |
|
|
|
If the stratum arg is implemented correctly shouldn't the pool line display have Diff:305u +Strtm Lu:[time]
all I see is the "+" without Strtm. Or a line that says Connected to multiple pools......
You're used to an older version. He's connected to 5 pools, (pools 0, 1, 2, 3, and 4), with work update notification (the +). Exact protocol being used isn't visible when there are multiple active pools. |
|
|
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools  only work with the first pool & discard the rest Are the pools working on the same blockchain? If not, are you using 4.99.0 and giving the pools separate goals? same pool & blockchain with different login/worker only using 4.10.0 Are you sure it's not being balanced? Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)? What symptoms are you seeing? only accepting shares from pool 0 what am i doing wrong ?! My guess is your other pools have higher share diff than 305u. it is same pool with different worker only same diff same IP:port & everything the only thing is changed is the worker Can you run with --log-file debug.log --debuglog and PM me a Google Drive ZIP of the debug.log file? |
|
|
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools only work with the first pool & discard the rest Are the pools working on the same blockchain? If not, are you using 4.99.0 and giving the pools separate goals? same pool & blockchain with different login/worker only using 4.10.0 Are you sure it's not being balanced? Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)? What symptoms are you seeing? only accepting shares from pool 0 what am i doing wrong ?! My guess is your other pools have higher share diff than 305u. |
|
|
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools only work with the first pool & discard the rest Are the pools working on the same blockchain? If not, are you using 4.99.0 and giving the pools separate goals? same pool & blockchain with different login/worker only using 4.10.0 Are you sure it's not being balanced? Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)? What symptoms are you seeing? |
|
|
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools only work with the first pool & discard the rest Are the pools working on the same blockchain? If not, are you using 4.99.0 and giving the pools separate goals? |
|
|
|
Regarding mining.capabilities:
The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])
In this case, for set_multialgo, we would use parameter list as following:
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])
This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner. Isn't this something you can have users configure on your website? I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs. I suppose it makes sense to tell the pool as well, so it can try to offer the best deal... Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm. How about we take your idea, but with some minor changes to these options? mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}) This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option. Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together. So maybe: mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}}) Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm". Well, that wouldn't work. Most of the time (at least right now, all of the time), cost and performance are unknowns - so BFGMiner has nothing to send for those. In practice, I was thinking of sending: mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":[],"SHA256d":[]}}) Another thing maybe we need to consider is how you would want to handle rigs that have a set of scrypt+SHA256d devices (CPU, OpenCL, maybe DualMiner in the future), and also SHA256d-only devices... Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already. Yes, this is already the case. |
|
|
|
Regarding mining.capabilities:
The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])
In this case, for set_multialgo, we would use parameter list as following:
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])
This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner. Isn't this something you can have users configure on your website? I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs. I suppose it makes sense to tell the pool as well, so it can try to offer the best deal... Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm. How about we take your idea, but with some minor changes to these options? mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}) This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option. Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point |
|
|
|
Is supporting neoscrypt in BFGminer's future?
If someone contributes the code... |
|
|
|
So after a ton of work, multi-blockchain and multi-algo support for BFGMiner is starting to shape up. I would greatly appreciate if others interested in this field could contribute by testing and/or improving documentation as needed to make usage of new features easily accessible. "Multipool" operators are asked to review the new stratum extension proposals to ensure they cover all desired use cases and/or help test them. Front-end developers (or anyone using RPC) likewise are welcome to critique the RPC changes. If anyone wants to get their favourite proof-of-work algorithm added for 5.0, now is the time to propose your code in a merge/pull request (sorry, I don't have time to write this code myself at the moment, so you'll need to bring-your-own-code). DRAFT Human readable changelog:- Multi-blockchain support: BFGMiner can now be told which pools use the same "mining goals", and will track the blockchain independently for ones that don't. This allows you to mine multiple cryptocurrencies concurrently using any pool strategy (including balance and load-balance).
- Multi-algorithm support: BFGMiner is now capable of hashing on both scrypt and SHA256d work at the same time, and you can assign the mining algorithm to use on a per-goal basis. As with multi-blockchain support, this works even in balancing strategies. Note that at this time, only CPU, OpenCL, and Proxy drivers actually support multiple algorithms at the same time (DualMiner must be preconfigured for only one, and GridSeed remains scrypt-only).
- Stratum extensions for mining goals: New experimental methods mining.capabilities and mining.set_goal for Stratum allow you to expose control of the mining algorithm to the pool. These extensions are considered draft and may be changed based on the needs of multiblockchain pool operators.
- RPC: Also extended for multiple mining goals/algorithms. Interface is subject to change.
- Titan: Work flushing optimisations from KnCMiner.
The code is in git under the bfgminer branch (and tagged bfgminer-4.99.0). Windows downloads are available from http://luke.dashjr.org/programs/bitcoin/files/bfgminer/4.99.0/ |
|
|
|
So wait for the next build... |
|
|
|
sh: ./make-release: No such file or directory I don't know what you're trying to say. It's expected that some builds throughout this process will fail, and it should automatically move on... |
|
|
|
|
Show Posts
