Open miningpoolhub opened 10 years ago
It is indeed available . You can change the strategy to round robin.
This strategy only moves from one pool to the next when the current one falls idle and makes no attempt to move otherwise.
Or you can customise with rotate.
This strategy moves at user-defined intervals from one active pool to the next, skipping pools that are idle.
Thanks for the info. But when I try "round-robin", it continually attempts connection to other pool even current pool is not idle. I'm using sgminer 5.0 branch, using multi algo swithcing but it doesn't seem to be related problem.
I confirmed current pool management as "round-robin" from console, and connection attempt logs by process explorer. Isn't it a bug? What I want is that sgminer to not even attempt connection. It doesn't work as document says.
@miningpoolhub It's not a bug and as far as I know the strategies work as intended. I think you're confusing the "pool watchdog" connection with the actual "work pool" connection. Pools are continuously scanned to find out which is alive and which isn't to avoid connection delays or confusion when switching. This is obviously done by connecting to the pool briefly but not getting work from it. If a pool is not alive, then it is skipped in every strategy until it becomes available.
What you are looking for is a variant of the failover strategy where, sgminer scans top to bottom in the priority list for an alive pool. Once you find a pool, you want to "latch" onto it as if it became the top priority, even if a higher priority pool becomes available again. If the current pool dies, then and only then you want to rescan top to bottom for a pool. Also you basically want to "disable" the "pool watchdog" so that no connection will ever be made to a pool unless a pool switch occurs. Detection of alive pools will only happen then as it goes down the list of pools, sort of like a blind-failover.
Am I correct?
@ystarnaud Yes, you are right. I want the strategy you described.
How about adding a "pool-group" on pool settings? Which just treat some group of pools as one when running watchdog.
Example When pools have something like "pool-group" : "hellopool" options, watchdog, failover check may skip these same named pool-group and continue to check other pools.
Detailed strategy When connected to one of the pool-group, watchdog skips same named pool-group pools, and when it's not connected to one of the pool-group, watchdog checks all pools to detect alive pools.
I think this option would make things not conflict with existing options like "fail-over, quota, round-robin, rotate" because it's set to specific pools one by one. Compatibility with existing failover options seems important since some miners would want to run rigs with their existing strategy. With this "pool-group" option, it will not conflict with global failover strategy, but easy to understand how pool switching will occur and works well with multialgo switchings.
I think it may be done by changing priority and quota
From: miningpoolhubmailto:notifications@github.com Sent: 22-07-2014 08:45 AM To: sgminer-dev/sgminermailto:sgminer@noreply.github.com Cc: anshugoyal2mailto:anshu.goyal2@gmail.com Subject: Re: [sgminer] Pool failover strategy addition. (#350)
How about adding a "pool-group" on pool settings? Which just treat some group of pools as one when running watchdog.
When pools have something like "pool-group" : "hellopool" options, watchdog may skip these pool-group with same name and continue to check other pools. I think this option would make things not conflict with existing options like "fail-over, quota, round-robin, rotate" and easy to understand.
Reply to this email directly or view it on GitHub: https://github.com/sgminer-dev/sgminer/issues/350#issuecomment-49693608
@anshugoyal2 Can you tell me more in detail? I thought for it a moment but could't find any method to accomplish it. I don't want just switching, but wants to get rid of wasteful server connection check. It matters a lot.
I will surely send you a sample config and debug(for server connection check) if necessary.
From: miningpoolhubmailto:notifications@github.com Sent: 22-07-2014 12:27 PM To: sgminer-dev/sgminermailto:sgminer@noreply.github.com Cc: anshugoyal2mailto:anshu.goyal2@gmail.com Subject: Re: [sgminer] Pool failover strategy addition. (#350)
@anshugoyal2 Can you tell me more in detail? I thought for it a moment but could't find any method to accomplish it. I don't want just switching, but wants to get rid of wasteful server connection check. It matters a lot.
Reply to this email directly or view it on GitHub: https://github.com/sgminer-dev/sgminer/issues/350#issuecomment-49704602
@anshugoyal2 Would you share it in this issue forum? Or sending email to info@miningpoolhub.com would be appreciated. I will post it later here for sharing the knowledge.
@anshugoyal2 Have you succeeded it?
Any updates? I would like to implement and commit but don't know how others think about new option. Please leave your thoughts.
Sorry to say There are problems in my internet(modem). So I am not succeeded till now. I am sending all replies from my mobile. You have to wait.
Okay can you please tell me your mining urls so I can get to work.
@anshugoyal2 Here are urls for mining.
Scrypt : stratum+tcp://us-east1.hub.miningpoolhub.com:12001 Scrypt-N : stratum+tcp://us-east1.hub.miningpoolhub.com:12002 Keccak : stratum+tcp://us-east1.hub.miningpoolhub.com:12003 Groestl : stratum+tcp://us-east1.hub.miningpoolhub.com:12004 MyriadGroestl : stratum+tcp://us-east1.hub.miningpoolhub.com:12005 x11 : stratum+tcp://us-east1.hub.miningpoolhub.com:12007
Here is sample config for easy testing. { "pools" : [ { "poolname" : "x11", "url" : "stratum+tcp://us-east1.hub.miningpoolhub.com:12007", "user" : "username.workername", "pass" : "x", "algorithm" : "darkcoin-mod" }, { "poolname" : "keccak", "url" : "stratum+tcp://us-east1.hub.miningpoolhub.com:12003", "user" : "username.workername", "pass" : "x", "algorithm" : "maxcoin" }, { "poolname" : "myriadcoin-groestl", "url" : "stratum+tcp://us-east1.hub.miningpoolhub.com:12005", "user" : "username.workername", "pass" : "x", "algorithm" : "myriadcoin-groestl" }, { "poolname" : "scrypt", "url" : "stratum+tcp://us-east1.hub.miningpoolhub.com:12001", "user" : "username.workername", "pass" : "x", "algorithm" : "zuikkis" "nfactor" : "10", }, { "poolname" : "scryptn", "url" : "stratum+tcp://us-east1.hub.miningpoolhub.com:12002", "user" : "username.workername", "pass" : "x", "algorithm" : "zuikkis" "nfactor" : "11", }, { "poolname" : "groestl", "url" : "stratum+tcp://us-east1.hub.miningpoolhub.com:12004", "user" : "username.workername", "pass" : "x", "algorithm" : "groestlcoin" } ] }
You have to sign up first at http://miningpoolhub.com and set your worker's mining target on "My Workers" page. At default, "No work" is set so any of urls will work.
To help you in technical way, all these urls accept "mining.subscribe" message and keep connection at first, but determines if it's connecting to right work at "mining.authorize" phase. Since server can only get user's worker name from "mining.authorize", server doesn't disconnect before this message comes. It keeps connection when workername is valid for current algorithm and port, but disconnects then. This endless job is done in sgminer, it's not that hard to suffer from server side right now but this can be like DDoS when miners increase.
Thanks in advance.
well.!! I am afraid of DDoS. OK then I will post a config file if I am successful for pool group switch.
Thank you for your try and efforts! Really appreciated.
@anshugoyal2 Any updates? Have you succeeded it?
No, Because it is not possible to treat all pools as one(cuase there stratum are different) until you merge all coins using same algorithm into one pool. But as your main problem is regularly pool checking for work you should increase-scan time, failover switch delay and expiry. Also I found a software which can be useful for youe. awesome miner which uses latest sgminer. Pool groups and settings for same algorithm can be configured in it.
scan time, failover switch delay and expiry can help but it's not potential solution that will remain. Endless server connecting attempt makes server lack and more importantly server can't block them because they are not attacking but just mining.
I can recommend awesome miner software but how much percent would they use this software? By thinking about actual rate how many miners would use, I don't think it will be that much. Just about 15%?
And it seems like it can't run on linux, and ASIC things.
I make a proposal again to adding a server group naming option to group servers. You told me that it was not possible since their stratum was different, and one simple option can make things as one server. I can implement it. But I want to hear about what others are thinking.
@miningpoolhub Just to let you know, I will work on the new strategy shortly as I have to make some changes to the pool handling code.
@ystarnaud Thanks. Is that new strategy would solve endless reconnection try problem?
I am looking forward to it.
Hi, sgminer works well, but it would be better if it handles failover server with one more option. Below is the description written at github main page.
Failover The default strategy is failover. This means that if you input a number of pools, it will try to use them as a priority list, moving away from the 1st to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will move back to the higher priority ones.
Similar to that, but I want my sgminer to works as 1st to 2nd, 2nd to 3rd and stay to their pool if 3rd pool doesn't disconnect. When 3rd pool disconnects, sgminer to try from 1st to 2nd, 2nd to 3rd again. No more connection tries when it is already connected to one of them.
This would be good for our pool, Mining Pool Hub. http://miningpoolhub.com We provide switch option for miners to switch to any other coins from website. It works well, but I see endless connection / disconnection to pool1 and pool2 even when it is connected and mining to pool3. Yeah, I knew this normal strategy but it could be better.
Our pool doesn't open port for every worker, it just disconnects by what the worker had chosen on website. So disconnect is intended behaviour. If it stay to one of the pool that doesn't disconnect, it means the worker has connected to right pool with right algo. I think it will be more useful for multipools nowaday.
Thanks.