i got an interesting mail (my answer is included):
Am 18.07.2011 19:15, schrieb
> If I understand this correctly, I think your addition will lower the variance of returns slightly, but not have any affect on the expected returns.
I think it will have an affect.
example 1: two pools found a block next to each other with the same speed. original bithopper will stick with the one with the lower shares. that could be good or worse.
if it's good you earn much more; if its bad you loose the half.
a pool with a very high hashrate finds a block righte before a small pool.
original bithopper will switch to the small one. it would be better to try to submit shares to the fast pool and - after that - continue with the small one.
^^ thats my impression. please correct me if i am wrong
I'm at work right now, but I would like to discuss it further either in here or on the forums (I still don't have proper non-newbie privledges necessary to post in the thread).
> IMO, it adds unnecessary complexity for a small decrease in variance. Can we please add it with a switch, such as --time-slicing=[yes|no] ?
^^ bithopper itself is not from me.
so if you don't want that slicing right now, just stick with the original version.
if it gets merged (i hope so), i prefer a switch too (i would even suggest pluggable modules through c00w's planned website - so if you're watching you can change the strategy on the fly)
> If two pools are both at X% and both are standard proportional pools, the expected return on shares is equal. Due to time-lag in pulling stats, one should choose the pool with a lower hashrate for highest return (although if hoppers are a large portion of the hashrate, this is unstable and will cause the hashrate, #workers, and optimal pool to oscillate unstably).
my recent version (see attachment; as i got ill i was not able to publish it right now. especially the "ghash pool bonus" is not well tested (i should write a program to simulate pool stats)) has a few improvements:
- bonus for BIG pools (i now; you don't like that. but big pools goes to 40% diff very fast, so i think its a good idea to catch up)
- tries to stay longer at one pool (means: if after a ten minute round the same pool got a new time slice it stays there)
- tries to start the longest (means most profitable) slice as soon as a new block is found, a pool lags or another slice finished
thank you for you thoughts. i just think we need a long-time sim here - and i am still planning to work on a bitcoin patch to better detect btc guild / deepbit blocks
as i said: i got ill
i just managed to continue the work the pool-ghash adaption.
you can get it here:
(i promise i will make a git push; but with that headache..BBRRRRR)
(this time its a zip; i just like changes
LOL just recognized it was a github comment...my headache ...
anyway: please tell me what you think about it