3 ms·

> Archlinux “Zen” (lower latency kernel). that might be the problem low latency kernels aren't of any help unless you're running realtime (or near-realtime) w

by znpy 4y ago

> Archlinux “Zen” (lower latency kernel). that might be the problem low latency kernels aren't of any help unless you're running realtime (or near-realtime) workloads. not only that, in order to guarantee high priority tasks they will hurt regular process performances. for desktop usage running a "low latency" kernel is probably a bad idea (no wonder "low latency" kernel config are not the default choice).

dijit 4y ago
I think you have it backwards. The lower latency kernels are great for desktops (and the default for desktop distros typically). They sacrifice raw power for lower latency. So my compiles take a bit longer as the kernel will switch tasks more often, but keypresses will be captured with reduced latency from my perspective. I have tested this, the stock arch kernel has considerable more latency on inputs.
- diffeomorphism 4y ago
  "Lower latency" usually means lower peak, not average. E.g. <5 99% of the time and 25 1% of the time is "high" but much better for desktops than <15 100% of the time (made up numbers). So you usually avoid low latency or real time kernels unless you need the <15 guarantee.
  - dijit 4y ago
    I think we're talking about latency in incorrect terms, I'm referring to polling frequency of my task queue to handle interrupts, which is configured as an increase in the polling rate of the scheduled workloads inside linux with the following keys: CONFIG_HZ_100 # Typical for server workloads CONFIG_HZ_250 # For servers that need to switch tasks more often (think: overprovisioned cloud providers) CONFIG_HZ_300 # For Media servers/workstations, typically CONFIG_HZ_1000 # For desktops, typicall. The documentation suggests for “workstation/desktop” operations the timer should be set to 1000MHz. Why does it recommend this? Because the higher the polling rate the quicker it will see inputs from human interface devices like mice and keyboards and respond to them. A higher tickrate here will mean more interrupts (meaning lower throughput but a lower latency to interrupts). If you're talking about process latency of non-interrupted processes then a lower value is prefered because you don't really want your program to wait around for more CPU time while linux polls all of its buffers and tries to schedule other tasks. You can easily see what is configured by asking the kernel for its configuration param: `zcat /proc/config.gz | grep -E '^CONFIG_HZ'`

by znpy 4y ago

dijit 4y ago

I think you have it backwards. The lower latency kernels are great for desktops (and the default for desktop distros typically). They sacrifice raw power for lower latency. So my compiles take a bit longer as the kernel will switch tasks more often, but keypresses will be captured with reduced latency from my perspective. I have tested this, the stock arch kernel has considerable more latency on inputs.

diffeomorphism 4y ago
"Lower latency" usually means lower peak, not average. E.g. <5 99% of the time and 25 1% of the time is "high" but much better for desktops than <15 100% of the time (made up numbers). So you usually avoid low latency or real time kernels unless you need the <15 guarantee.
- dijit 4y ago
  I think we're talking about latency in incorrect terms, I'm referring to polling frequency of my task queue to handle interrupts, which is configured as an increase in the polling rate of the scheduled workloads inside linux with the following keys: CONFIG_HZ_100 # Typical for server workloads CONFIG_HZ_250 # For servers that need to switch tasks more often (think: overprovisioned cloud providers) CONFIG_HZ_300 # For Media servers/workstations, typically CONFIG_HZ_1000 # For desktops, typicall. The documentation suggests for “workstation/desktop” operations the timer should be set to 1000MHz. Why does it recommend this? Because the higher the polling rate the quicker it will see inputs from human interface devices like mice and keyboards and respond to them. A higher tickrate here will mean more interrupts (meaning lower throughput but a lower latency to interrupts). If you're talking about process latency of non-interrupted processes then a lower value is prefered because you don't really want your program to wait around for more CPU time while linux polls all of its buffers and tries to schedule other tasks. You can easily see what is configured by asking the kernel for its configuration param: `zcat /proc/config.gz | grep -E '^CONFIG_HZ'`