5 ms·

Being an RTOS is only necessary if your application has a requirement for real-time response and is also itself designd for bounded-response-time. Ignoring dri

Being an RTOS is only necessary if your application has a requirement for real-time response and is also itself designd for bounded-response-time. Ignoring drivers for the moment, your typical desktop application does not have a need for a bounded response time. Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. The underlying drivers, on the other hand, do tend to need bounded-response time, but this is typically performed by the use of the interrupt handling subsystem, whether directly handled or split into upper/lower. Even non-RTOSs should be able to provide real-time response to drivers in this way and the trade-offs taken by an RTOS scheduler are not always appropriate or optimal for a desktop, user-facing system.

loudmax 7y ago
> Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. No they won't fail but a responsive user interface is critical. A process running on an RTOS won't complete any faster (probably the opposite), but displaying some sort of acknowledgement that a key has been pressed or a button has been clicked without any human perceptible delay is really nice. I'd love for the user interface portion of an OS to run with real time constraints.
- deleted 7y ago
  [deleted]
- caspper69 7y ago
  Real-time response and a/an RTOS are not the same thing. An RTOS only allows processes with a known (or computable) runtime to run so that it may make guarantees about timing of execution. In some RTOSes scheduling may be entirely static and determined at compile time. This type of OS is used in critical systems (aircraft, hospital equipment, nuclear bombs). It's not really the type of system you'd want for a general purpose operating system.
  - snvzz 7y ago
    >An RTOS only allows That's just the easy way to achieve hard realtime. It is, fortunately, not the only way.
0xcde4c3db 7y ago
> Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. Not a few milliseconds, but a few dozen seconds might be a different story. While it might be hard to predict or measure an exact number, your deadline is however long it takes for the user to equate it to "forever" and kill the process / leave the website / uninstall the app / etc..
- joosters 7y ago
  A 'real time' OS does not mean fast. It is simply that the OS can promise an application/driver that it will get the processing time that it requests. e.g. a nuclear power station controller might use a RTOS to guarantee that the emergency shutdown process can be completed in under a certain number of seconds, regardless of whatever else is going on. In general, being able to make these kind of promises means that the OS has to be pretty conservative about the code it allows to run, and a 'best effort' OS or some 'soft' RTOS is probably going to be faster or more efficient. In terms of UI responsiveness, I'd bet that crappy software running on a 'hard' RTOS can still manage to feel sluggish, because the UI delays probably aren't actually in the OS itself.
- vondur 7y ago
  I've never tried it, but isn't there a kernel for Linux that's been more optimized for desktop, but not quite real time?
nickpsecurity 7y ago
There is some benefit to real-time ability in an OS. Mainly, to prevent one application from freezing up the system. That's happened to me both on Windows and Linux. Took work to wrestle it back into my control again. I remember people who used the QNX demo disk on old machines describing how they could do big compiles in the background with the system still responsive to input. I'm guessing the parts interacting with the user had higher priority.
- TickleSteve 7y ago
  Thats priorities at work.... not bounded-response-time.
  - nickpsecurity 7y ago
    Good point. A little out of my element here. :) Real-time might help in another way: mitigating covert channels. Gotta know the timing of secret-handling code. Then, make the observed timing fixed-length or random. Don't always need the timing to do that, though. For instance, the separation kernels just need timing for the partitions with whole thing stopping regardless of where code is at. One last benefit might be easier performance monitoring and diagnostics. If it's predictable, one might be able to assign a range or profile to it. Then, raise alarm if anything goes out of profile. Just speculating here: never built one.
dleslie 7y ago
Audio. A great many people work with audio or want to work with audio, and Windows and OSX are lightyears ahead of Linux in terms of ease of use and overall quality. You'd think the PulseAudio fiasco would have improved the situation, but I believe the developers thought as you did, and so built a system that's woefully encumbered with latency. Jack improves the situation WRT latency, but it comes at the cost of an altogether brittle and broken integration with PA, and thus with all major Linux desktops. Bounded response times may not be needed for your word processor, but there's plenty of folks out there who would be better served by it. Hell, I'd love a snappier editor on account of predictable response times to keypresses.
- AsyncAwait 7y ago
  > You'd think the PulseAudio fiasco would have improved the situation PA is in rather good shape now & it has capabilities its predecessors didn't. But it's very hard to get people to update their notions about something once it sets in. No matter how much Microsoft tries, Windows will always be 'insecure, virus-ridden', macOS will always be super stable, beautiful, no matter how much Apple screws up & Linux will always be unusable on the desktop no matter how many decades I'll spend enjoying it on the desktop at home and at work. Sadly, it seems a person's mind tends to naturally lean conservative and it takes a herculean effort to regularly update one's preconceived notions.
  - dleslie 7y ago
    PulseAudio remains practically unusable for an audio workstation; latency in the tens or twenties of miliseconds are unacceptable.
    - AsyncAwait 7y ago
      If you want realtime, there's JACK. PA is intended to replace/supplement ALSA, it has features like network transparency, per app volume control, EQ, virtual outputs etc. Not every SW has to have every feature, but PA has useful features ALSA doesn't.
snvzz 7y ago
>Being an RTOS is only necessary if your application has a requirement for real-time response Or, in other words, the operating system is not general purpose, because it is not suitable for these uses. Do note these uses do include the likes of audio. If there's no way to guarantee latency, then a spike will surely eventually cause an overrun, which will be perceived as an audio hiccup. Sometimes, this is just an annoyance. On a live performance or in pro audio work, it can be fatal. A good microkernel will allow mixed criticality tasks to share the system. A lot of recent research in the topic has brought SeL4 to this point.

loudmax 7y ago

> Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. No they won't fail but a responsive user interface is critical. A process running on an RTOS won't complete any faster (probably the opposite), but displaying some sort of acknowledgement that a key has been pressed or a button has been clicked without any human perceptible delay is really nice. I'd love for the user interface portion of an OS to run with real time constraints.

deleted 7y ago
[deleted]
caspper69 7y ago
Real-time response and a/an RTOS are not the same thing. An RTOS only allows processes with a known (or computable) runtime to run so that it may make guarantees about timing of execution. In some RTOSes scheduling may be entirely static and determined at compile time. This type of OS is used in critical systems (aircraft, hospital equipment, nuclear bombs). It's not really the type of system you'd want for a general purpose operating system.
- snvzz 7y ago
  >An RTOS only allows That's just the easy way to achieve hard realtime. It is, fortunately, not the only way.

0xcde4c3db 7y ago

> Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. Not a few milliseconds, but a few dozen seconds might be a different story. While it might be hard to predict or measure an exact number, your deadline is however long it takes for the user to equate it to "forever" and kill the process / leave the website / uninstall the app / etc..

joosters 7y ago
A 'real time' OS does not mean fast. It is simply that the OS can promise an application/driver that it will get the processing time that it requests. e.g. a nuclear power station controller might use a RTOS to guarantee that the emergency shutdown process can be completed in under a certain number of seconds, regardless of whatever else is going on. In general, being able to make these kind of promises means that the OS has to be pretty conservative about the code it allows to run, and a 'best effort' OS or some 'soft' RTOS is probably going to be faster or more efficient. In terms of UI responsiveness, I'd bet that crappy software running on a 'hard' RTOS can still manage to feel sluggish, because the UI delays probably aren't actually in the OS itself.
vondur 7y ago
I've never tried it, but isn't there a kernel for Linux that's been more optimized for desktop, but not quite real time?

nickpsecurity 7y ago

There is some benefit to real-time ability in an OS. Mainly, to prevent one application from freezing up the system. That's happened to me both on Windows and Linux. Took work to wrestle it back into my control again. I remember people who used the QNX demo disk on old machines describing how they could do big compiles in the background with the system still responsive to input. I'm guessing the parts interacting with the user had higher priority.

TickleSteve 7y ago
Thats priorities at work.... not bounded-response-time.
- nickpsecurity 7y ago
  Good point. A little out of my element here. :) Real-time might help in another way: mitigating covert channels. Gotta know the timing of secret-handling code. Then, make the observed timing fixed-length or random. Don't always need the timing to do that, though. For instance, the separation kernels just need timing for the partitions with whole thing stopping regardless of where code is at. One last benefit might be easier performance monitoring and diagnostics. If it's predictable, one might be able to assign a range or profile to it. Then, raise alarm if anything goes out of profile. Just speculating here: never built one.

dleslie 7y ago

Audio. A great many people work with audio or want to work with audio, and Windows and OSX are lightyears ahead of Linux in terms of ease of use and overall quality. You'd think the PulseAudio fiasco would have improved the situation, but I believe the developers thought as you did, and so built a system that's woefully encumbered with latency. Jack improves the situation WRT latency, but it comes at the cost of an altogether brittle and broken integration with PA, and thus with all major Linux desktops. Bounded response times may not be needed for your word processor, but there's plenty of folks out there who would be better served by it. Hell, I'd love a snappier editor on account of predictable response times to keypresses.

AsyncAwait 7y ago
> You'd think the PulseAudio fiasco would have improved the situation PA is in rather good shape now & it has capabilities its predecessors didn't. But it's very hard to get people to update their notions about something once it sets in. No matter how much Microsoft tries, Windows will always be 'insecure, virus-ridden', macOS will always be super stable, beautiful, no matter how much Apple screws up & Linux will always be unusable on the desktop no matter how many decades I'll spend enjoying it on the desktop at home and at work. Sadly, it seems a person's mind tends to naturally lean conservative and it takes a herculean effort to regularly update one's preconceived notions.
- dleslie 7y ago
  PulseAudio remains practically unusable for an audio workstation; latency in the tens or twenties of miliseconds are unacceptable.
  - AsyncAwait 7y ago
    If you want realtime, there's JACK. PA is intended to replace/supplement ALSA, it has features like network transparency, per app volume control, EQ, virtual outputs etc. Not every SW has to have every feature, but PA has useful features ALSA doesn't.

snvzz 7y ago

>Being an RTOS is only necessary if your application has a requirement for real-time response Or, in other words, the operating system is not general purpose, because it is not suitable for these uses. Do note these uses do include the likes of audio. If there's no way to guarantee latency, then a spike will surely eventually cause an overrun, which will be perceived as an audio hiccup. Sometimes, this is just an annoyance. On a live performance or in pro audio work, it can be fatal. A good microkernel will allow mixed criticality tasks to share the system. A lot of recent research in the topic has brought SeL4 to this point.