It means that if, for some reason, mirc didn't execute the command associated with a timer in time, it triggers it right after it's finished doing whatever it's doing and before the next scheluded repetition. At least that's the effect I understand (I use it in one of my scripts to animate a dialog). It's not easy to understand exactly what I mean unless you have the proper conditions; something like a milliseconds timer with a short interval calling an intensive (cpu-wise) command. In such cases, it seems that more cpu is given to mirc for that, although the "regularity" of the repetitions is lost.