Closed platinum4 closed 9 years ago
No it wouldn't. My only advice for now is do not switch pools manually. If you really need to hash on a certain pool, move the pool up in the config (or manually set priorities) and restart sgminer.
It looks like the code will need to be revised to accommodate rental pools. I have an idea but I will need to think on it.
maybe some sort of super-priority
Im thinking a config option that says you can't override this pool's priority.
that would work as well, and most likely be much simpler to add
Yeah but with us on CGWatcher it automatically puts the top pool at priority 0; not sure if we can force it more than that
On Wed, Aug 6, 2014 at 6:02 PM, badman74 notifications@github.com wrote:
that would work as well, and most likely be much simpler to add
— Reply to this email directly or view it on GitHub https://github.com/sgminer-dev/sgminer/issues/332#issuecomment-51409642.
This one has been hit-and-miss, but I just recently successfully performed a 12-hour rental on Keccak, so I think this is target pool dependent. I don't think this needs to be left open for now, but if it crops up, I will re-open it.
Not sure if this is a service issue or a pool-priority respect issue, but I've noticed within the last week, without fail, if a rental goes through on betarigs, sgminer5 fails to walk back up the pool-priority chain and acknowledge that the pool is alive and has work being [ready to be] served. Upon sgminer5 restart, it immediately hits the pool with no problems and starts hashing as it should, and I'm not particularly worried about where or which pool down the chain it goes afterward; just want people to quit bitching at me and my inbox as if I'm robbing them of precious non-profit mining minutes. My config file is found here: https://bitcointalk.org/index.php?topic=632503.msg7680589#msg7680589
This is an issue valid for builds AFTER July 2nd, 2014, which ystarnaud's [3rd] test build of that day has been working flawlessly. This may be pre-jansson push, not sure.