Had you asked me this question about an assembler routine, then we may be able to compute the delay with some accuracy. In the case of 'c', we don't know what the compiler is doing unless we look at the assembler the compiler generated. In short, we cannot easily answer the question. If you change any of the code in the ISR, the compiler may do something different - stack more registers etc thus adding to the delay. Technically when you refer to 'interrupt latency' it means the time the cpu takes to respond to the interrupt source and vector to the ISR - this is normally between 1-4 cycles depending on what instruction is currently executing. In your case it is the latency along with the number of cycles needed to reload the timer. I would suggest you use timer2 as a auto-reload timer so that the hardware takes care of the timer reloading and thus taking any software delays out of the equation, so we are not concerned with what the compiler does.