The real realtime preemption end game • Hacker News Board

Re: The real realtime preemption end game

#21

Post by refulgentis » Thu, Nov 16, 2023, 4:15 PM UTC

calvinmorrison wrote: post #18

binary132 wrote: post #13

Earlier quoted context omitted.

I get the sense that applications with true realtime requirements generally have hard enough requirements that they cannot allow even the remote possibility of failure. Think avionics, medical devices, automotive, military applications. If you really need realtime, then you really need it and "close enough" doesn't really exist. This is just my perception as an outsider though.

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

...yes, after realtime support lands

Re: The real realtime preemption end game

#22

Post by tyingq » Thu, Nov 16, 2023, 4:16 PM UTC

calvinmorrison wrote: post #18

binary132 wrote: post #13

Earlier quoted context omitted.

I get the sense that applications with true realtime requirements generally have hard enough requirements that they cannot allow even the remote possibility of failure. Think avionics, medical devices, automotive, military applications. If you really need realtime, then you really need it and "close enough" doesn't really exist. This is just my perception as an outsider though.

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

I'm guessing it's not that technical experts will be choosing this path, but rather companies. Once it's "good enough", and much easier to hire for, etc...you hire non-experts because it works most of the time. I'm not saying it's good, just that it's a somewhat likely outcome. And not for everything, just the places where they can get away with it.

Re: The real realtime preemption end game

#23

Post by worthless-trash » Thu, Nov 16, 2023, 4:17 PM UTC

TeeMassive wrote: post #3

It's kind of crazy that a feature necessitated 20 years of active development to be somewhat called complete. I hope it will be ready soon. I'm working in a project that has strict serial communication requirements and it has caused us a lot of headaches.

Can you expand on this, as I'm a little naive in this area, say you isolated the cpus (isolcpus parameter) and then taskset your task onto the isolated cpu, would not the scheduler no longer be involved, and your task be the only thing serviced by that CPU ?

Is it other interrupts on the CPU that break your process out of the "real time" requirement, I find this all so interesting.

Re: The real realtime preemption end game

#24

Post by wholesomepotato » Thu, Nov 16, 2023, 4:18 PM UTC

eisbaw wrote: post #19

Great to hear. However even if Linux the kernel is real-time, likely the hardware won't be due to caches and internal magic CPU trickery. Big complex hardware is a no-no for true real-time. That's why AbsInt and WCET tools mainly has simple CPU architectures. 8051 will truly live forever. btw, Zephyr RTOS.

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.

Re: The real realtime preemption end game

#25

Post by loeg » Thu, Nov 16, 2023, 4:20 PM UTC

cduzz wrote: post #11

loeg wrote: post #4

Synchronous logging strikes again! We ran into this some at work with GLOG (Google's logging library), which can, e.g., block on disk IO if stdout is a file or whatever. GLOG was like, 90-99% of culprits when our service stalled for over 100ms.

I have discussions with cow-orkers around logging; "We have Best-Effort and Guaranteed-Delivery APIs" "I want Guaranteed Delivery!!!" "If the GD logging interface is offline or slow, you'll take downtime; is that okay?" "NO NO Must not take downtime!" "If you need it logged, and can't log it, what do you do?" These days I just point to the CAP theorem and suggest that logging is the same as any other distributed syst…

I read GD as “god damn,” which also seems to fit.

Re: The real realtime preemption end game

#26

Post by lumb63 » Thu, Nov 16, 2023, 4:20 PM UTC

refulgentis wrote: post #21

calvinmorrison wrote: post #18

Earlier quoted context omitted.

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

...yes, after realtime support lands

A lot of realtime systems don’t have sufficient resources to run Linux. Their hardware is much less powerful than Linux requires.

Even if a system can run (RT-)Linux, it doesn’t mean it’s suitable for real-time. Hardware for real-time projects needs much lower interrupt latency than a lot of hardware provides. Preemption isn’t the only thing necessary to support real-time requirements.

Re: The real realtime preemption end game

#27

Post by Aaargh20318 » Thu, Nov 16, 2023, 4:21 PM UTC

What does this mean for the common user? Is this something you would only enable in very specific circumstances or can it also bring a more responsive system to the general public?

Re: The real realtime preemption end game

#28

Post by synergy20 » Thu, Nov 16, 2023, 4:23 PM UTC

calvinmorrison wrote: post #18

binary132 wrote: post #13

Earlier quoted context omitted.

I get the sense that applications with true realtime requirements generally have hard enough requirements that they cannot allow even the remote possibility of failure. Think avionics, medical devices, automotive, military applications. If you really need realtime, then you really need it and "close enough" doesn't really exist. This is just my perception as an outsider though.

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

no you don't, you use a true RTOS instead.

linux RTOS is at microseconds granularity but it still can not 100% guarantee it, anything in cache nature (L2 cache, TLB miss) are hard for hard real time.

a dual kernel with xenomai could improve it, but it is not widely used somehow, only used in industrial controls I think.

linux RT is great for audio, multimedia etc as well, where real-time is crucial, but not a MUST.

Re: The real realtime preemption end game

#29

Post by nraynaud » Thu, Nov 16, 2023, 4:24 PM UTC

eisbaw wrote: post #19

Great to hear. However even if Linux the kernel is real-time, likely the hardware won't be due to caches and internal magic CPU trickery. Big complex hardware is a no-no for true real-time. That's why AbsInt and WCET tools mainly has simple CPU architectures. 8051 will truly live forever. btw, Zephyr RTOS.

I think it's really useful on 'big' MCU, like the raspberry pi. There exists an entire real time spirit there, where you don't really use the CPU to do any bit banging but everything is on time as seen from the outside. You have timers that receive the quadrature encoders inputs, and they just send interrupt when they wrap, the GPIO system can be plugged to the DMA, so you can stream the memory to the output pins without involving the CPU (again, interrupts at mid-buffer and empty buffer). You can stream to a DAC, stream from a ADC to memory with the DMA. A lot of that stuff bypasses the caches to get a predictable latency.

Re: The real realtime preemption end game

#30

Post by stavros » Thu, Nov 16, 2023, 4:24 PM UTC

Aaargh20318 wrote: post #27

What does this mean for the common user? Is this something you would only enable in very specific circumstances or can it also bring a more responsive system to the general public?

As far as I can understand, this is for Linux becoming an option when you need an RTOS, so for critical things like aviation, medical devices, and other such systems. It doesn't do anything for the common user.