Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The real realtime preemption end game

lwn.net

Post reply on HN
Print view View original

211–220 of 281 posts

Re: The real realtime preemption end game

#211

Post by dilyevsky »

gigatexal wrote: post #160
Animats wrote: post #130

QNX had this right decades ago. The microkernel has upper bounds on everything it does. There are only a few tens of thousands of lines of microkernel code. All the microkernel does is allocate memory, dispatch the CPU, and pass messages between processes. Everything else, including drivers and loggers, is in user space and can be preempted by higher priority threads. The QNX kernel doesn't do anything with strings.…

QNX is used in vehicle infotainment systems no? Where else? I'm not bothered by the kernel bloat. There's a lot of dev time being invested in Linux and while the desktop is not as much of a priority as say the server space a performant kernel on handhelds and other such devices and the dev work to get it there will benefit the desktop users like myself.

Routers, airplanes, satellites, nuclear power stations, lots of good stuff

Re: The real realtime preemption end game

#212

Post by dilyevsky »

js2 wrote: post #192
Animats wrote: post #130

QNX had this right decades ago. The microkernel has upper bounds on everything it does. There are only a few tens of thousands of lines of microkernel code. All the microkernel does is allocate memory, dispatch the CPU, and pass messages between processes. Everything else, including drivers and loggers, is in user space and can be preempted by higher priority threads. The QNX kernel doesn't do anything with strings.…

VxWorks is what's used on Mars and it's a monolithic kernel, so there's more than one way to do it. :-)

I think RT build also had to disable mmu

Re: The real realtime preemption end game

#213

Post by jancsika »

abe_m wrote: post #166
blt wrote: post #152

Earlier quoted context omitted.

How is your point 2) a response to any of the earlier points? Hard realtime systems don't care about variation, only the worst case. If your code does a single multiply-add most of the time but calls `log` every now and then, hard realtime requirement is perfectly satisfied if the bound on the worst-case runtime of `log` is small enough.

I suppose it isn't, but I bristle when I see someone tossing around statements like "close enough doesn't really exist". In my experience when statements like that start up, there are people involved that don't understand variation is a part of every real process. My point is that if you're going to get into safety critical systems, there is always going to be some amount of variation, and there is always a "close en…

The point is to care about the worst case within that variation.

Most software cares about the average case, or, in the case of the Windows 10/11 start menu animation, the average across all supported machines apparently going 20 years into the future.

Re: The real realtime preemption end game

#214

Post by jancsika »

eschneider wrote: post #185
jancsika wrote: post #164

Earlier quoted context omitted.

Your division puts audio performance applications in a grey area. On the one hand they aren't safety critical. On the other, I can imagine someone getting chewed out or even fired for a pause or a glitch in a professional performance. Probably the same with live commercial video compositing.

Audio is definitely hard realtime. The slightest delays are VERY noticeable.

I mean, it should be.

But there are plenty of performers who apparently rely on Linux boxes and gumption.

Re: The real realtime preemption end game

#215

Post by rsaxvc »

HankB99 wrote: post #203
deepsquirrelnet wrote: post #54

What a blast from the past. I compiled a kernel for Debian with RT_PREEMPT about 17-18 years ago to use with scientific equipment that needed tighter timings. I was very impressed at the latencies and jitter. I haven’t really thought about it since then, but I can imagine lots of used cases for something like an embedded application with raspberry pi where you don’t quite want to make the leap into a microcontroller…

Interesting to mention the Raspberry Pi. I saw an article just a day or two ago that claimed that the RpiOS was stated by and ran on top of RTOS. That's particularly interesting because at one time years ago, I saw suggestions that Linux could run as a task on an RTOS. Things that required hard real time deadlines could run on the RTOS and not be subject to the delays that a virtual memory system could entail. I don'…

>That's particularly interesting because at one time years ago, I saw suggestions that Linux could run as a task on an RTOS.

I've worked with systems that ran Linux as a task of uITRON as well as threadX, both on somewhat obscure ARM hardware. Linux managed the MMU but had a large carveout for the RTOS code. They had some strange interrupt management so that Linux could 'disable interrupts' but while Linux IRQs were disabled, an RTOS IRQ could still fire and context switch back to an RTOS task. I haven't seen anything like this on RPi though, but it's totally doable.

Re: The real realtime preemption end game

#216

Post by PaulDavisThe1st »

tyingq wrote: post #5

I wonder if this being fixed will result in it displacing some notable amount of made-for-realtime hardware/software combos. Especially since there's now lots of cheap, relatively low power, and high clock rate ARM and x86 chips to choose from. With the clock rates so high, perfect real-time becomes less important as you would often have many cycles to spare for misses. I understand it's less elegant, efficient, etc.…

CPU speed and clock rate has absolutely nothing to do with realtime anything.

Re: The real realtime preemption end game

#217

Post by tinix »

robocat wrote: post #171
beiller wrote: post #67

Earlier quoted context omitted.

Your talk of xrun is giving me anxiety. When I was younger I dreamed of having a linux audio effects stack with cheap hardware on stage and xruns brought my dreams crashing down.

xrun definition: https://unix.stackexchange.com/questions/199498/what-are-xru... (I didn't know the term, trying to be helpful if others don't)

just a buffer under/overrun

Re: The real realtime preemption end game

#218

Post by mananaysiempre »

vacuity wrote: post #204
adastra22 wrote: post #202

Earlier quoted context omitted.

There's quite a history of capabilities-based research OS's that culminated in, but did not start with L4 (of which seL4 is a later variant).

Yes, but I believe seL4 took it to the max. I may be wrong on that count, but I think seL4 is unique in that it leverages capabilities for pretty much everything except the scheduler. (There was work in that area, but it's incomplete.)

IIRC the KeyKOS/EROS/CapROS tradition used capabilities for everything including the scheduler. Of course, pervasive persistence makes those systems somewhat esoteric (barring fresh builds, they never shut down or boot up, only go to sleep and wake up in new bodies; compare Smalltalk, etc.).

Re: The real realtime preemption end game

#219

Post by rsaxvc »

dataflow wrote: post #199

I feel like focusing on the kernel side misses CPU level issues. Is there any known upper bound on, say, how long a memory access instruction takes on x86?

I don't know for x86.

But for things that really matter, I've tested by configuring the MMU to disable caching for the memory that the realtime code lives in and uses to emulate 0% hitrate. And there's usually still a fair amount of variance on top of that depending on if the memory controller has a small cache, and where the memory controller is in its refresh cycle.

Re: The real realtime preemption end game

#220

Post by vacuity »

mananaysiempre wrote: post #218
vacuity wrote: post #204

Earlier quoted context omitted.

Yes, but I believe seL4 took it to the max. I may be wrong on that count, but I think seL4 is unique in that it leverages capabilities for pretty much everything except the scheduler. (There was work in that area, but it's incomplete.)

IIRC the KeyKOS/EROS/CapROS tradition used capabilities for everything including the scheduler. Of course, pervasive persistence makes those systems somewhat esoteric (barring fresh builds, they never shut down or boot up, only go to sleep and wake up in new bodies; compare Smalltalk, etc.).

Guess I'm too ignorant. I need to read up on these. I did know about the persistence feature. I think it's not terrible but also not great, and systems should be designed for being shut down and apps being closed.
Post reply on HN