Would a router/firewall benefit from a realtime kernel? I've read about reduction in latency from such kernels. The hardware in question is "powerful" CPU so not likely to be hardware limited.
They still produce the RT Kernel?
Yes, the patchset is actively developed, see: https://wiki.linuxfoundation.org/realtime/start#versions_of_preempt_rt_patches
1 Like
More "powerful" platforms have preempt enabled in default kernels 6.6
What is your application for realtime scheduled process?
1 Like
That’s what I’m asking. I’ve got a gigabit connection and I use this box for my router firewall and to run snort. I’m asking if patching the kernel with the real time patch would offer any improvements that would be meaningful.
So PR does not come into play here. IIRC RT was kicked around on X86 some years back, little interest do to negligible gain.
Probably you are looking to add
CONFIG_PREEMPT_DYNAMIC=y
And then measure different scheduling modes.
More beef in various snort capture modes, like dpdk and similar.
2 Likes
it seems that there are several backports that break the rt patch.
1 Like
For networking workloads, the -rt patchset brings no advantages (but serious pains, if you wanted to apply it on top of OpenWrt's patch stack).
Even for traditional -rt uses in (live-) audio workstations with their weak realtime (no one is going to die, if the realtime targets are not met - it's not a lathe or other dangerous machining equipment) requirements, the importance of the dedicated -rt patchset is greatly diminished, for many reasons:
- most of the big patches have already been absorbed into the normal kernel
- the big kernel lock is no more
- other types of locks have gotten reduced and much more fine grained
- the normal kernel now offers hard- and voluntary preemption
- tickless kernels are a nice side effect, slightly orthogonal, but made possible by these developments
- we're no longer restricted to HZ=100, HZ={250,300,1000} is just a config symbol away
- there pretty much are no single core CPUs anymore, multicore has even reached the embedded space and plastic routers
- so there's pretty much always a way to handle important tasks in time on one of your x-cores
- CPUs and their peripherial busses and devices have gotten much faster in general, so even without hard realtime targets, the chances of fatal delays have gotten much less likely
- networking tasks are inherently single-threaded, even if you now may have the -rt patches applied, the firewall still can't do anything before the packets have been processed by the network card - and only then wireguard can work with that. These are mostly layered tasks, preemption usually does not really help here.
- in general, your bottlenecks are found elsewhere (uplink, ISP-, peering- and server side), a <10 year-old x86_64 CPU has no problems to handle 1 GBit/s network traffic (neither with sqm, wireguard and other additional complexities involved), it still remains bored.
So unless your CPU is reeeeaaalllyy underpowered and regularly operating at its limits, there's no benefit to -rt. Keep in mind, -rt does not make anything faster, on the contrary, it makes everything (slightly) slower, to guarantee that the exceptional cases can't introduce delays (beyond the weak realtime targets). And what would you expect from -rt on a router whose CPU is generally adequate for the task? -rt can only reduce the (nano-second-) jitter, in the sense of guaranteeing it to be more uniform, but that is hardly a problem for you on a router, even for the most hardcore latency fetishists or prosumer networking enthusiasts.
Now 40-, 100 GBit/s and more networking and/ or the needs of high-frequency stock trading are another topic, but there the kernel is the least of your concerns, the speed of light, physical link distances (down to a few hundred metres) and hardware are. For these tasks, the general purpose kernel shouldn't be involved at all, as you operate hardware offloaded before the packet has even been fully received, with firewalls rules offloaded to the highly specialized networking ASICs and other esotheric solutions with insane prices and power requirements.
Ergo, if you are on (semi-recent) x86_64 and not really maxing out the CPU constantly, there is nothing to be gained from -rt on your router. Even if there were, there'd be many lower hanging fruits in tweaking the existing kernel configuration for not-resource-constrained environments like x86_64, before looking into -rt makes any sense.
If you care, the biggest no-no would be running your router in a VM (because that steals control from the router to the hypervisor, and all in-VM timing guarantees are gone).
8 Likes