Use fallback servers when u/p is incorrect for first server #25

dfc opened this Issue Jul 5, 2011 · 2 comments


None yet
2 participants

dfc commented Jul 5, 2011

Right now btcguild is down to some extent. They are still accepting connections but rejecting all logins. Instead of falling back to the next server on the line poclbm exits out. I expected that it would failover gracefully to the next server in the list.

dfc commented Jul 6, 2011

The following comment was added to this ticket and then removed. I wanted to keep it here for posterity in case anyone suffers from the same confusion as clopez.

clopez#25 said:

Clearly you are not understanding how this works.
When your server fails poclbm tries to conenctg to the next server on the list, and when it fails to the next in a circle round..
But, each X getworks poclbm wll try to falback to the first one. (X is default 2 which is very low for a GPU miner). You should try to reach it. I use --failback=1024

Contrary to clopez's comment I do unserstand how this works. In my opinion the purpose of the fallback code was to gracefully handle pool outages/issues. The fallback server functionality essentially lets miners "fire and forget." I also understand that pool administrators may keep a pool up to test something but reject most users from accessing the pool why they work on something. This is what is/was happening with btcguild. I do not think that btcguild had any nefarious intentions but as it is a pool operator could reject u/p during unplanned downtime and not worry that there would be an automated mass exodus to other pools.

If it really is only an issue of incorrect u/p, the miner running poclbm would see the warning message as well as the lack of submitted shares and easily be able to conlcude that the u/p was wrong.


clopez commented Jul 7, 2011

Yep.. you are right.

Here is a dirty fix


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment