Nice work! When you do get it done, could you paste your raw before and after data somewhere (eg google docs or pastebin)? I'd like to get an idea of mean time differences for the pools to your part of the world. Knowing your part of the world (eg Europe, Americas, Australasia - you don't have to be exact) might be handy since if a number of us do this and people from similar parts of the world have similar differences in LP announces then these penalties coud be built into bitHopper as a default,, and the penalties populated automatically.
Thanks for taking the time. I hope Sukrim is watching - he was keen to do something of the sort.
This LP "who solved the block" procedure exploits an assumption, that a pool that finds a block will be sending notifications to miners earlier than other pools. This may not always be correct.
One has to understand these delays and what long polling is.
When a pool's bitcoin detects a new block (whether they found it themselves or found out about it over the p2p network), the the job of sending notifications goes to pushpool. Pushpool looks at all the open RPC connections that have long polling enabled, and pushes out a notification of the new block to the miners. Long polling keeps a connection open between the miner and the pool, so the miners get a quicker notification of the new block than if they were to just request new work every 15 seconds or so. This reduces obsolete share submissions ("stale" shares), improving pool efficiency.
Pushpool can't instantaneously notify everyone however, due to network bandwidth. Essentially, it goes through a list of all open connections and sends each the LP push consecutively. Small pools can send all their miners the notification quickly, but depending on the pool implementation and the number of open connections, this can take more than five seconds on busy pools. If you are on the start of the list, you get notification fast; at the end of the list, it can take longer. This means that the pool delay can be random per miner, much more significantly than packet transit times. Profiling
your pool connection time may give different results from others, and may give different results even if you restart bithopper on a different day and make new RPC connections to the pool.