@puwaha, @patrike

question for you if you don't mind. I understand your argument for using 24hr averages (and preferably even longer) vs instant and having running switching no more often than once an hour or so. I'm still to see the results - I used to run switching every 1-5 minutes with a high threshold for switching, like 30-40% (call it 1/1/30). I need to run it for the whole day or 2 to make a conclusion. But here's a problem that surfaced right away when using 24hr/1hr pattern (i'll call it 24/1/10) - bad pools. So if I run 1/1/30 and the pool is bad, which can be manifested in multiple ways, for instance AM keeps restarting a miner saying that the process is not running (though accepted # keeps ticking) or no accepted blocks are coming in, then the pool will potentially quickly drop off the top of the profitability table and AM will happily switch to (hopefully) a non-corrupted pool. Now if the same problem arises during my 24/1/10 configuration, I'm potentially screwed for hours - the best AM miner can do here (I wish it could be more intelligent dealing with multiple restarts, except just stop trying after X times and stopping the miner in the process) is to keep restarting the miner, which does no good, since it keeps going back to the same corrupted pool. Have you run into something like this before (btw, it seems that lots of pools are having problems in the last couple days)? How would you deal with it?

PS: I find it quite useful to monitor the # of accepted blocks in the last 3-5 minutes and if that number stalls force profit switching and restarting the rig. HOWEVER, and that might be another question, it seems that AM has a "miner not running, restarting" routine that's run outside of the rules framework and I can't figure out how to intercept it and, potentially, force it to run a profit switching before restarting the miner - have you ever dealt with that one?

Thanks!