In addition consider a few of these facts about mining:
Over time (the longer the time the closer to 100% luck tends to gravitate to) you get the same number of coins on any number of pools whether you mine on the pools with the most hash power or the least.
Obviously human nature makes most gravitate to the pools with higher hash rates but thosexwith lower hash rate hitting fewer blocks and pay those submitting shares more coins than a large pool....
Consider an avg block of blake coin is 25.2
If your pool has a total number of users μ
and hits φ blocks a day (25.2 * φ ) / μ
is the number of Blc each user will earn per day (I am assuming all users have identical / equal hashrate for this and normal flat luck for the example.
So you see the more users mining the more blocks one can expect to solve however those rewards are divided up between a greater number of users.
Again if eu pool hits 2000 blc today and you are mining and are 5% of that you will roughly earn 100 blc.
Suppose the next day you mine in LA & the whole pool earns 500 blc that day but since fewer are mining you are 20% of the pools hash rate your reward is identical.
If you read about pplns you learn it takes 4 rounds (or shifts if in use) to earn full awards.
So pool hopping with round robin puts you at a slight disadvantage vs. staying in one pool.
The other alternative i mentioned earlier is to use load balance on multiple pools. With this strategy cg miner 'attempts' to que work from several pools and balance more or less hashes to the pool(s) providing more or less work.
The reason this strategy is not good in the blake ecosystem is twofold. First getwork is NOT being used , the strantum protocol is. Thus there is very minor or no variance across pools. The second problem is that merged mined coins work tends to get 'stale' and become invalid for the auxuliary chains as each second ticks by.
The stats you see from cg miner that a new block was detected only indicate blocks of blake coin / none of the others.
If you mine like me always in verbose/debug mode the work being rolled is only blake coin also.
So you dilute your hash power this way and also the hash power of all pools you are mining on.
Also cg miner is not 'perfect' when connected to multiple pools and the bottom line is some hash power is wasted, more stale shares are submitted & fewer solves.
In mining you cannot use work from one pool and submit it to another, this is part of the protocol.
The only exception to my examples given here are when a coins difficulty is always rising quickly like bitcoin.
For bitcoin mining you gain a slight edge mining on a pool with the most hash power since on a small pool you may only hit a few blocks a week. If difficulty is always generally rising mining on a smaller pool your reward is much more impacted by bad pool luck although with good luck your rewards can be much larger.
The blake coin system will someday reach a point of adoption where difficulty is always or almost always rising .....
I suggest you read up on pplns & the read me docs with cg miner. I think you will find my conclusions correct mathematically (and they are in practice also since I have actually tested all these & other methods on the merged pools) .....
Sorry for the long post but I hope this fully detailed the reasons why Bluedragon747 & I are correct in the mining strategies we suggest. We want everyone and the network to work with as little waste as possible.
Further reference pplns
http://www.etcwiki.org/wiki/Bitcoin:_PPLNS_vs_PPS 
