If AM waits for hours for an updated hashrate from ccminer that it has connection issues or it is not responding, and does not take time into consideration, it is not the correct behavior.
AM should have a timer that checks every x seconds the reported hashrate from the miner's API, with one minute delay when miner is started to allow all GPUs to be started and send hash rates. Like this if one pool / algo server is offline, it will change to the next most profitable algo from the list. RIGHT ?
If this happens often to you, you should setup or adjust a rule based upon Accepted progress. If the accepted rate doesn't increase after X number of minutes, then have AM apply a template (or you could do another pool) so it will mine something else.
You did not understand the question.
Read again and test it yourself.
Try and unplug network cable to check in the simplest way.
The problem is that if zpool is under DDOS attack, when ccminer tries to submit the shares it shows "connection refused" error. During this period AM does not update hashing rate and remains with the old hashrate for minutes or even hours. This is a big mistake from implementation algorithm because AM waits for updates from a miner that could be broken instead of AM having a computed hash rate per second that will solve a lot of problems like the one from above, when if you have 24 hours statistics you could have ccminer stucked for 12 hours or more instead of having it restarted (or switching to next one from statistics list) by AM like it suppose to do in a correct way.
Dear puwaha , next time try and understand and test things before writing wrong and misleading answers.
Have a nice day.