When I first implemented the stat delay, I immediatley changed the pool stats API to show the current round at 1 second with 100 shares. Within 15 minutes the pool speed increased over 200 GH/sec. We are still higher now than before I put in that delay.
That 200 GH/sec is likely all the pool hoppers thinking you found a block as your API reports that condition. So by your data hoppers account for about 8% of your pools peek hash rate. Report a round with a few hours and 1563027+ shares and those 200 GH/sec will prob disappear. I am not convinced that stat delay will solve the issue as there is already a published method to deal with deepbit's delay.
Yeah, my friend on the 24th floor with the 44 Gh/s alerted me to that a minute ago. He apparently has already compensated for Eleuthria's changes by trapping the share submissions of everyone who is mining on his network and doing some deep major magic-fu that way over my head. Sh*t.
Eleuthria, I don't think your stat delay is going to make much difference to the real "pool-hoppers." I will keep my lowly personal 1.2 GH/s pointed at you merely out of loyalty and a hope that pool members continue to debate this here.
I will ask the bigger fish that are around me if they would provide some of their "stat delay compensation" code for me to post here. (doubt it, but worth a try).
I am not yet convinced by the math arguments on either side. Right now, I'm depressed.