3 ms·

Features of modern CPUs don't really prevent them from real time usage, afaik. As long as something is bounded and can be reasoned about it can be used to build

Features of modern CPUs don't really prevent them from real time usage, afaik. As long as something is bounded and can be reasoned about it can be used to build a real time system. You can always assume no cache hits and alikes, maximum load etc and as long as you can put a bound on the time it will take, you're good to go.

synergy20 3y ago
mlock your memory, test with cache miss and cache invalidation scenarios will help, using no heap for memory allocation, but it's a bit hard
- jeffreygoesto 3y ago
  Right. But still possible. https://www.etas.com/en/applications/etas-middleware-solution.php https://www.etas.com/en/applications/etas-middleware-solutio...
- eschneider 3y ago
  Does anyone use paged memory in hard realtime systems?
SAI_Peregrinus 3y ago
Exactly. "Real-time" is a misnomer, it should be called "bounded-time". As long as the bound is deterministic, known in advance, and guaranteed, it's "real-time". For it to be useful it also must be under some application-specific duration. The bounds are usually in CPU cycles, so a faster CPU can sometimes be used even if it takes more cycles. CPUs capable of running Linux usually have higher latency (in cycles) than microcontrollers, but as long as that can be kept under the (wall clock) duration limits with bounded-time it's fine. There will still be cases where the worst-case latency to fetch from DRAM in an RT-Linux system will be higher than a slower MCU fetching from internal SRAM, so RT-Linux won't take over all these systems.
bloak 3y ago
So the things that might prevent you are: 1. Suppliers have not given you sufficient information for you to be able to prove an upper bound on the time taken. (That must happen a lot.) 2. The system is so complicated that you are not totally confident of the correctness of your proof of the upper bound. 3. The only upper bound that can prove with reasonable confidence is so amazingly bad that you'd be better off with cheaper, simpler hardware. 4. There really isn't a worst case. There might, for example, be a situation equivalent to "roll the dice until you don't get snake eyes". In networking, for example, sometimes after a collision both parties try again after a random delay so the situation is resolved eventually with probability one but there's no actual upper bound. A complex CPU and memory system might have something like that? Perhaps you'd be happy with "the probability of this operation taking more than 2000 clock cycles is less than 10^-13" but perhaps not.
- formerly_proven 3y ago
  You're probably thinking about bus arbiters in 4.), which are generally fast but have no bounded settling time.
dooglius 3y ago
System management mode is one example of a feature on modern CPUs that prevents real-time usage https://wiki.linuxfoundation.org/realtime/documentation/howto/debugging/smi-latency/smi https://wiki.linuxfoundation.org/realtime/documentation/howt...

synergy20 3y ago

mlock your memory, test with cache miss and cache invalidation scenarios will help, using no heap for memory allocation, but it's a bit hard

jeffreygoesto 3y ago
Right. But still possible. https://www.etas.com/en/applications/etas-middleware-solution.php https://www.etas.com/en/applications/etas-middleware-solutio...
eschneider 3y ago
Does anyone use paged memory in hard realtime systems?

SAI_Peregrinus 3y ago

Exactly. "Real-time" is a misnomer, it should be called "bounded-time". As long as the bound is deterministic, known in advance, and guaranteed, it's "real-time". For it to be useful it also must be under some application-specific duration. The bounds are usually in CPU cycles, so a faster CPU can sometimes be used even if it takes more cycles. CPUs capable of running Linux usually have higher latency (in cycles) than microcontrollers, but as long as that can be kept under the (wall clock) duration limits with bounded-time it's fine. There will still be cases where the worst-case latency to fetch from DRAM in an RT-Linux system will be higher than a slower MCU fetching from internal SRAM, so RT-Linux won't take over all these systems.

bloak 3y ago

So the things that might prevent you are: 1. Suppliers have not given you sufficient information for you to be able to prove an upper bound on the time taken. (That must happen a lot.) 2. The system is so complicated that you are not totally confident of the correctness of your proof of the upper bound. 3. The only upper bound that can prove with reasonable confidence is so amazingly bad that you'd be better off with cheaper, simpler hardware. 4. There really isn't a worst case. There might, for example, be a situation equivalent to "roll the dice until you don't get snake eyes". In networking, for example, sometimes after a collision both parties try again after a random delay so the situation is resolved eventually with probability one but there's no actual upper bound. A complex CPU and memory system might have something like that? Perhaps you'd be happy with "the probability of this operation taking more than 2000 clock cycles is less than 10^-13" but perhaps not.

formerly_proven 3y ago
You're probably thinking about bus arbiters in 4.), which are generally fast but have no bounded settling time.

dooglius 3y ago

System management mode is one example of a feature on modern CPUs that prevents real-time usage https://wiki.linuxfoundation.org/realtime/documentation/howto/debugging/smi-latency/smi https://wiki.linuxfoundation.org/realtime/documentation/howt...