Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:02:16 PM |
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) only work with the first pool & discard the rest ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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?
|
|
|
|
7000pool
Newbie
Offline
Activity: 9
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:08:34 PM |
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) only work with the first pool & discard the rest ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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 ?! http://mansoa.org/21.png
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:20:05 PM |
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) only work with the first pool & discard the rest ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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 ?! ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fmansoa.org%2F21.png&t=665&c=I6-wMTJP1EOQog) My guess is your other pools have higher share diff than 305u.
|
|
|
|
7000pool
Newbie
Offline
Activity: 9
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:29:05 PM |
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) only work with the first pool & discard the rest ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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 ?! http://mansoa.org/21.pngMy 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 the balance work with COM miners but don't work with PXY
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:31:35 PM |
|
i'm trying to use --balance with --stratum-port <arg> it dosn't balance shares between pools ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) only work with the first pool & discard the rest ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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 ?! ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fmansoa.org%2F21.png&t=665&c=I6-wMTJP1EOQog) 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?
|
|
|
|
hurricandave
Legendary
Offline
Activity: 966
Merit: 1003
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:32:38 PM |
|
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......
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:42:05 PM |
|
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.
|
|
|
|
hurricandave
Legendary
Offline
Activity: 966
Merit: 1003
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:45:59 PM |
|
O.k. I was used to using load-balance on an older version.
|
|
|
|
nicehashdev
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 12:46:43 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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) 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). 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.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 01:06:59 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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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...
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 01:27:33 PM |
|
only accepting shares from pool 0 what am i doing wrong ?! ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fmansoa.org%2F21.png&t=665&c=I6-wMTJP1EOQog) 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...
|
|
|
|
7000pool
Newbie
Offline
Activity: 9
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 01:37:43 PM |
|
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... thnx man ![Kiss](https://bitcointalk.org/Smileys/default/kiss.gif)
|
|
|
|
nicehashdev
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 07:29: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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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... 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). I think it is much easier and convenient to make benchmarking on miner side; to miners that don't want benchmark to be run on start - they can manually specify performance speeds in config. About multi mining - if two algos can run on GPUs, you can still avoid any possible issues, just create two connections - one is for GPU intensive algos and another one for GPU memory intensive algos.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 14, 2014, 07:41:19 PM |
|
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?
|
|
|
|
VoodooServ
Newbie
Offline
Activity: 8
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2014, 06:21:18 AM |
|
It work BFGminer with technobit miner hardware (HEX16a & other...) ?
|
|
|
|
nicehashdev
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2014, 03:32:32 PM |
|
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.
|
|
|
|
chup
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 736
Merit: 262
Me, Myself & I
|
![](https://bitcointalk.org/Themes/custom1/images/post/question.gif) |
November 15, 2014, 07:14:10 PM |
|
Should this image work on TL-MR3020 3G? (Atheros AR9330 rev.1, 4MB flash and 32MB RAM)? Thx. Tried flashing from OpenWrt without success, different platform . MR3020 and WR703n are same hardware (with minor changes of more LEDs and one switch) for EU and CH market. Tried installing bfgminer on OpenWrt, but not enough space, at the start I have 80% available memory. I don't know what packages I could remove to make more room for bfgminer. Anyone could help? ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
nwoolls
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2014, 07:35:29 PM |
|
Should this image work on TL-MR3020 3G? (Atheros AR9330 rev.1, 4MB flash and 32MB RAM)? Thx. Tried flashing from OpenWrt without success, different platform . MR3020 and WR703n are same hardware (with minor changes of more LEDs and one switch) for EU and CH market. Tried installing bfgminer on OpenWrt, but not enough space, at the start I have 80% available memory. I don't know what packages I could remove to make more room for bfgminer. Anyone could help? ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) The scripts I use for compiling the 703n firmware are available on Github: https://github.com/nwoolls/BFGMiner-OpenWrt-Toolsand the package list I use: libcurl libpthread jansson libusb-1.0 kmod-usb-serial kmod-usb-serial-cp210x kmod-usb-serial-ftdi kmod-usb-acm -kmod-gpio-button-hotplug hotplug2 -dnsmasq -uboot-envtools -6relayd -libgcc -libc -firewall -iptables -ip6tables -swconfig -ppp -ppp-mod-pppoe -kmod-ipt-nathelper -kmod-ledtrig-netdev libncurses screen
|
MultiMiner: Any Miner, Any Where, on Any Device | Xgminer: Mine with popular miners on Mac OS X
|
|
|
chup
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 736
Merit: 262
Me, Myself & I
|
![](https://bitcointalk.org/Themes/custom1/images/post/question.gif) |
November 15, 2014, 09:05:01 PM |
|
Tried flashing from OpenWrt without success, different platform . MR3020 and WR703n are same hardware (with minor changes of more LEDs and one switch) for EU and CH market. Tried installing bfgminer on OpenWrt, but not enough space, at the start I have 80% available memory. I don't know what packages I could remove to make more room for bfgminer. Anyone could help? ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) The scripts I use for compiling the 703n firmware are available on Github: https://github.com/nwoolls/BFGMiner-OpenWrt-Toolsand the package list I use: libcurl libpthread jansson libusb-1.0 kmod-usb-serial kmod-usb-serial-cp210x kmod-usb-serial-ftdi kmod-usb-acm -kmod-gpio-button-hotplug hotplug2 -dnsmasq -uboot-envtools -6relayd -libgcc -libc -firewall -iptables -ip6tables -swconfig -ppp -ppp-mod-pppoe -kmod-ipt-nathelper -kmod-ledtrig-netdev libncurses screen Thx for the support, still don't know should platform be changed in line 7 of cross-compile-bfgminer.sh to something else for MR3020? I think I'm very close bricking this small thing. Maybe I'll try to exchange MR3020 for WR703n and save it's life... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
vegasguy
Legendary
Offline
Activity: 1610
Merit: 1003
"Yobit pump alert software" Link in my signature!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 17, 2014, 04:05:14 PM |
|
Guys I have zeus thunder x6, and Ive been at this days trying to make it work with latest version of bfgminer. Ive read ALL of the text files many times over and it mentions very little about zeus miners. The latest version I can get working is the last one that has native zeus support 4.31 (I think), thats about 4 months old. Is it possible to get the latest version working using the com port commands. If so what command do I use to set the clock rate to 255? What command to set the number of chips to 128? In cgminer to set clock , chips and serial, I would use:
--zeus-chips 128 --zeus-clock 328 --scan-serial \\.\COM12
What is the equivalent in latest bfgminer?
I have used the zadig tool to convert my drivers, but then the latest BFGminer flat does not see them. Ive used the "M" and "+" and typed "all" and tried "auto" and even tried manual ports I know are correct such as //./COM4 . Cant get them to detect.
Does it just not work in later versions and needs to be specifically complied for zeus?
Thank you in advance
Vegas
|
I want to make sure everyone knows that I just released my software called "Yobit pump alert". THis is custom software that uses an algo to detect the start of a pump here on yobit, the second it starts. YOu can even filter the coins you see by price. Most pumps start less than 100 sats , so you can easily filter the cheap coins, so they are the only ones displayed https://bitcointalk.org/index.php?topic=1945937.msg20241953#msg20241953
|
|
|
|