Performance Measures
The old rule of thumb that real-time performance increases with each new CPU generation has become invalid, because CPU clock speed no longer doubles every few years. Although multicore CPUs have higher overall throughput, each core has performance that's roughly comparable with current single-CPU chips. The number of instructions and I/O cycles required to handle an interrupt won't decrease and the clock frequency won't increase, so the best-possible latency will remain around 10 s for the foreseeable future.
Interrupt latency and jitter get plenty of attention, mostly because they're easy to measure and summarize on nice graphs. However, the path length from a hardware interrupt to the first instruction in your handler represents just one part of real-time performance; other components probably have a greater effect on overall performance.
If your code performs only a trivial function, such as reading or writing a port using data stored in a FIFO buffer, then OS code determines the total path length from the interrupt to the final operation. Suppose, for example, that the total time required to handle a single interrupt has 10-s latency plus 40 s of hocus-pocus after your code, for a total of 50 s. The maximum repetitive interrupt rate could hit 20 KHz as long as the system does nothing other than handle interrupts.
That might be acceptable for a trivial real-time application such as an arbitrary waveform generator that can precompute a table of output values. Most applications have a husky nonreal-time component handling the user interface and converting input samples into output values, so the real-time component must not completely hog the CPU.
That tradeoff highlights the essential difference between a hard real-time OS and all others: A complete lack of fairness. Desktop and server OS design assumes that all tasks should receive their more-or-less fair fraction of the CPU's total processing power. Priorities and scheduling tweaks may favor one task or task category over another, but everybody has an opportunity to play.
An RTOS, in contrast, ensures that real-time tasks start when they must and run to completion as they should. Unless and until a real-time task yields control, it's in charge. There are various nuances and tweaks that may reduce such absolute control, but that's the starting point.
So, although it's tempting to use the only hard numbers you'll find, things like interrupt latency and task-switch speed might actually be the least of your worries. You must, instead, know numbers that trendy software development methodologies can't predict: The path length through your real-time code and the actual CPU usage of your nonreal-time code.
Good luck with all that.
