6 ms·

what is a real time kernel vs a normal kernel? just "faster"?

by fierro 5y ago

mutagen 5y ago
'real time' generally means latency guarantees and trading some throughput for consistent low latency for interrupts and scheduling. So faster in some dimensions and slower in others. The Arch Linux wiki has some description of their real time patches: https://wiki.archlinux.org/title/Realtime_kernel_patchset https://wiki.archlinux.org/title/Realtime_kernel_patchset
- jmiskovic 5y ago
  Arch wiki is an amazing source of practical information. It's like graybeard forums but distilled into a readable text. My last laptop ran Mint distro; whenever I searched around for HW issues it was always their wiki, fully stocked with useful info and steps how to fix stuff.
  - froh 5y ago
    "graybeard forums" = ?
    - jmiskovic 5y ago
      I'm referring to the usenet, mailing lists, various issue trackers and distro-specific forums were knowledgeable people diagnose and solve problems for others. The arch wiki has some of same diagnostics/troubleshooting content in more approachable format and kept up to date. Quite a few times it pointed me in right direction even if I don't use Arch.
      - froh 5y ago
        ah so grey haired as in experienced people think John Maddog Hall. got it. thanks.
  - fogihujy 5y ago
    Yeah, I'm always amazed when I end up looking at the Arch wiki for a Debian issue, simply because the Arch wiki is more relevant and up to date.
  - fierro 5y ago
    wow thanks for calling that out. Just spent an hour browsing through it and was basically an Operating Systems refresher course. Great resource!
mikepurvis 5y ago
Often it's explicitly not faster— you intentionally do work in a more interruptible/resumable/chunked way even if it's less efficient to do it that way than to just block the system and do it all in one shot. These kinds of tradeoffs don't make sense for a lot of common Linux workloads, which is why it isn't the default.
- corysama 5y ago
  Yes, and: in return you get documented guarantees about how much time certain operations are allowed to take. As opposed to “We work hard to make it fast most of the time. But, no promises because sometimes stuff happens.”
squarefoot 5y ago
Real time offers predictability. In some contexts being certain of a 3ms latency is better than going randomly from 1 to 4ms which could make the code faster on the average but with less predictable timings.
mixmastamyk 5y ago
"More responsive," is the typical simplified description.

what is a real time kernel vs a normal kernel? just "faster"?

by fierro 5y ago

what is a real time kernel vs a normal kernel? just "faster"?

'real time' generally means latency guarantees and trading some throughput for consistent low latency for interrupts and scheduling. So faster in some dimensions and slower in others. The Arch Linux wiki has some description of their real time patches: https://wiki.archlinux.org/title/Realtime_kernel_patchset https://wiki.archlinux.org/title/Realtime_kernel_patchset

jmiskovic 5y ago
Arch wiki is an amazing source of practical information. It's like graybeard forums but distilled into a readable text. My last laptop ran Mint distro; whenever I searched around for HW issues it was always their wiki, fully stocked with useful info and steps how to fix stuff.
- froh 5y ago
  "graybeard forums" = ?
  - jmiskovic 5y ago
    I'm referring to the usenet, mailing lists, various issue trackers and distro-specific forums were knowledgeable people diagnose and solve problems for others. The arch wiki has some of same diagnostics/troubleshooting content in more approachable format and kept up to date. Quite a few times it pointed me in right direction even if I don't use Arch.
    - froh 5y ago
      ah so grey haired as in experienced people think John Maddog Hall. got it. thanks.
- fogihujy 5y ago
  Yeah, I'm always amazed when I end up looking at the Arch wiki for a Debian issue, simply because the Arch wiki is more relevant and up to date.
- fierro 5y ago
  wow thanks for calling that out. Just spent an hour browsing through it and was basically an Operating Systems refresher course. Great resource!

mikepurvis 5y ago

Often it's explicitly not faster— you intentionally do work in a more interruptible/resumable/chunked way even if it's less efficient to do it that way than to just block the system and do it all in one shot. These kinds of tradeoffs don't make sense for a lot of common Linux workloads, which is why it isn't the default.

corysama 5y ago
Yes, and: in return you get documented guarantees about how much time certain operations are allowed to take. As opposed to “We work hard to make it fast most of the time. But, no promises because sometimes stuff happens.”

squarefoot 5y ago

Real time offers predictability. In some contexts being certain of a 3ms latency is better than going randomly from 1 to 4ms which could make the code faster on the average but with less predictable timings.

mixmastamyk 5y ago

"More responsive," is the typical simplified description.