QNX: When an OS Really, Really Has to Work 514
An anonymous reader writes "Fortune has this article about how QNX's OS has found a niche and is doing well. Especially after 1996 when Microsoft executives said they would crush them in 2 years. When your software absolutely positively needs to work!"
A couple things (Score:-1, Interesting)
1) It isn't the operating system controlling the grinding of lenses or correcting the tilt of the TGV. It is a function of the hardware to do these things. That they report back to some software (which could frankly be run on any embedded OS) which then tells them what to do next is almost irrelevant.
2) An OS is the least important part of an embedded system. It is perhaps the most replaceable part. This is why WinCE is such a poor choice when it comes to UIs. Why do you need the OS to define the UI shell for you when what really matters is the final software that will be visible.
An embedded system simply described looks like this:
Software->OS->Hardware
The OS part of the picture is completely interchangeable and hardware too, to some respect.
Proclaiming the joys of QNX is as silly as proclaiming the joys of Linux or VxWorks. What really matters at that level is not the OS but the support that the system integrator can provide to the OEM. In that situation it is WinCE that comes out ahead of the pack.
spawn() hangs system (Score:2, Interesting)
We have ported QNX to two custom boards, one based on the MPC7410 PPC and another based on the MPC755. The MPC7410 system is running fine. The new port to the MPC755 has a nasty problem. Anytime spawn() is invoked, the entire QNX system hangs. All processes stop, regardless of priority. This system hang doesn't happen on the MPC7410.
It looks like it's just spawn() that is the problem. We can start and kill large processes from the ksh shell just fine.
This problem does not happen on our MPC7410 system. Other than this spawn problem, both systems run great.
Both systems have MPC107 controllers, 128 MB of SDRAM, and the same Ethernet controller. The MPC7410 system has 2 MB of external L2 cache, the MPC755 system has 1 MB of external L2. We believe that memory and cache integrity are OK.
What could spawn() be doing to take down the whole kernel on the MPC755?
Here is a simple example program that runs fine on the MPC7410, but completely hangs QNX on the MPC755:
#include <stdio.h>
#include <spawn.h>
int main(int argc, char** argv)
{
char* path ="/bin/ls";
printf("About to spawn %s\n", path);
fflush(stdout);
spawn(path, 0, NULL, NULL, NULL, NULL);
printf("Spawn is done\n");
return 0;
}
Here are the PPC registers on the MPC755 board seen by typical applications:
MSR = 0000.9932
HID0 = 0010.C0A4
HID1 = 8000.0000
L2CR = BB00.0060
We've submitted a request to QNX support for help on this. However, if anyone has any thoughts regarding this problem then please share.
Thanks
Inaccurate microkernel claims? (Score:1, Interesting)
From the article:
Isn't the Windows NT kernel supposed to be a microkernel? Admittedly, it is a bit larger than people intended when they came up with the idea of a microkernel (especially since MS added GUI code to it in NT 4.0), but still...
And what about OS X? That has Mach at its heart doesn't it? That's a microkernel too.
Both of the above are commercially successful.
Pronouciation? (Score:4, Interesting)
I remember using qnx in a Canadian Highschool (Score:5, Interesting)
Anyway I took 2 programming courses in basic and pascal. The labs used some strange Unisys dumb terminals connected to a builky black looking box. Very XT-ish and looked like it was from the early to mid 80's. Anyway it ran a no name OS called QNX. I believe it was powered by a 286 or 6800 with about 4 megs of ram for all 20 students. It had no display but a teletype printer where we would print out our programs. It handled quite well for such a limited server.
Its Very old and I remember a 1984 copyright that showed up whenever I booted. I had no idea it was a unixlike system.
It seemed just as fast as a standalone 286 and it had a "$" as the prompt sign with a strange scripting system. I considered it underpowered and old but was supprised by the included gcc, sed, gmake, and other utilities and powerfull scripting. It had some nice api's for 2d graphics displays.
Anyway 2 years later I wanted to try Unix after playing with NT 4 when after it just came out. I tried Caldera (shudder )Linux and I was supprised that I have been running gnu and unix all long. The shell scripts and everything were identical and I have been using Unix without even knowing it.
Linux felt quite old without X in the old days( before kde was stable and gnome was around). But I have qnx running on that horribly ancient system to thank.
Re:Inaccurate microkernel claims? (Score:1, Interesting)
A fire-and-forget controller... (Score:5, Interesting)
People in white lab coats are the primary cause of cancer in rats.
Qnx: Microkernel, real-time, small, and fast (Score:5, Interesting)
Later, the BBS was upgraded to an 8 MHz AT clone and 2400 baud modems. Still, smooth as silk, even at capacity.
The BBS never crashed once and always ran smooth.
I can't say much about today's Qnx, because I haven't used it. But yesterday's Qnx displayed a level of quality I've never seen in another OS. If I ever find myself needing medical attention, I usre as hell hope the OS running under the hood is Qnx. There is nothing more reliable.
-Teckla
Re:QNX? ICK! (Score:3, Interesting)
Re:A couple things (Score:5, Interesting)
Only partly true.
The operating system provides the framework within which the software works. For things like a desktop where things like the occasional 1/2 second ~ 3second delay isn't fatal, and blue-screening a couple of times a week (or day, as the case may be) is mostly just an annoyance, then yes -- the two are pretty much equal.
For things like nuclear reactor control, precision robotics and medical instruments, where a 1 miliseond (much less 1 second) hickup can result in death and destruction. they are most definitely not equal. The hard realtime in Windows is, well, not that hard. It's pretty easy to get Windows to lock up for the better part of a second. Linus is only slightly better -- but only when you install the realtime patches.
As far as reliability, Microsoft is still proud of being able to (sometimes) run for 3 months at a shot without rebooting. Linux has a much better history, but it's still far from bulletproof. As far as I know, neither one is certified to run things like nuclear reactors and medical equipment.
The Navy's decicision to use Windows to run their battleships has been the source of some amusement -- having managed to bluescreen one ship and leaving it 'dead in the water'. As to whether this could happen during a battle, converting 'dead in the water' to 'dead and in the water' is a matter of conjecture. All I can say with certainty is that I'm glad I'm not a US sailor.
QNX reliability (Score:5, Interesting)
One November a customer called and complained that they were not getting their log files. These log files were written to a ftp shared directory. One of my coworkers logged into the robot via modem and started looking around. When he tried to get a directory listing he got an Input/Output error instead. After a little digging around in the logs in ram he determined the hard drive had died. The most interesting thjing is that the hard drive had apparently died in August. The robot had run continually from August to November and the only trace of any problems was the lack of log files. There was no other permament storage in the system. The OS, UI and all the robot applications were running in RAM for 3 months without problems.
I Love QNX
Re:QNX? ICK! (Score:3, Interesting)
That doesn't even make sense. I rely on BSD systems that have user contributions regularly, including fixes.
Also, can you name a single embedded device that uses BSD? Embedded linux is hot. Embedded BSD is unheard of.
You don't happen to work in an embedded sector, do you? You hear about embedded Linux because you're listening for info on Linux. I work for a company that produces embedded systems (we sell approximately 2,500/day) and we've just recently considered moving away from PSOS. Linux was absolutely not an option for a variety of reasons. The decision came down to NetBSD, OpenBSD or FreeBSD.
The only strange thing was that FreeBSD was chosen because they were further along in granular locks that are required for a preemptive kernel.
There are many reasons for people to go with BSD systems...licensing is a big one, but take off your blinders and you'll find lots of technical reasons as well.
and attracting developers isn't important? (Score:3, Interesting)
Experiences (Score:1, Interesting)
QNX is a realtime OS, and as such I think it's not quite where a desktop OS needs to be. While it handles multitasking fairly well, when any of those tasks required 100% of either of my CPUs the Photon GUI would screech to a halt. It harkened back to the days of coorperative multitasking in Windows 3.1. So when running programs occaisionally the computer would seem to freeze with no indication of ever relinquishing control. I would always get it back, sometimes after a couple of minutes, but the experience is unnerving.
Re:Inaccurate microkernel claims? (Score:4, Interesting)
Sorta like Linux isn't really monolithic, since you can load kernel modules.
The NT kernel is extremely stable. Typically, drivers are what bring a 2K/XP/server system down. In fact, that is all I've ever seen bring a system down. QNX is unique in that it can restart any system component that has failed, and it isolates everything a lot more. Make no mistake - that is slower than having drivers run in kernel space, but it has its benefits. The microkernel can axe drivers and restart them in realtime, something that cannot be done for NT's kernel mode drivers (although programs and other drivers can be dynamically loaded and unloaded.)
And yes, the display driver was also moved into kernel land for NT4 and higher. Trust me - you would NOT be happy with 3d game performance or GUI performance if it were not (although some may argue for the server version that would be a better idea, but honestly my servers run headless so I don't care.)
Re:Some interesting points to note (Score:3, Interesting)
I usually call them FACTS, not "generalizations".
I've had it happen many times. A few of the reasons Windows is so unstable is that so many programs run with root privlidges, and that the system itself is so bloated and crappy. However, even as bloated and crappy as it is, if it was a microkernel, it would run wonderfully because that COULDN'T CAUSE A PROBLEM assuming the very small base was written properly.
Could someone please tell me why no other OSes are microkernels? You would get 100% stability, and as an added bonus, there are never any times when one part of the system can even slow down another part even slightly... Really incredible things they are... Why don't we see any good microkernel systems, preferably designed and written by pros? OpenBSD likes security, why don't they take up the job? That's really the only way to ever get 100% security (even if you want to run buggy and/or untrusted apps).
No, but programs running as root, or SUID are. Also, all the drivers in the kernel are as well. I've had Unix system freeze up because of writing CDs, loading videocard drivers, and other privlidged things which wouldn't happen with a microkernel.
It's on hell of a niche...
Besides, that's their niche because that's where the money is, and what they've designed it for. If they would invest some resources into the things most people want in a desktop, I have no doubt they could do a good job of taking over that as well.
It's a plain Unix system as far as the user/developer is concerned. What more interoperability could you want?
Re:you are using it? (Score:4, Interesting)
Or you have tried it as a "normal" desktop type OS? Have any thoughts on it if
so?
Yea, I tried it for a while, couple of weeks or so, just playing around with it. I
thought it was pretty cool, it had a ports like software installation program,
you clicked on what you wanted to install, and it took care of dependancies and
the like, very nice browser, supported everything my test box had (Dell GX110)
with an i810 video card. No problems, Solaris x86 gave me much more. I
thought it was pretty cool. Felt *nixy, gui-wise, all in all, not bad at all.
I have it running on a Audrey, as I said earlier, and I like it.
SealBeater
Qnx+Bt+uk (Score:1, Interesting)
There was only one glitch, they left anonymous Ftp open
Compare Context Switching times (Score:3, Interesting)
The announcement [osnews.com] was that AmigaOS4 PPC on a 600Mhz AmigaOne had around 4 microseconds, give or take a few micro. Im not sure how correct my figures were, but AmigaOS turned out a little better...
I wonder if theres room for more playsers in this niche.
Good article.
Re:QNX reliability (Score:3, Interesting)
First, you clearly can't write another error to the log stating you cant write to the log. It sounds silly, but sometimes people write this and plan to consider the question later. When later never rolls around, problems can occur.
Second, you could shut the system down alltogether. After all, the system is failing and if left unchecked could cause loss of life and/or property. But it seems a bit paranoid to shutdown over a diagnostics error; downtime is money lost. But on the plus side, you know the problem will receive attention.
A third alternative is to add some form of low level error system. The downside is even the warning 'lights' can go unnoticed, or simply ignored. This happens especially with things like "error code: 4343." The THERAC 25, in part suffered from such an enigmatic design.
Another is to just wait for an error more catastrophic to come up, and decide what to do then. Indeed, the parent post implies that this is an acceptable procedure: rather preemptively strike the hardware down, and incur delays on production, one can just wait for a real problem to arise. But this surmounts to just ignoring the problem.
Sadly, I don't think any reliable consensus on what to do will be geared towards safety for a long time. Professional Engineers are liable for any disasters that may occur as a result of their failure in design or inspection. Until software designers (or perhaps "software engineers") are assigned the same level of liability, I doubt that anyone will consider these topics seriously.
A lil history... (Score:3, Interesting)
QNX vs. Linux (Score:2, Interesting)
Now, we have the article describing QNX as the quintessential "When Software Really, Really Has to Work" OS.
How about Linux ?
Can we say, without lying, that Linux can measure up to QNX on that front ?
If not, when can we expect Linux to gain that status ?
Re:QNX reliability (Score:2, Interesting)
QNX Trivia: when QNX Software was still called Quantum Software Systems Ltd., they called their operating system QUNIX (which should answer any questions about how to pronounce the name). However, after a visit from AT&T's lawyers, they decided to drop the vowels.
Back in 1985 I wrote a Point-Of-Sale application for video stores. It used QNX version 2 in real mode (8088s and 8086s) or in protected mode (80286, later 386 and beyond). And even on the lowly 8088 machines, it was possible to run the application for two users (main console and one dumb terminal in 640K). With a 286 machine, and a multiport serial card, 11 users could be supported with just 4 megs of RAM (but the hard drive could be a bottleneck) At one point (1990) over 600 video stores used that software. That app was written and compiled under the "K&R C compiler - not ANSI C" that QNX provided back then. The OS came on two 1.2M floppies, the compiler came on a third floppy.
There are still 30 odd video stores running that software and they will be using it as long as their hardware holds out. (It is getting harder to find P166 or 486 class machines...QNX 2 will not run on anything faster and the upgrade path is expensive)
They use it because the only problems they experience are hardware problems and operator error. The OS can't protect you from a failed power supply or a direct hit from lightning. It also can not protect you from the superuser (root) person who types in something like:
"zap
Several places just do not turn their machines off - ever. So far as I know the best record for uptime was nearly ten years. Some would have been better, but there was an occasion requiring some mandatory "downtime" a few years ago when everyone had to upgrade their apps - but not their OS.
Re:Why not expect QNX-like reliability everywhere? (Score:4, Interesting)
That's not surprising. QNX costs money, and Linux is free.
What's disappointing is that the Hurd kernel was such a dud. They've been trying to write a microkernel for a decade. Unfortunately, they started with the Mach interprocess communication model, and never escaped. Microkernel architecture depends crucially on getting the basic design decisions right. You can just hack together a UNIX-type OS, and fix stuff until it works, but microkernels have to be done right.
The other downside of a message-passing microkernel is that you do more data copying. But modern CPUs do data copying quite well, and it's not the issue it used to be. In a world where SOAP converts subroutine calls to XML, the overheads of a message-passing OS are trivial.
If message-passing OSs were more popular, hardware support could make the overhead of message passing even lower. Copying, after all, is infinitely parallelizable.
Re:you can download a free copy of Neutrino (Score:4, Interesting)
integration of memory, proccess, and file systems. You can address memory as a file. you can refer to processes as file. want a snap shot of your process? just copy it to disk some where.
linking programs together at run time. Have a constant you want to change, grab it into a simple gui slider with ease. Want to grab images from a frame grabber, just register to recive them. What? they are comming from a frame grabber on another machine? no difference. and this is being routed to a gui running on a third? also not a problem.
Want to start a bunch of processes on your cluster, link them all via scripts, then move proccesses around to load ballance, relinking as you go? Also not a problem, you can do it with a single script on one machine.
Having that level of fast comunication primitives is great.
Re:QNX Floppy Challenge (Score:3, Interesting)
I wonder if some of that could be jettisoned for some kind of microwindows based GUI and perhaps a browser of some kind. Having tried Knoppix and LNX BBC also, I think these things are inherently cool and more importantly useful.
It gives a warm fuzzy feeling to know that you can carry around a disk or CD which boots into a full blown emergency repair kit or demos what can be done with Linux. The best that has so far been mustered for Windows is the excrable recovery console - something while better than nothing is still incapable of solving all but the most basic problems.
Not as freezesafe as I thought (Score:2, Interesting)
But after doing a floodping at the QNX machine it stopped doing anything. I don't know if it crashed but even the window is able to handle these floodpings.
However maybe it got fixed - I'll test it again in the next days.
b4n
Re:Bullet Proof (Score:3, Interesting)
Re:Compare Context Switching times (Score:3, Interesting)
My question would be, are those hard numbers?
IE, is it 'QNX will switch in 40 microsecs, period. AmigaOS will switch in 4..usually...but sometimes, it takes a lot longer...depends on what you're doing, really...'
Re:QNX? ICK! (Score:3, Interesting)
Saturday, June 14, 2003
OUTAGE
Network card driver randomly decided to shut itself down at around 8 this morning. Actually it's done this a few times before already (most of which I was around to catch after a few minutes; we weren't quite so lucky this time). I originally thought this was dhcpd rising from the grave but now I'm not so sure anymore. Time to see if a reboot helps.
It's not so much that Linux is unstable, it's just that the stability seems to be a function of whatever mood Linus and random driver writers are in at the time of whichever version is released. Right now the OS randomly kills processess when you start running out of memory. Randomly.
There's a reason people use QNX, and the fact that their lunch money won't buy a copy of it isn't usually a factor.
Re:QNX rules (Score:2, Interesting)
Then, by that definition, Linux 2.4.x is a microkernel. The filesystems, and the networking layer (and each of the different protocols) are all seperate modules ... which are only very loosly tied to the core.
Sure, most of those don't have a specific process associated with them ... but that's mainly an efficency thing. Even then on my laptop there are eleven different processes that are kernel spawned/owned processes.