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

231–240 of 281 posts

Re: The real realtime preemption end game

#231

Post by vacuity »

adastra22 wrote: post #228
mananaysiempre wrote: post #218

Earlier quoted context omitted.

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.).

Amoeba was my favorite, as it was a homogeneous, decentralized operating system. Different CPU architectures spread across different data centers, and it was all homogenized together into a single system image. You had a shell prompt where you typed commands and the OS could decide to spawn your process on your local device, in the server room rack, or in some connected datacenter in Amsterdam, it didn't make a diffe…

Wouldn't there be issues following from distributed systems and CAP? Admittedly, I know nothing about Amoeba.

E.g. You spawn a process on another computer and then the connection drops.

Re: The real realtime preemption end game

#232

Post by rmu09 »

zmgsabst wrote: post #229
LeifCarrotson wrote: post #110

Earlier quoted context omitted.

We've successfully used a Delta Tau real-time Linux motion controller to run a 24 kHz laser galvo system. It's ostensibly good for 25 microsecond loop rates, and pretty intolerant of jitter (you could delay a measurement by a full loop period if you're early). And the processor is a fixed frequency Arm industrial deal that only runs at 1.2 GHz. Perhaps even that's not an example of such a system, 0.3 microseconds is…

Thanks for the detailed reply! I’m trying to understand where the roadblock on a rPi + small FPGA hybrid board for $50 fails at the task… and it sounds like the OS/firmware doesn’t suffice. (Or a SoC, like a Zynq.) Eg, if we could guarantee that the 1.5GHz core won’t “be off” by more than 1us on responding and the FPGA can manage IO directly to buffer out (some of) the jitter, then the cost of many hobby systems with…

You can get pretty far nowadays with preempt rt and an FPGA. Maybe you even can get near 1µs max jitter. One problem with the older RPis was unpredictable (to me) behaviour of the hardware, i.e. "randomly" changing SPI clocks, and limited bandwidth.

Hobby systems like a small CNC mill or lathe usually don't need anything near 1µs (or better) max jitter. LinuxCNC (derived from NIST's Enhanced Machine Controller, name changed due to legal threats) runs fine on preempt-rt with control loops around 1kHz, with some systems you can also run a "fast" thread with say 20kHz and more to generate stepper motor signals, but that job is best left for the FPGA or an additional µC IMHO.

Re: The real realtime preemption end game

#233

Post by elcritch »

vacuity wrote: post #170
gigatexal wrote: post #162

Earlier quoted context omitted.

> 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. So much like a well structured main method in a…

Recently, I've been thinking that we need a microkernel design in applications. You have the core and then services that can integrate amongst each other and the core that provide flexibility. Like the "browser as an OS" kind of things but applied more generally.

That’s pretty much what Erlang/OTP is, and it’s like a whole OS. Though it lacks capabilities.

Re: The real realtime preemption end game

#234

Post by elcritch »

ska wrote: post #106
stavros wrote: post #30

Earlier quoted context omitted.

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.

For the parts of such systems that you would need an RTOS for this isn't really a likely replacement because the OS is way too complex. The sort of thing it could help with is servicing hardware that does run hard realtime. For example, you have an RTOS doing direct control of a robot or medical device or whatever, and you have a UI pendant or the like that a user is interacting with. If linux on that pendant can mak…

It depends on the field. I know of one robots control software company planning to switch to a RT Linux stack. Their current one is a *BSD derived rtos that runs, kid you not, alongside windows.

RT Linux might not pass on some certifications, but there’s likely many systems where it would be sufficient.

Re: The real realtime preemption end game

#235

Post by spacechild1 »

duped wrote: post #61
cptaj wrote: post #36

Earlier quoted context omitted.

Unless its just music

Unless that music is being played through a multi kW amplifier into a stadium and an xrun causes damage to the drivers and/or audience (although, they should have hearing protection anyway).

> and an xrun causes damage to the drivers and/or audience

An xrun typically manifests itself as a (very short) discontinuity or gap in the audio signal. It might sound unpleasant, but there's nothing dangerous about it.

Re: The real realtime preemption end game

#236

Post by sesm »

fbdab103 wrote: post #62
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?

My understanding is that real-time makes a system slower . To be real-time, you have to put a time allocation on everything. Each operation is allowed X budget, and will not deviate. This means if the best-case operation is fast, but the worst case is slow, the system has to always assume worst case.

It’s a classic latency-throughout trade off: smaller latency - lower throughout. Doing certain operations in bulk (like GC) increases latency, but is also more efficient and increases throughput.

Re: The real realtime preemption end game

#237

Post by signa11 »

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.…

this feels like tannenbaum-torvalds debate once again.

Re: The real realtime preemption end game

#238

Post by creshal »

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.…

> Millions of lines of kernel, all of which have to be made preemptable.

~90% of those are device drivers, which you'd still need with a microkernel if you want it to run or arbitrary hardware.

Re: The real realtime preemption end game

#239

Post by tremon »

atq2119 wrote: post #210
tremon wrote: post #84

Earlier quoted context omitted.

No -- soft realtime applications are things like video conferencing, where you care mostly about low latency in the audio/video stream but it's ok to drop the occasional frame. These are still realtime requirements, different from what your typical browser does (for example): who cares if a webpage is rendered in 100ms or 2s? Hard realtime is more like professional audio/video recording where you want hard guarantees…

> who cares if a webpage is rendered in 100ms or 2s? Do you really stand by the statement of this rhetorical question? Because if yes: this attitude is a big reason for why web apps are so unpleasant to work with compared to locally running applications. Depending on the application, even 16ms vs 32ms can make a big difference.

Yes I do, because I don't think the attitude is the reason, the choice of technology is the reason. If you want to control for UI latency, you don't use a generic kitchen-sink layout engine, you write a custom interface. You can't eat your cake and have it too, even though most web developers want to disagree.

Re: The real realtime preemption end game

#240

Post by dontlaugh »

creshal wrote: post #238
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.…

> Millions of lines of kernel, all of which have to be made preemptable. ~90% of those are device drivers, which you'd still need with a microkernel if you want it to run or arbitrary hardware.

But crucially, drivers in a microkernel run in user space and are thus pre-emptible by default. Then the driver itself only has to worry about dealing with hardware timing when pre-empted.
Post reply on HN