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

List of Open Source Real-Time Operating Systems

osrtos.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: List of Open Source Real-Time Operating Systems

#11

Post by alxlaz »

rambojazz wrote: post #4

Can Linux itself be compiled/built as a realtime OS? I mean without adding additional software or hacking.

There is a patchset that enables deterministic behaviour on Linux (https://www.linux.com/news/event/elce/2017/2/inside-real-tim... has a few pointers). Much of it has been mainlined, and it does have trustworthy enough commercial backing that it's worth considering at least.

That being said, the more typical approach for this, as employed by e.g. RTLinux ( http://www.rtlinux.org/ -- I'm not endorsing it, it's just the one I'm more familiar with), is to run a hard RTOS along with Linux, running real-time tasks on the RTOS and everything else on Linux. It's a more complex solution, and it's a little unsettling that we've even had to come up with it, but it works surprisingly well. Writing fancy UIs and multimedia applications on top of things like QNX is difficult (not necessarily in terms of learning/development effort, but also in terms of licensing, cost, hardware support etc.), while writing real-time control applications on a patched Linux kernel requires some trips down the kernel rabbit holes, and is hard to get through some certification processes. Companies optimize for whatever they need :).

Re: List of Open Source Real-Time Operating Systems

#12

Post by snvzz »

rambojazz wrote: post #4

Can Linux itself be compiled/built as a realtime OS? I mean without adding additional software or hacking.

The short answer is NO.

The long answer is that there's patchsets like linux-rt which give it better "soft realtime" behaviour, but no hard realtime (deadline guarantees), thus not actual realtime.

Linux-rt allows "coexistence" with "hard realtime", but it's basically a cop-out: Just reserve a processor to run something else than Linux for hard realtime tasks.

In reality, while linux-rt patchset (not mainline) suffices for most pro audio work, Linux has over a million LoC of trusted code base running in supervisor mode; It should not go anywhere near where anything requiring any kind of assurance is running. This happens to be the case with tasks requiring hard (i.e. actual) realtime, as hard realtime is all about guarantees.

My advice for hard realtime would be to look at seL4 and eChronos, both open source as per OSI definition, and pick the one best suited to your design.

Re: List of Open Source Real-Time Operating Systems

#15

Post by makarhum »

peter_retief wrote: post #3
travisgriggs wrote: post #2

Love this page. After wanting to try something other than FreeRTOS, and having been frustrated with very public projects RIOT and Zephyr, I found TNEO from this page and have used it successfully in multiple gadgets. Still very happy with it.

Interesting, I am looking at Zephyr for BLE devices, so you say TNEO is a good option?

Comparing Zephyr and TNEO is like comparing apples and oranges. Zephyr is full fledged operating system with networking etc while TNEO is more like basic building blocks of os for those who want to implement everything themselves.

I can warmly recommend Zephyr for BLE usage. It is up to date with recent bt specs and implementation is really solid.

Re: List of Open Source Real-Time Operating Systems

#16

Post by snvzz »

gmueckl wrote: post #5
rambojazz wrote: post #4

Can Linux itself be compiled/built as a realtime OS? I mean without adding additional software or hacking.

There are patchsets out there that add realtime capabilities to the kernel. But as far as I know none of them is in the mainline. I am also not confident that the kernel can be made truly hard realtime capable without major rewrites. The best bet is probably RTLinux which runs the entire Linux kernel as one of the processes managed by a hard realtime kernel.

Linux isolated through virtualization under a microkernel is the way to go if running Linux in the same hardware is actually needed at all. The realtime tasks would simply run outside of Linux, shielded from Linux.

Genode's virtualization (particularly when paired with the excellent seL4 microkernel) is a good way to achieve that.

If Linux can interfere with the "hard realtime" task, then there can be no assurance (of meeting hard deadlines) and it's thus not a solution providing hard realtime.

Re: List of Open Source Real-Time Operating Systems

#17

Post by peter_retief »

makarhum wrote: post #15
peter_retief wrote: post #3

Earlier quoted context omitted.

Interesting, I am looking at Zephyr for BLE devices, so you say TNEO is a good option?

Comparing Zephyr and TNEO is like comparing apples and oranges. Zephyr is full fledged operating system with networking etc while TNEO is more like basic building blocks of os for those who want to implement everything themselves. I can warmly recommend Zephyr for BLE usage. It is up to date with recent bt specs and implementation is really solid.

Thanks, I had no idea how many options there are

Re: List of Open Source Real-Time Operating Systems

#18

Post by tyingq »

snvzz wrote: post #12
rambojazz wrote: post #4

Can Linux itself be compiled/built as a realtime OS? I mean without adding additional software or hacking.

The short answer is NO. The long answer is that there's patchsets like linux-rt which give it better "soft realtime" behaviour, but no hard realtime (deadline guarantees), thus not actual realtime. Linux-rt allows "coexistence" with "hard realtime", but it's basically a cop-out: Just reserve a processor to run something else than Linux for hard realtime tasks. In reality, while linux-rt patchset (not mainline) suffic…

For some use cases, a Beaglebone black can allow for "real" real time while running Linux. It has two microcontrollers (PRU) that share memory with the main ARM cores. So if the real time part can be satisfied by the PRU, it's a neat solution.

Re: List of Open Source Real-Time Operating Systems

#19

Post by snvzz »

tyingq wrote: post #18
snvzz wrote: post #12

Earlier quoted context omitted.

The short answer is NO. The long answer is that there's patchsets like linux-rt which give it better "soft realtime" behaviour, but no hard realtime (deadline guarantees), thus not actual realtime. Linux-rt allows "coexistence" with "hard realtime", but it's basically a cop-out: Just reserve a processor to run something else than Linux for hard realtime tasks. In reality, while linux-rt patchset (not mainline) suffic…

For some use cases, a Beaglebone black can allow for "real" real time while running Linux. It has two microcontrollers (PRU) that share memory with the main ARM cores. So if the real time part can be satisfied by the PRU, it's a neat solution.

Same idea as linux-rt "hard realtime": Reserve a processor (doesn't matter if it's the same chip or architecture or not).

The issue with this is precisely the shared memory. If Linux can interfere with the PRU, then there's no assurance. This breaks hard realtime: No assurance that the system will react timely in a certain way to a certain event.

Re: List of Open Source Real-Time Operating Systems

#20

Post by zozbot123 »

javert wrote: post #8
rambojazz wrote: post #4

Can Linux itself be compiled/built as a realtime OS? I mean without adding additional software or hacking.

Absolutely. https://rt.wiki.kernel.org/index.php/Main_Page This is the wiki for the PREEMPT_RT patchset. Parts of this have been moving into mainline for years, bringing the regular kernel closer and closer to real-time. However, there are some real-time features that will never be appropriate for mainline, so you can get them through this patchset. Some of the "famous" kernel devs are also very active in PREEMPT-RT;…

AIUI the plan is to merge the patchset itself into mainline to ease the maintenance burden, but to keep the changes that don't actually make sense for mainstream server use under a special config/#define flag, PREEMPT_RT_FULL or similar. It will then be up to users/distributors whether to enable it. I've only tried the current patchset casually, but IME, the throughput penalty is there but is barely perceptible for casual use, and the improved responsiveness due to kernel thread preemption and the priority inversion fix do make the system a lot more usable especially under load.
Post reply on HN