OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30

[Luke-Jr]

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?

[7000pool]

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 ?!
http://mansoa.org/21.png

[Luke-Jr]

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.

[7000pool]

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 ?!
http://mansoa.org/21.png

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
the balance work with COM miners
but don't work with PXY

[Luke-Jr]

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?

[hurricandave]

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]

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]

O.k. I was used to using load-balance on an older version.

[nicehashdev]

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

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]

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

[Luke-Jr]

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

[7000pool]

only accepting shares from pool 0
what am i doing wrong ?!
http://mansoa.org/21.png

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 

[nicehashdev]

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

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]

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]

It work BFGminer with technobit miner hardware (HEX16a & other...) ?

[nicehashdev]

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]

@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

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.

Tried flashing from OpenWrt without success, different platform

Code:

PLATFORM=TLMR3020

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

[nwoolls]

@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

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.

Tried flashing from OpenWrt without success, different platform

Code:

PLATFORM=TLMR3020

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

The scripts I use for compiling the 703n firmware are available on Github:

https://github.com/nwoolls/BFGMiner-OpenWrt-Tools

and 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

[chup]

Tried flashing from OpenWrt without success, different platform

Code:

PLATFORM=TLMR3020

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

The scripts I use for compiling the 703n firmware are available on Github:

https://github.com/nwoolls/BFGMiner-OpenWrt-Tools

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

[vegasguy]

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