Post
Topic
Board Mining software (miners)
Re: bitHopper: Python Pool Hopper Proxy
by
organofcorti
on 14/08/2011, 09:00:11 UTC
I got almost the same graph of @organofcorti two weeks ago. (from my own open-sourced simulator)
However, 100% agree with @deepceleron

When we have more proportional pools, efficiency doesn't 'seem' to be decaying because we have more chance to hop into < 43% pool all the time.
Earlier share is always more profittable, slicing reduces profit in the long time, and a share from > 43% pool is less profittable than a share from pps pool.

What the graphs show is that for a large number of alternative pools what you gain in efficiency per share for hopping earlier, you lose on the PPS back up. The efficiency remains constant because as you increase the hop off point you don't need to hop to back up and go for 1.0 efficiency anymore. Did your sim include a PPS backup, or just look at per share efficiency?

I'd love you to post your graphs so we can get a side by side comparison.

The real problem is variation, which slicing can help with at a cost to efficiency.

You can hop early if you want (although too early loses you efficiency since there will be fewer available pools under that level leaving you with PPS) but your efficiency wont be any better in the long run. Your variance with be better if you hop since you'll be using PPS a lot and if it wasn't for hoppers being banned and having to manage extra PPS accounts I'd stay hopping early.

I've been hopping only one week at 1.0 and although it's early (given the extra variance doing it this way) I seem to be getting results in the ballpark I was expecting (150 to 250%).



Edit: While I'm on the subject, 43% only applies to one single prop pool with one single backup. The max is slightly different for two prop pools +pps, etc up to about 4 prop+pps when it levels out totally and there is no local maximum after about .2*diff.