Kurvanga
Newbie
Offline
Activity: 14
Merit: 0
|
|
November 08, 2014, 08:38:42 AM |
|
How can I fix that? pool does not see any work of course. [2014-11-02 11:42:21] HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl
Try updating libcurl (if you're using Linux). Definitely try: sudo apt-get install build-essential autoconf automake libtool pkg-config libcurl4-gnutls-dev libjansson-dev uthash-dev libncursesw5-dev libudev-dev libusb-1.0-0-dev libevent-dev libmicrohttpd-dev hidapi sudo apt-get update sudo apt-get upgrade You may also have to rerun ./configure and make again... His libcurl is fine. No version of libcurl supports stratum+tcp, so this is an ordinary message before it uses its own implementation. Also, I don't see any actual problems in his log... Thanks for the reply guys Apart from that there is zero activity on the pool from my worker when i'm using BfgMiner same for the bfgminer output. I can post it if needed when i'm at home. ltc.com is dead...just visited the website and it's just junk...so, probably try multipool.us (anything scrypt also mines doge) or liteguardian.com if you only want to mine litecoin... Hehe the poll address is fake just intentionally, ok so I downloaded 4.10 ver for my windows machine and it acts the same when i'm trying to mine with my gpu, bfgminer-3.10.7-win64 works fine with the pool i use , bfgminer-4.10.0-win64 does not. The same issue is on linux. May it be a pool is incompatible? I am mining there with dmaxl's cgminer but it's not updated anymore.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 08, 2014, 12:33:54 PM |
|
Hehe the poll address is fake just intentionally, ok so I downloaded 4.10 ver for my windows machine and it acts the same when i'm trying to mine with my gpu, bfgminer-3.10.7-win64 works fine with the pool i use , bfgminer-4.10.0-win64 does not. The same issue is on linux. May it be a pool is incompatible? I am mining there with dmaxl's cgminer but it's not updated anymore. Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression. 1. Enter anything random for Session name, click Go. 2. For "Working commit:", put bfgminer-3.10.7 3. For "Broken commit:", put bfgminer-4.10.0 4. Click "Start" 5. Wait for the webserver to build a CUSTOM version of BFGMiner (ignore the version it claims to be when you run it). 6. Download the custom build, and test if it works. Click the relevant button. 7. Go back to step 5 until it gives you a "verdict" on which change is guilty for breaking it. 8. Post the final result here.
|
|
|
|
Elmit
|
|
November 08, 2014, 12:49:31 PM |
|
sh: ./make-release: No such file or directory
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 08, 2014, 12:54:10 PM |
|
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...
|
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 08, 2014, 01:24:24 PM |
|
So wait for the next build...
|
|
|
|
AJinNYC
Member
Offline
Activity: 84
Merit: 10
Bored with you morons.
|
|
November 08, 2014, 09: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?
|
Done with this forum. Goodbye all.
|
|
|
nwoolls
|
|
November 08, 2014, 09: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?
e.g.: --set amu:clock=x0881 --set nfy:osc6_bits=53
|
MultiMiner: Any Miner, Any Where, on Any Device | Xgminer: Mine with popular miners on Mac OS X
|
|
|
chup
Sr. Member
Offline
Activity: 736
Merit: 262
Me, Myself & I
|
|
November 10, 2014, 12:39:50 PM |
|
Should this image work on TL-MR3020 3G? (Atheros AR9330 rev.1, 4MB flash and 32MB RAM)? Thx.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 10, 2014, 10: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:- 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/
|
|
|
|
damm315er
|
|
November 10, 2014, 11:57:26 PM |
|
Is supporting neoscrypt in BFGminer's future?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 11, 2014, 12:43:35 AM |
|
Is supporting neoscrypt in BFGminer's future?
If someone contributes the code...
|
|
|
|
nicehashdev
|
|
November 13, 2014, 10: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.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 13, 2014, 03:03:17 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? 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
|
|
|
|
nicehashdev
|
|
November 13, 2014, 05: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? 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.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 13, 2014, 05: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? 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.
|
|
|
|
Mario241077
Legendary
Offline
Activity: 1302
Merit: 1000
ORB has a good chance to grow.
|
|
November 14, 2014, 06:04:14 AM |
|
Please add neoscrypt as soon as possible
|
|
|
|
7000pool
Newbie
Offline
Activity: 9
Merit: 0
|
|
November 14, 2014, 11:38:14 AM |
|
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
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 14, 2014, 11:56:31 AM |
|
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?
|
|
|
|
7000pool
Newbie
Offline
Activity: 9
Merit: 0
|
|
November 14, 2014, 11:59:00 AM |
|
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
|
|
|
|
|