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......
Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 4. (Read 308307 times)
November 14, 2014, 08:32:38 AM
November 14, 2014, 08:31:35 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
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
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 ?!
it is same pool with different worker only same diff same IP:port & everything
the only thing is changed is the worker
November 14, 2014, 08:29:05 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
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
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 ?!
http://mansoa.org/21.png
it is same pool with different worker only same diff same IP:port & everything
the only thing is changed is the worker
the balance work with COM miners
but don't work with PXY
November 14, 2014, 08:20:05 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
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
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 ?!
November 14, 2014, 08:08:34 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
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
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 ?!
http://mansoa.org/21.png
November 14, 2014, 08:02:16 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
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
Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)?
What symptoms are you seeing?
November 14, 2014, 07:59:00 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
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
November 14, 2014, 07:56:31 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
Are the pools working on the same blockchain?it dosn't balance shares between pools
only work with the first pool & discard the rest
If not, are you using 4.99.0 and giving the pools separate goals?
November 14, 2014, 07:38:14 AM
i'm trying to use --balance with --stratum-port
it dosn't balance shares between pools
only work with the first pool & discard the rest
it dosn't balance shares between pools
only work with the first pool & discard the rest
November 14, 2014, 02:04:14 AM
Please add neoscrypt as soon as possible
November 13, 2014, 01:26:06 PM
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?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.
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.
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. November 13, 2014, 01:13:31 PM
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?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.
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. 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".
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.
November 13, 2014, 11:03:17 AM
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?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.
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
November 13, 2014, 06:59:32 AM
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.
BTW; as soon as you prepare BFG version with these features, we are ready to update our stratum proxy @ NiceHash to support this and give it a try.
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.
BTW; as soon as you prepare BFG version with these features, we are ready to update our stratum proxy @ NiceHash to support this and give it a try.
November 10, 2014, 08:43:35 PM
Is supporting neoscrypt in BFGminer's future?
If someone contributes the code... November 10, 2014, 07:57:26 PM
Is supporting neoscrypt in BFGminer's future?
November 10, 2014, 06:54:38 PM
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:
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/
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/
November 10, 2014, 08:39:50 AM
@nwoolls
Could you please update the WR703n firmware to BFGminer4.8. I cannot do it myself, got stuck on the size of the firmware.
Thanks
Could you please update the WR703n firmware to BFGminer4.8. I cannot do it myself, got stuck on the size of the firmware.
Thanks
bfgminer-ar71xx-generic-tl-wr703n-v4.10.0-r1-squashfs-factory.bin
bfgminer-ar71xx-generic-tl-wr703n-v4.10.0-r1-squashfs-sysupgrade.bin
Sorry for the delay.
Should this image work on TL-MR3020 3G? (Atheros AR9330 rev.1, 4MB flash and 32MB RAM)? Thx.
November 08, 2014, 05:11:17 PM
How would I overclock more than one ASIC unit? I'm using MultiMiner, but I believe that just sits on top of BFGMiner as a GUI.
I got 8 Antminer U2s and one CryptoRig Hitchhiker NanoFury. I can overclock the NanoFury without an issue, but when I try to overclock the Antminers, in addition to the NanoFury, I get the same performace out of the Antminers as I do when I don't overclock them. What's the proper syntax to use when trying to target more than one device?
I got 8 Antminer U2s and one CryptoRig Hitchhiker NanoFury. I can overclock the NanoFury without an issue, but when I try to overclock the Antminers, in addition to the NanoFury, I get the same performace out of the Antminers as I do when I don't overclock them. What's the proper syntax to use when trying to target more than one device?
e.g.:
Code:
--set amu:clock=x0881 --set nfy:osc6_bits=53
November 08, 2014, 05:07:48 PM
How would I overclock more than one ASIC unit? I'm using MultiMiner, but I believe that just sits on top of BFGMiner as a GUI.
I got 8 Antminer U2s and one CryptoRig Hitchhiker NanoFury. I can overclock the NanoFury without an issue, but when I try to overclock the Antminers, in addition to the NanoFury, I get the same performace out of the Antminers as I do when I don't overclock them. What's the proper syntax to use when trying to target more than one device?
I got 8 Antminer U2s and one CryptoRig Hitchhiker NanoFury. I can overclock the NanoFury without an issue, but when I try to overclock the Antminers, in addition to the NanoFury, I get the same performace out of the Antminers as I do when I don't overclock them. What's the proper syntax to use when trying to target more than one device?
Jump to: