QNX CRASHED MY CAR

THE Q-N-X OPERATING SYSTEM IS A BAG OF HURT COMMA AND I KNOW BECAUSE I'M SITTING AT HOME WITH MY ARMS WRAPPED IN CASTS FROM MY SHOULDERS TO MY FINGERTIPS AFTER MY CAR CRASHED INTO A RAVINE PERIOD TAKE THE TIME TO READ THIS IF YOU DRIVE COMMA OR ARE THINKING OF BUYING COMMA A CAR RUNNING THIS QUOTE REALTIME UNQUOTE OPERATING SYSTEM PERIOD

I BOUGHT A NEW CAR LAST YEAR BECAUSE I WANTED THE MOST EFFICIENT DRIVE OUT THERE COMMA MEANING A V8 ENGINE RUNNING Q-N-X PERIOD IF Q-N-X CAN RUN HOSPITAL EQUIPMENT THAT KEEPS PEOPLES HEARTS BEATING AND LUNGS BREATHING THEN IT MUST BE OKAY TO RUN A CAR ENGINE COMMA RIGHT QUESTION MARK THAT'S WHAT I THOUGHT AT LEAST PERIOD

QNX 6.5 Plagued by Performance Problems

Tonight, I installed QNX 6.5 on my new PC that I bought just a few weeks ago. It isn't top of the line, but it's more than adequate for daily Internet and office stuff, and even a little gaming and compiling. And while I know that QNX isn't the fastest operating system in the world due to its realtime nature, I was more than a little underwhelmed by its performance—especially for development.

From Floppy to Flash: The New QNX Flash Demo

Long ago and far away, a little company called QNX Software Systems (QSS) had a tiny operating system. It was so tiny it ran on things like wristwatches, hospital machinery, and remote-controlled cars. So small was QNX that QSS decided to show off with a one-of-a-kind floppy disk demo.

About a dozen years later, QNX is doing it again. Thank to some new features in its newly-released QNX 6.5, QSS is distributing 256 MB flash drives with a full, working install of QNX 6.5 with multi-core support. But let's look back at the forerunner to this project.

QNX 6.5: Forgettable Upgrade

I can't let any year pass without reviewing QNX, especially not for a major upgrade. Despite being passed from Harman Kardon to Research In Motion like a dirty old dollar bill, QNX Software Systems released QNX 6.5.

My new 3.33 GHz Core i7 980X system with 24 GB RAM was screaming for a challenge, having eaten through Windows 7 and Ubuntu 10.10 in the last few months without complaint. Would QNX live up to its own hype?

QNX 6.5: “New” Version Same as Last Version

Every few years, QSS releases a major new QNX update and I, like dozens of other people around the planet, install the latest release of the infamous microkernel operating system, hungry for significant updates. And, since QSS just released QNX 6.5, I immediately got started with it.

I set a guideline for myself in evaluating QNX 6.5: use it like I would Windows 7 or Mac OS X for one typical evening of relaxation, communication, and work. I shot over to http://www.qnx.com/download/ and got to work.

QNX Interface Lags Mac, Windows

I've been a QNX user since 2000, when QNX Software Systems released the new Neutrino-based QNX6 platform. This was a large-but-welcome upgrade: QNX finally had a 32-bit kernel with hard realtime capabilities that ran on multiple microarchitectures. Likewise, the Photon microGUI was much improved and was even impressive for its day.

Apple's Mac OS 9 was working with the Platinum interface introduced in 1997 and Windows, at the time, was still using the Chicago GUI from 1995. QNX took a couple pages from each company's interface book for Photon and the system had a cutting-edge look and feel. But the industry didn't stand still, and Apple and Microsoft both upgraded their graphical user interfaces significantly in 2001.

The GUIs were much improved: Apple's Aqua interface had been the darling of the industry since Mac OS X Beta was available, and debuted to a chorus of praise while Microsoft showed off their Fischer-Price scheme that wowed non-technical users and other lower rungs of society. But QNX stayed still.

QNX Ignores Desktop Standards, Security

Last May, QNX released a minor update to their flagship operating system, QNX RTOS. The tweaks and optimizations in 6.4.1 kick things up the proverbial "notch" and deliver some surprises too, so long-time users and curious, potential switchers have some things to pore over.

I installed QNX 6.4.1 on a Dell Precision T7400. The system sports eight 3.2 GHz cores and 12MiB L2 cache in two Xeon X5482 quad-core processors running 16GiB RAM. This machine is some serious, high-end iron. It whipped Windows 7 prereleases around like a wrestler with a newborn babe and Ubuntu similarly slid around like race-cars hitting oil on the track: there wasn't anything this colossus couldn't compute.

Likewise, QNX rushed through all but the most demanding tasks. I work at a 3D movie effects studio, which shall go unnamed in this review, and I was curious about QNX's realtime abilities and their effect on rendering. So I began the process of porting some of our in-house custom software to the little microkernel that could. Our software is POSIX-compliant, meaning it should port to any standard Unix, but here I hit my first snag. QNX is anything but standard.

QNX 6.4 > 6.3

I had been running QNX 6.3 on my trusty old 1.4 GHz Pentium III system with two gigs of memory for the last couple years and it was alright. Never quite fast enough despite decent hardware (P3 chips were 2x as fast as P4s clock per clock, don't whine otherwise) and limited hardware support, I was looking forward to the upgrade because, finally, after four years I might get a better-optimized system.

QNX Missed the 64-bit Bus

Why, on my eight-way Xeon 5365 system, does QNX only report a single 1.333 GHz chip? And why, after spending thousands dollars on RAM, does QNX only see four gigabytes of it? These were the first signs something was amiss with this tiny operating system touted as being capable of running cars, hospital devices, and entire networks all from a single floppy.

And being on an ISO apparently doesn't help. Freely available from their site with a gratis license, I decided to give it a spin after reading the announcement that QNX Software Systems had Open Sourced their kernel and, a week later, their multi-core support. They had even rolled up the last several years' worth of updates, something devotees had been clamoring for.

But all to no avail. After repeatedly power-cycling my system, I stumbled upon a nice little quirk of the OS. To run QNX with SMP or MMCP support, you have to manually backup, copy, and rename an alternate kernel into place from the command line. If this were Mac OS X there would be a mutiny. QNX ought to keep that in mind if it wants to be taken seriously.

So now, with all eight 3 GHz cores showing, QNX still only saw four of my thirty-two gigabytes of memory. Returning to EFI, I saw QNX was booting in 32-bit mode. After poking around the operating system, QSS's site, and finally Google, I came to the cringe-inducing conclusion that QNX wasn't booting in 32-bit mode — it's just 32-bit. Period. Not 64-bit, not mixed-mode, nada.

Let's allow that to sink in. QNX is a wholly 32-bit operating system. The CPU industry has moved to 64-bit, which addresses up to 16 XB of memory, two magnitudes greater than what is typical today. Think of the difference between kilobytes and gigabytes, and then imagine being able to use only four kilobytes of your sixteen gigabytes of RAM. Infuriating, no? Not to mention stupid.

Truth be told, I was so disappointed in QNX that I completely gave up when I realized top wasn't installed with the OS. I did install the GNU package, didn't I? If my name were Dan Dodge I'd be ashamed of myself. Even Linux includes a more or less complete UNIX command utility set.

I understand having to run a car with 96K of system memory, or an emergency respirator with half that much, but with the breadth and depth of networks today leaving QNX only capable of addressing four gigabytes is shortsighted. We're talking QNX developers, the platform's lifeblood, not being able to use the latest systems to make great new QNX apps with.

If you're running a Pentium 4 and don't particularly care about having a usable OS or developing good software, check QNX out. If you're pushing the limits, however, don't expect QNX to push with you.

Major QNX Upgrade to Rock Embedded World

QNX is about to take another quantum leap forward. Production on a new QNX kernel, dubbed "Axion," aka QNX 8, is wrapping up later this summer and will debut sometime early next year. And it's going to pack a wallop in the embedded industry.

"Technologies like 64-bit, VT, SSE, and multi-core have all become important in the market today," said Luc du Croix, senior kernel engineer with QNX Software Systems. "And it's important that QNX take advantage of each and every one of them."

We spoke with du Croix, who has been with QSS for over a decade in various roles, about the changes coming in the new operating system. For the last year, he and his team have been hard at work rewiring their kernel alongside Intel and AMD engineers so they can support new features as soon as possible.

"With this upgrade we're actually using different SSE operations to speed kernel performance." Heretofore, SSE was seen mostly as a multimedia booster, useful for games and Photoshop plugins. "Imagine using a single instruction to move up to one hundred and twenty-eight bits of message data."

Multiple cores are key too. QNX already supports multi-processing and has won awards for its efficient use of multiple processors. But massively multi-core processing (MMCP) is a little different. "SMP is like starting a fire with sticks. MMCP is like lobbing a Molotov cocktail out of the window of a speeding Ferrari and that's what we'd really like to be doing."

Another thing that's changing is processor caching. Back when Neutrino was released, 256k off-die cache was common. Today, 2 MB on-chip cache is the norm. "QNX Neutrino is tiny, 69k, and with all of the processor cache available today, we've rewritten the kernel to load and run entirely from cache."

Running from cache has some serious speed advantages. "QNX messaging is a whole order of magnitude faster when run from cache versus system memory," du Croix said. "It prevents QNX from having to access the system bus." QSS calls this feature FastCache.

When QNX does run in main memory, however, it will be able to access up to sixteen exabytes thanks to the 64-bit ground-up rewrite. "Thirty-two bits just wasn't enough," du Croix said. "Our customers want to run on AMD 64, Core 2, Power6, and they're all playing with 64-bits."

After the update is polished, it will be bundled with the latest version of the Eclipse development suite and offered as an upgrade to developers as QNXtreme, the successor to the current QNX 6.3-based Momentics. QSS will also include a whole new userland based on FreeBSD 6's, an idea left over from the scrapped Overfiend project.

Customers deploying production systems will have the option to upgrade when the time comes as Axion will be completely backward compatible with 32-bit platforms. Customers using QNX4, however, will likely want to contact their QSS rep for evaluation.

Follow-Up With Sven Jörg, BNX Project

Today we have a second interview with Sven Jorg, head developer of BNX, an implementation of Haiku on the QNX Neutrino microkernel. Since the last interview, public reactions have formed about the project and the BNX SourceForge project has gone live. We'll cover those and other topics in the talk below.

1. Grant: Hi Sven. First things first. How do you pronounce BNX?

Sven: I pronounce BNX as |binɪks|.

2. Grant: And in the IPA no less! Very good. Moving on, your SourceForge project went live. When we last talked, it was still pending approval. What was that all about?

Sven: SourceForge has a slow approval process that typically takes several days. In our case, however, another project was using the BNX name. Since it was inactive, we requested to take over the name. At this point Eric S. Raymond stepped in and told us that unless we used the Linux kernel, he would prevent our use of the BNX name on SourceForge. He was holding our project name hostage. We had to appeal to higher-ups at SourceForge and they eventually approved our request. So, finally, our SourceForge project is up and running.

3. Grant: I never knew Mr. Raymond took such a particular interest in what software SourceForge projects used.

Sven: Nor did I. The people from SourceForge said it's been a problem lately and they're trying to get him some help.

4. Grant: I hope everything goes well for him. What else has happened with BNX since we last talked about it two months ago?

Sven: We've looked more into XFS and its performance. We've been delighted with what we've seen. We're running Haiku and have found it to be quite stable. My test system only crashed twice in an hour! But on our new box, I was up to six crashes an hour. I was very impressed. Our new system uses dual processing and performance is simply astounding. We're multi-booting BeOS 5, Haiku, QNX 6.3 and Linux 2.6.16.16 using XFS. We also have Windows XP on there for games and Windows Vista build 5381.1 just because.

5. Grant: What kind of new development system did you get?

Sven: It is truly a sweet-ass setup. It took us the last six weeks scouring eBay for the parts, but every second was worth it. Our new system has half a gig of ECC RAM, two 320 GB hard drives, a Radeon 9200 PCI graphics card, and two 200 MHz Pentium Pros with 1 MB L2 cache each. And to top it all off I overclocked the chips to 233 MHz! Linux starts up in less than two minutes! We are ready to rock and roll.

6. Grant: Wow, that's some serious hardware. But why didn't you opt for something a little newer?

Sven: Well for one we are not a rich project. It is only Adolf and I. There is no financial base for the project, just the time and skill we can muster. No one gets paid to make BNX. For two, if we are getting our clock speeds up to the 2 GHz range, that would be something like 10x the speed of the Pentium Pros, and we would be at 60 crashes per hour. How could we develop an operating system? All of our time would be spent crashing and rebooting, never getting any work done. Six crashes per hour is a workable rate — 60 is not.

7. Grant: I guess that makes sense. Now, there were some questions raised after our last interview. First, are you aware of the existence of Zinzala, a BeOS-inspired work-alike for QNX?

Sven: Yes. It was, in part, inspiration for BNX. But as far as its usefulness goes, it hasn't been updated since 2004. It was also proprietary and, most importantly, was not BeOS-compatible.

8. Grant: Do you think your projection of a year until usability is an accurate one?

Sven: Our work lies in two places: making Haiku work on Neutrino and making Neutrino and Haiku work with XFS. I think the making XFS work will take between three to six months. QNX has no problem with XFS, it's just another userspace process. We might run QNX off its own file system and Haiku on XFS, but we'd prefer to have everything on XFS. It took three years to fully integrate XFS into the Linux kernel after SGI released it under the GPL. But we have their work to go from, So about 36 months for them but only six months for us.

Getting Haiku to work with Neutrino is the real challenge, and I believe it will take nine months to make Haiku work on Neutrino. Hopefully with the work we do to Haiku's servers, they'll be kernel-agnostic and you could run them on anything.

9. Grant: So does that mean that you will be developing the Haiku servers and integrating your changes back into the project? There was some noise over that — whether you would fork or share improvements with the main project.

Sven: What we'll do is share our changes that are easy to share and let Haiku integrate what they want. I imagine a lot of our changes will only be useful in certain contexts. But they can do with it what they want. We may end up forking but we'll try to avoid that as long as possible. Haiku would be a more powerful project if they had support for more than one kernel, so they will be thanking us before long.

10. Grant: Haiku News ran an item about BNX being yet another Haiku derivative and expressed doubts about the project.

Sven: This is insecurity and jealousy. BeOS users have seen a lot of failed attempts to resurrect their favorite operating system. Haiku has every right to think they will do the best with the bits they're making. We will prove to them just what BNX can do in the future. But really, if they don't want us using their servers on another kernel, they should change their license. It's as simple as that. Don't whine about us using your code when the license you used allows us to! I just have this to say: Don't worry, be happy! You're getting Neutrino support for free!

11. Grant: Does any work with Neutrino itself have to be done?

Sven: It could be, but with how we're licensing it, it'll be a stock QNX Momentics SMP kernel with no customizations. We took this route because frankly it was cheapest for us as developers and for potential end-users. Haiku source is open; QNX is closed and any work on it would be expensive if QNX even does work like that. We never even asked if they modify their kernel for customers. We will eventually use a custom configuration for Neutrino, tuned for our priorities, which will be much different from a typical QNX install.

12. Grant: Is there anything else you would like to address today?

Sven: If there are any more concerns or questions, please contact me directly. Thanks for the interest in BNX. See you at the SourceForge!

BNX? Sven Jörg Talks About Merging BeOS & QNX

In the last few years, BeOS fans have witnessed the beginning of what some say is a renaissance for the beleaguered operating system. Haiku, an open source re-implementation of BeOS based on a kernel by a former BeOS developer, and Zeta, based on official Be source code taken over by German firm yellowTab, are the two projects on which many place their hopes for a BeOS revival.

And then there's the focus of today's interview with Sven Jörg — BNX, a mating of Haiku's open source BeOS servers with a specially-licensed, real-time kernel from QNX Software Systems. Jörg, lead developer of the project, talks with us today about his team's unique approach to their BeOS successor. I corresponded with Sven over the course of several weeks regarding what led the BNX team to their idea and how they will implement it in the near future.

1. Why the need for another BeOS? With Haiku and Zeta, haven't all the bases been covered?

Sven: Some might be happy to accept that. But those two other approaches have some serious drawbacks. Haiku is working on recreating an operating system that at this point over six years without an update. By the time they have something to fully replace BeOS 5, it'll be ten-year-old technology. When it's done, it'll be like 2000 all over again. In 2010. You might be able to use it to run old BeOS apps for nostalgia, but that's about it.

With Zeta, yellowTab are amending the BeOS API to make it more modern, but as hardware is changing so much so quickly today, they must devote a lot of resources to getting Zeta working with USB 2, FireWire, multiple cores, 64-bit, etc. Zeta takes the same small/efficient approach BeOS did, and it's farther ahead than Haiku is, but it still has the same basic problem: They are a long way from what we consider modern hardware and operating system concepts in 2006.

2. What is the ultimate goal of the BNX project?

Sven: Our goal, simply, is to create a bleeding-edge BeOS that can be used for high-end production. We want BNX to be a Media OS today, like BeOS was in the late Nineties.

3. What has changed that you must address in BNX in order to be a modern Media OS?

Sven: Two things. What an OS is expected to do, and the hardware it is expected to support.

Six years ago MP3 was coming into its own. Video-on-demand was also in its infancy. Now we have ways to manage tens of thousands of MP3s with just a few clicks and we're right on the verge of video-on-demand being ubiquitous. There's simply no BeOS solution to do anything like that. The Web has become richer and more complex, and has crept into the rest of the OS. Graphics standards have shot ahead as well. Everything is richer and offers more functionality.

As far as hardware goes, What was yesterday's high-end server or graphics workstation is now on the desktop and today's high end workstation includes 64-bit, four or more gigs of memory, two or more cores, larger and faster cache memory, real-time video encoding, etc. And here we have BeOS still choking on half a gig of RAM. This is the first thing that needs addressed in order to truly bring BeOS ahead to current times — modern hardware support.

4. How do you intend to take care of the hardware support problem without being bogged down in it like you say the other two BeOS projects are?

Sven: We asked which part of the OS that had to be upgraded in order to take advantage of these things, and that was the kernel. From that realization, we agreed that recreating it would take too long, as with Haiku. Licensing the actual BeOS kernel wasn't an option but still would have left us with too much work to do. So we began shopping for kernels.

5. What different options did you look at?

We looked at Linux first, of course, because it's everywhere nowadays. And we we weren't satisfied with what we found. Linux takes a very sturdy, monolithic approach. It's so sturdy and monolithic, in fact, that it's just plain bloated.

6. What about the real-time extensions to the Linux kernel that have received so much attention in the last year or so? Did you look at those?

Sven: Real-time Linux extensions are basically hacks. You can't expect it to be as good a product built to be real-time. Go with something built from the ground up to perform a certain way rather than a poorly kludged mess. This was the route the BlueEyedOS project had taken years ago. And looking to that project today, it is a footnote. Linux sucks.

7. Were there any other options worth noting before you settled on QNX Neutrino?

Sven: We looked at almost every popular Open Source kernel as well as a few commercial ones. None of them made sense, either because of their capabilities and performance or their licensing programs and prices.

8. So what was it about QNX that seemed right?

Sven: Adolf, one of the other BNX developers, dual-booted QNX for several years and had a lot good to say about it. And from there it was pretty simple. They have a proven track record and they aggressively support the latest hardware. Since they have a microkernel, you can choose which parts of the OS to license and which to leave out. We could just take the kernel and let QNX take care of the hardware while we focused on moving the BeOS API ahead.

9. So what parts go where? Are you licensing the whole QNX shebang?

Sven: No. All we want from them is their kernel. We'll throw Haiku's servers on top of it. In this manner, we get the tight fast kernel that supports new hardware innovations and the free time to work on the API of the system. We're also looking at taking some parts from elsewhere, like the TCP/IP stack from FreeBSD and and the XFS file system from IRIX. We will take whatever will give the BeOS API the best advantage, even if it means going beyond BeOS itself.

10. Where is the project now? What are your near-term goals for BNX?

Sven: We are running QNX Momentics 6.3 SP2 as our development platform and, thanks to QNX's modular design, are getting different parts going. While we test parts for our OS, the whole QNX OS is already there working. So for instance we can just fire up the TCP/IP stack and test it. Moving to XFS is another goal, a bit trickier but so far it still seems feasible. Before we do anything else, we want filesystem and networking support on top of our kernel. From there we will get Haiku's BeOS servers running, and that will take some work. They have to be modified to work with Neutrino and our new file system and networking stack. After that, it's pretty much all in place.

11. To get it down to a number, when do you expect to be able to run BeOS apps?

Sven: Within a year from now.

12. A year? That's a fairly short amount of time compared to the other projects.

Sven: We'll spend a year getting things together and still end up just about where the others are in terms of functionality. That's thanks to using Haiku and Neutrino. We can focus on sewing it all together rather than recreating anything.

13. What were the licensing terms with QNX Software Systems?

Sven: We aren't allowed to comment on any of the figures or stipulations involved, but I can say that their contract with us was very generous. It went a long way to making our decision with QNX final. :)

14. Do you find it ironic that many saw BeOS and QNX as rivals at one point and now you're dependent on one to realize the other?

Sven: There aren't really any feelings involved except the desire for a working BeOS successor.

As for the rivalry, I think it was misplaced. BeOS was a Media OS, and QNX was an embedded OS. While there are many common things between the two, they were targeted at different places. QNX only ran on the desktop as a development environment for itself anyways. BeOS ran laps around that incarnation of it.

15. What kind of PC will I need to run BNX?

Sven: You can get by well with a 1 gig Pentium III and half a gig of RAM, though BNX will in theory run on anything the Intel QNX Momentics system would run on, from Pentiums on up. Adolf is on a 450 MHz Pentium II system with 512 MB RAM while I use a 2.8 GHz Pentium 4 with a gig of RAM. It will depend on what you want out of the system, really, that will dictate hardware requirements. The newer the better though. We're about to get a Core Duo system to develop on.

16. And what's the current status of the BNX project page at SourceForge?

Sven: Another project had the BNX name already, but since it was inactive, we took it over. Unfortunately that process takes about two or three weeks to complete. So we have our page, we're just waiting for it to activate.

17. Thanks for taking the time to talk with us, Sven, and best of luck on the project.

Sven: Thank you, Grant.

Interview With Paul Leroux of QNX Software Systems

Today we're happy to feature an interview by Grant Hayes of MacSlash with Paul Leroux, a technology analyst with QNX Software Systems, who is participating in Embedded World 2006. In the interview, Paul discusses the changes QSS has experienced in the last couple years, new and established competition, and moving forward in the marketplace with new technology.

1. How has QNX changed since its acquisition by Harman International in 2004?

Paul Leroux: If you polled QNX employees with this question, 99% would tell you that life at QNX has remained remarkably stable. Granted, we're now part of a much larger organization, but we still target the same markets (networking, automotive, industrial automation, medical), offer the same value-added services, and maintain the same technology focus.

Harman, of course, is strongly focused on automotive and home infotainment products. In fact, they acquired QNX because they see software, and the QNX Neutrino RTOS in particular, as key to achieving differentiation in those markets. Nonetheless, Harman encourages us to target multiple industries, including networking and automation. One reason is the cross-training effect: The more that cars and home entertainment systems become network-connected, the more that QNX's expertise in networking will help enable products in those markets.

Likewise, the graphics technology that QNX originally developed for control systems and high-end videogaming devices is proving invaluable for in-car navigation and infotainment units. Our expertise in one market feeds the others.

Our management has also remained stable, with the notable exception of our new head of R&D, Charles Eagan. Charles is a former Cisco executive and longtime QNX developer, and he brings lots of know-how to the table. Dan Dodge remains at the helm as QNX CEO and CTO.

2. Where is the current focus at in QNX Neutrino development?

Paul Leroux: We have two big pushes: a new technology that constitutes a radical departure from conventional OS partitioning, and a new mode of multiprocessing that helps developers migrate easily to multi-core processors.

Let's start with partitioning. Most embedded systems nowadays need to be secure, connected, and upgradable; they must also deliver fast, predictable response times under all operating scenarios, including failure conditions and system upgrades — that's a pretty tough set of requirements. Consequently, we've just introduced adaptive partitioning, which provides each software subsystem with a guaranteed share of CPU cycles, even when the device experiences a heavy processing load or a denial-of-service attack. With adaptive partitioning, a user can download and start a new software component without compromising the real-time behavior of existing components — even if the new component misbehaves and starts running in a loop at the highest priority level. Process starvation, which is always a concern in priority-based real-time systems, is eliminated.

Now the cool thing is, adaptive partitioning will enforce CPU guarantees only when the processor runs out of spare cycles. Otherwise, it uses standard, priority-based preemptive scheduling. This approach allows busy partitions to borrow unused CPU cycles time from other partitions and permits 100% processor utilization; it also allows developers to code their embedded applications the exact same way they do today. This is a far cry from conventional fixed partition schedulers, which force developers to redesign their apps and which prohibit full CPU utilization — a real issue for resource-constrained embedded products.

As for multi-core, we've introduced bound multiprocessing — BMP for short. Most developers are already familiar with SMP, where one copy of the OS manages all processor cores simultaneously, and applications can float to any core. Well, BMP shares SMP's scalability and transparent resource management, but also lets you lock any existing software application, along with all of its threads, to a specific core. That way, applications written for uniprocessor environments can run correctly in a multi-core environment, without modifications. Moreover, those legacy apps can run in conjunction with new applications that take full advantage of the concurrent processing provided by multi-core hardware.

Of course, we still support SMP and AMP — developers are free to choose which form of multiprocessing works best for their design.

3. Who is adopting QNX Neutrino lately?

Paul Leroux: The auto market has embraced QNX Neutrino in a big way. Companies like Audi, DaimlerChrysler, Honda/Acura, Hyundai, and Saab all ship QNX-based telematics and infotainment units in their vehicles. Networking is also very strong — witness the release of Cisco's flagship, the CSR-1 routing system, which is based on our microkernel technology.

At the same time, we're seeing a resurgence in our traditional markets, industrial automation in particular. Sales to industrial customers grew considerably last year — more than we expected. Personally, though, the most exciting development this past year was the new QNX-based Laser Camera System for the space shuttle Discovery. It isn't the first time that QNX has been used on a space shuttle, but it's cool knowing that QNX helped the Return to Flight mission become reality.

4. Are QNX 4 customers upgrading to QNX Neutrino?

Paul Leroux: It all depends on their requirements. Many QNX 4 users have upgraded to QNX Neutrino because it offers fuller POSIX compliance, targets multiple processor architectures, and supports tools for memory analysis, code coverage, application profiling, and system profiling. At the same time, we've redoubled our efforts to help users to stay with QNX 4, if that's what's best for them.

For instance, we've released the first in a series of QNX 4 driver updates, which provide support for a variety of network chips, graphics chips, and ATAPI controllers. There's even a new USB 2.0 driver that supports HID, printer, and mass storage devices. Developers can find out more by visiting the developer support center on the QNX website.

5. When can we expect a successor to the QNX Momentics self-hosted development suite?

Paul Leroux: We've been very quiet about this, but starting soon, developers won't have to wait for new versions to get their hands on the latest QNX technologies. That's because we're working on a new component-based model of product releases. Rather than force developers into major upgrades — the traditional method — we will release new features as they become available. Moreover, developers will be able to integrate these new features into their existing QNX environment, and just as easily "unplug" a feature if it doesn't address their requirements.

We can do all this because we designed our technology from the beginning to be modular and component-based. The new product rollout model will leverage this inherently modular design.

6. Let's talk about competition to QNX. Specifically, real-time Linux has advanced quite a bit in the last few years. How does this impact QNX?

Paul Leroux: Despite those advances, Linux's real-time capabilities still lag far behind those of the QNX Neutrino RTOS — and that won't change anytime soon. Embedded design is all about doing more with less, and QNX Neutrino can achieve better latencies on low-cost, low-power processors than Linux can on higher-end processors. With QNX, you shell out less for hardware, you get better response times, and you still get a full-fledged POSIX OS. Plus, you can now have guaranteed CPU time for critical tasks, even if your system is under load or a DoS attack.

Even if Linux could approach QNX Neutrino in terms of real-time performance, real-time constitutes just one of many reasons why customers choose us. For instance, consider our component-based microkernel architecture. It provides finer-grained fault tolerance than Linux, and allows users to replace and upgrade drivers, protocol stacks, and other low-level services on the fly. That makes it extremely attractive to anyone building routers and other high-availability systems.

7. How about competition with more traditional rivals, like WindRiver and its VxWorks?

Paul Leroux: You can no longer assume that a competitor who, say, is strong in defense systems won't try to take away your automotive business. Technology requirements are becoming increasingly similar across market segments, and everyone is attempting to leverage their success in one segment to gain traction in others.

That said, some of our competitors have made the fatal mistake of assuming the OS has become a commodity — they've started to believe their own hype. But in the embedded business, technology really does count. When someone is about to embed an OS into hundreds of thousands of devices, chances are they'll want the fastest, most reliable, most cost-effective technology available. Because we still believe in the OS, because we focus aggressively on making our OS more secure, more reliable, and easier to work with, we hold a serious advantage.

8. What are QNX's technical benefits over Windows CE? What is competition between the two like?

Paul Leroux: For a technical comparison of QNX Neutrino and Windows CE, there's no better source than Dedicated Systems, an independent firm that has performed exhaustive tests of both OSs. Their evaluations found that QNX Neutrino was the top choice when it comes to real-time performance and OS architecture. In fact, version 6.3 of QNX Neutrino scored higher than any other RTOS that Dedicated Systems has ever evaluated. QNX Neutrino also surpassed Window CE on "softer" measures, like ease of installation and quality of documentation. Anyone interested in these results can download detailed reports from the QNX website.

From a market perspective, Windows CE is strong in industrial automation and in certain segments of the Japanese auto market, notably navigation. Aside from that, we rarely come up against it.

9. Does the eQip project have any official status within QNX Software Systems?

Paul Leroux: For those who don't know, eQip stood for "embedded QNX for intelligent platforms". A pair of QNX developers launched the eQip project on their own initiative, with blessings from R&D management. It then evolved into a community project — and a pretty cool one, at that. When people first started downloading the eval version of QNX Neutrino, many of them didn't realize that this rich OS environment can scale down to small form factors, and still deliver lots of functionality. eQip helped correct that perception, by demonstrating the cool features — and impressive graphics —6 that QNX can bring to something like a PDA.

10. What's one thing that has excited you about QNX lately?

More than anything else, our adaptive partitioning technology. First of all, it's a unique feature in the OS world - no one has anything quite like it. And besides enabling higher levels of security, it can play a huge role in simplifying software integration. The firmware for the average embedded project is doubling in size about every 10 months, so it's now commonplace to have multiple development teams work on a device's various software subsystems. While this approach allows subsystems to be developed in parallel, it often leads to major headaches during integration and testing, when the subsystems suddenly have to contend for processor time. Components that worked well previously suddenly become starved of CPU. Adaptive partitioning can help by letting systems designers allocate a CPU budget to each development group beforehand. Each group can then test their code within their allocated partition under simulated worse-case conditions, knowing that the code will display similar performance at integration time — a good thing, when you're trying to get product out the door!

QNX to Support Intel Macs

I work for a company that uses QNX, a real-time Unix-like operating system for embedded devices such as car computers, phones, medical equipment, and air traffic monitoring systems. I personally use QNX to develop QNX apps, as there's a self-hosted version of QNX for Intel that developers can download for free. It's essentially a free desktop operating system, as only the development kit is pay-for.

We work with several QNX engineers from time to time and on their last trip in they showed us a preview of the next major upgrade to the system, QNX 6.4. Like its predecessors it ran on Intel, and they said this update will take advantage of Intel's new processor architecture as well as a few new platforms. When I pressed them about it, they said they were 99% certain that QNX 6.4 would run on Apple's new Intel Macintosh.

I asked him the how and when, and he said that Apple's new Macs are going to be very PC-like, and if they can run a stock install of Windows, QNX won't have any problem supporting them either. He said Apple promised the first Intel Macs in the second half of '06, which is when QNX 6.4 would be released. He also said that QNX has at least one Developer Transition Kit that QNX 6.3 runs just fine on.

Things are looking exciting as Apple will instantly have a handful of good operating systems to run on its new Intel hardware. QNX is a good addition, and I wanted to make sure the word got out. We weren't under NDA and the QNX guys said to go ahead and tell anyone we wanted, and that an announcement was forthcoming soon anyway. So there's at least one embedded real-time Unix-like system for new Intel Macs.

My First Month With QNX

Last month, I downloaded and installed QNX Momentics Development Suite 6.3, which is a full QNX Neutrino install for Intel with a temporary license for the commercial Momentics Development Suite that lasts for a month. After working with it for the last several weeks, I have some impressions of the system, both good and bad, that I'd like to share. But let's begin at the beginning, as they say, and go from there.

I was ready to boot and install QNX within an hour of first navigating to the product evaluation program page. Downloading the 500+ MB ISO file is a cinch, including the sign-up that gets your 30-day Momentics license sent to you. After that it's all just burning the image to disc. My license email came before the ISO was finished transferring and the burning went without incident.

Installing QNX was even simpler than downloading it. One thing fans of non-Windows operating systems will note, though, is the lack of a partition utility. The QNX installer is pretty obtuse, allowing you a choice of the whole disk or some fraction of it. This means you should have the disk pre-partitioned before you install QNX. In my case, I was taking the whole disk so the above was moot.

The actual install took about 10 minutes from boot to reboot and the only pause was when I had to enter my Momentics license. As an interesting note, if you choose not to enter your license the rest of the system still starts and runs, and only the Momentics suite is disabled. From what I saw in the installer, it's not even installed without the license. Effectively, QNX distributes a free real-time Unix-like operating system!

Booting was fast, less than 20 seconds. One can use QNX in text-only mode as well as in Proton, QNX's windowing system. Proton's integration with the rest of the system is almost as tight as the Windows or Mac OS X GUI, though it's not as polished. The GUI starts by default, where one enters root with no password to log on. From there you can make your own user account, which I recommend.

After logging into my own account I explored the system. The Proton system uses a panel at the right side of the screen as well as a dock at the bottom. The dock at the bottom is pretty standard, with a Start-like menu and minimized windows; the panel at right is where one can find links to programs, workspaces, and system performance monitors that give real-time feedback on processor, memory, and network usage.

QNX's applications all run very well and work seamlessly with the rest of the system. I really have no complaints. They even have a port of FireFox running as fast as ever for standards-compliant browsing. QNX's file manager is quick and gives an accurate view of the file system, and their software manager easily beats anything Linux has to offer. And everything launched in under five seconds.

My first real disappointment began when I opened the terminal and began playing with the command line. A lot of standard utilities are there, like uname, but a lot are also missing like the ever-important top and du. There's also no sudo and their version of ps is woefully out of date. If QNX wants to make a serious desktop platform, they ought sync their userland with a popular Linux or with FreeBSD as Apple does.

Another area that underwhelmed me was performance. The test system used for this article was a 3.6 GHz Pentium4 with HyperThreading turned on, 1GB RAM, and large 200GB hard drive. Performance felt identical on the second system I installed it on, a 450 MHz Pentium II with 128MB RAM. Windows XP was several times faster on this same hardware, as were several Linux distros, FreeBSD 5.4, and Zeta 1.0.

When I investigated why QNX would perform so slowly, I found — thanks to several users in various QNX forums — that QNX scheduling is much different from a typical desktop system due to its real-time nature. While real-time means that there's a guaranteed response time, this doesn't necessarily ensure lightning-quick desktop responsiveness. I'd recommend QNX allow switching between a few different scheduling schemes.

Support is another front that's confusing. A service pack was released a year after 6.3 was launched, but there's no word on whether there's another service pack in the coming. Launching the software manager is the best a user will get, and with only one service pack, the user feels left in limbo. Understandably, paying users get great support, but more updates for the software itself would be appropriate.

Overall, I give QNX 6.3 three-and-a-half stars out of five. It's stable and does not crash, installs quickly, and is easy to sit down and start using daily. Its unpredictable desktop performance, lack of a rich Unix userland, and simplistic installer are all places the developers at QNX Software Systems would be wise to focus on for the next version, however. Until then it's not quite ready for prime-time.

How QNX Failed Amiga

The Amiga platform has exhibited amazing longevity for something so plagued by problems. And for a platform with such problems, it's been an excruciatingly slow march to resolve matters. Amiga is still running a twenty-year old operating system on chips that haven't been updated in over eleven years, and is only able to use anything modern through emulation or as an add-on card. What other platform offers accelerator cards faster than the main CPU by a factor of ten?

Accordingly, the sorry state of Amiga lays mostly to blame in its many sponsors over the years, from Commodore to Escom to Gateway and finally to Amiga, Inc. Each and every one of these companies have fumbled the ball in directing Amiga, burying it further and further every year. Third parties have stepped in to alleviate this, but can not push the platform ahead, only offer it short-term boosts that allow applications — and not the operating system — speed-ups and modern features.

Enter QNX Software Systems, contracted by Gateway in 1997 to create a desktop operating system based on its embedded QNX Neutrino micro-kernel environment. QNX was a significant player in the embedded industry and had a reputation for efficient, real-time systems that oversaw everything from medicine drips to auto-assembly robots. It looked like such finely-honed technology would be the proper bridge to the second coming of the Amiga. Appearances, however, can be deceiving.

Interview With QNX's Vince Davis

1. Since the acquisition of QNX Software Systems by Harman International, has the direction of QNX's software or strategy changed?

Vince Davis: Harman has taken the attitude that QNX Software Systems knows what's good for itself, and that what's good for QSS is good for Harman's telematics needs. So basically QSS retains its autonomy. Having said that, some things have changed, and for the better.

Harman's financial backing has helped us go ahead with research and implementation that would have otherwise waited, so we can be more aggressive in delivering new technology to the marketplace. This means we can compete more effectively in the embedded arena against some of our larger competitors, such as WindRiver and Microsoft, and support new hardware faster, closer to its release date.

2. How is the competition going with Linux/Montavista? What are QNX's advantages over Linux?

Vince Davis: Real-time Linux is simply real-time kernel extensions running on top of a non-real-time kernel. I guess one could say Linux's advantages over QNX would be that it's more familiar to some customers since their developers know Linux already. In other words, our competition with Linux in the embedded space is with customers' comfort and prior investment with Linux.

QNX is better for real-time applications because it is built from the ground up with our microkernel which requires fewer system resources to run and less development time to customize. Linux's regular monolithic structure with extensions is a real kludge, so system deployment is nowhere near as efficient during development or runtime. Projects that have very specific requirements benefit greatly from our software.

We're working on a porting guide and some slick porting tools for release with QNX Momentics 6.4 to help ease developers from Linux to QNX. Changes are already minimal since we use POSIX, but we're doing everything we can to make moving to QNX effortless. Eventually we'll be including more GNU tools as well, making the QNX experience more similar to Linux than ever (see below for more details).

3. How does QNX compare to WindowsCE?

Vince Davis: WinCE is a lot of things to a lot of people, and to discount Microsoft in the embedded market is foolish. We're always keeping abreast of competitor's progress, and having said that, QNX Neutrino compares to Windows CE favorably both in mindshare and technology.

The embedded market is a lot different than the desktop market, and Microsoft's desktop offerings are far from being reliable and stable. Microsoft has had to work very hard to make inroads to the embedded world beyond its existing partners. A lot of people see using software from Microsoft as a bad bet and tend to stay with proven technologies from established embedded market players.

As far as the technology goes, WinCE was once based on a sub-set of the Win32 API but has evolved on its own since then. So if you're familiar with Win32, writing for WinCE shouldn't be much of a problem. The problem lies in that Win32 was made for the desktop and was never that elegant; it was more of a forced march with a lot of hacks and fixes along the way.

QNX offers the standard POSIX API, which makes porting Unix software a breeze. Alongside that we offer Photon which was specifically built for running on small system with limited resources, so developer won't have to sacrifice a lot of the system to include a graphical interface. There are also many third-party libraries for use in writing software for QNX platforms.

The kernel of WinCE is specially written for WinCE and its specs aren't publicly available, but it is used in some soft real-time applications. It's probably a monolithic kernel, which compares poorly with QNX's microkernel model. In QNX the kernel just passes messages and talks to hardware, and all other processes — from TCP/IP stacks to Photon applications — run as processes outside the kernel.

4. A few years ago there was an interesting project, eQip. Are there any plans for smartphones or PDAs?

Vince Davis: eQip stand for "Embedded QNX on Intelligent Platforms" and began as an effort to port QNX Neutrino to the iPaq, but quickly broadened to other PDA platforms. It was basically the QNX platform for PDA systems. The project stalled out in early '04 for a number of reasons, one of which was that QNX integrated the efforts this project was focused on, making it redundant.

As for what QNX's plans for smart phones and PDAs are, I can't talk about a lot but I can say it's the one market where QNX is underrepresented and that's changing. QNX makes an excellent phone/PDA operating system platform, especially with QNX Neutrino 6.3's new energy management. I'd keep an ear open in the next year or so for more news regarding QNX on phones and PDAs.

5. Are there plans for a new desktop release of the QNX RTOS for x86? If yes, what features should we expect?

By the second half of '06 we'll release QNX Momentics 6.4, which will include the QNX Neutrino RTOS 6.4. This upgrade will be a large step forward for the platform just as QNX 6.3 was from QNX 6.2. Among the advancements:

1. Integration of SMP support into one kernel. The SMP code is mature enough to sit in with the main kernel without a performance hit, so out of the box QNX will support up to four processors.
2. More of the GNU software library is being ported to QNX. With QNX 6.4, QNX will host all of the typical command-line tools a regular distribution of Linux would include.
3. Photon will support more modularization for ultra-embedded devices. There's some tweaks to how windows are rendered and buffers are retained, so there'll be less of a footprint than before.
4. Compiles using remote resources, more command-line tool support in the GUI, more board support packages, GCC 4.0 integration, and better support for older target versions.
5. Support for the latest Intel processors and chipsets, including the Pentium M and dual-core processors. QNX 6.4 should also be running on Apple's first wave of Intel Macintosh systems as well.

6. Do QNX Neutrino releases have code-names during development?

Vince Davis: Yes, though these generally aren't used beyond the development cycle. QNX 6.0 was Amiga, since it was supposed to be Amiga's new operating system. QNX 6.1 went by Homo Erectus because it was the first entirely QNX-driven release — our first to stand on its own — and Patches A and B were called Neandertal Man and Cro-Magnon Man respectively. We dubbed QNX 6.2 A Night at the Opera and its follow-up, QNX 6.2.1, A Day at the Races. QNX 6.3 was Godzilla and Service Pack 1 was Son of Godzilla. QNX 6.4 goes by Overfiend.

7. What are the minimum chip speed and memory requirements for the QNX Neutrino operating system and QNX Momentics development suite?

Vince Davis: Keep in mind the requirements and recommendations we list are for the QNX Momentics development suite and not the operating system itself. Minimum requirements for QNX Momentics 6.3 are a 700 MHz Pentium III with 256M RAM. We recommend a 2 GHz Pentium 4 and 512M RAM.

Minimum requirements for the QNX 6.4 development suite are likely to be around a 2 GHz Pentium 4 and 256M RAM. (Minimum requirements aren't ironed out until very late in the development cycle, and usually end up being the low-end of PCs at the time of release.)

Happily for many developers and enthusiasts, the QNX operating system will run on much less powerful hardware than what the development suite requires. The bare minimum for RAM is 32M (though 128M is more realistic for actually doing anything) and we've gotten QNX to run on some pretty old processors.

I have QNX 6.3 SP1 running on a dual-233 MHz Pentium Pro system with 512M RAM while another engineer has QNX 6.2.1 running on a 100 MHz Pentium box with 128M RAM. If you want to get QNX running on something older, adjust the boot iso's startup script and go to town. Serious developers will definitely want to stick to something above 500 MHz, however.

Legend of the QNX Upgrade

When I first got involved with QNX, I was looking for a better platform than Mac, Linux, or Windows. Each had had severe disadvantages that I'm sure we're all familiar with by now: Mac runs only on proprietary Apple hardware, Linux is a mess of spaghetti code not ready for a production environment, and Windows is a security and stability nightmare. After having spent years working with these shortcomings of the Big Three operating systems, I discovered and installed QNX.

My initial impression of the OS was that while small, fast, and efficient it lacked applications, drivers, and a polished interface. Booting it alongside Linux and Windows for novelty, I watched for improvements to the platform. When QNX 6.1 was released it became the only operating system on my hard drive. I finally had a truly efficient system that took full advantage of my hardware without the bloated overhead that Linux and Windows had.

This trend continued by leaps and bounds about a year later with QNX 6.2 and again the next year with 6.2.1. Another year and QNX 6.3 introduced an updated GUI and polished multi-processor support. A year after that and QNX 6.3 Service Pack 1 pushed the platform ahead even more. It was around this time, however, that I heard whisperings of a major upgrade to the platform, but all lips seemed sealed tight about the project save for its codename, Overfiend.

QNX Lags Behind the Big Three

I just bought a dual 3.6 GHz Pentium 4 system to install QNX on since last time I was running it was two years ago with version 6.2.1 and it was dog slow. I figured that QNX 6.3, having been upgraded quite significantly, would run a lot better and so bought the best hardware I could for it. I'm pretty depressed by my latest experience with QNX, however, and I'll break down why.

Unlike QNX 6, 6.1, and 6.2, QNX 6.3 (released June '04) has pretty good multi-processor support. For once it's not a big deal to enable the SMP kernel and both chips are properly recognized. I only wish that Neutrino was optimized for HyperThreading and SSE3, because I'm basically running on two 3,600 MHz Pentium Pro chips here. Oh well, two is better than one, multimedia extensions or not.

Speaking of processor annoyances, why is there no check box to enable 64-bit support? Is it on by default, or does this operating system just not support this feature at all? With how slow it runs it would be my guess that it only runs in 32-bit mode. All the major operating systems — Windows, Mac, and Linux — support 64-bit. I find this neglect of 64-bit to be unnerving and amateur. Let's hope QNX 6.4 acts like it was made in the 21st century when it's released.

I don't know what the QNX engineers are doing, but each new version of QNX uses a lot more memory than its predecessor. For instance, QNX 6.2 on a 1 GHz Pentium III system was taking about 96 MB out of my 1 GB of RAM; QNX 6.3 on my dual Pentium 4 system is grabbing about 412 MB of my 4 gigs of memory. What gives? This is at startup, before I've even loaded any programs. This is a huge use of resources for no discernible benefit — in other words, a waste.

Networking is a nightmare. Aside from the horrible graphical interface for network configuration, speed is an issue. It seems to crawl at only a fraction of what it should be, and I have no doubts Windows would be faster on the same hardware. Perhaps it's limited driver support, and QNX only has generic drivers for all but a few choice chipsets. Maybe I'd be better off running a BSD TCP/IP stack. All I know is that I'm using a 10/100BaseT ethernet card and seeing little better than 56k speeds.

All I want to say is that QNX had better get its ass in gear if it wants a piece of the real commercial market. Why bother releasing an operating system that's only going to piss people off? I honestly don't know why I bother retrying it every release and I'm already boxing up this new PC to return it and save my money and I imagine a lot of other folks feel the same on this topic. Here's to hoping folks are still interested when QNX 6.4 is released in another couple years and that it played a serious game of catch-up in the meantime.

QNX Multi-Processor Problems

I'm at wit's end here, folks, and I could really use some advice. My QNX install's performance is vexing me and I can't figure out how to resolve the issue. At work I'm running some extremely powerful big iron and grew sick of Windows. Our IT staff gave me the go-ahead to switch operating systems since I do embedded development not tied to the Windows OS, so I made the leap to QNX 6.2.1. Before I go on, let me share my system's specs:

• 4x 3.4 GHz Pentium 4 Extreme Edition w/ 2MB L2 cache
• 4 GB (4x1 GB) PC3200 DDR SDRAM
• 300 GB 7200RPM SATA Maxtor 6B300SD HDD

After having read about how efficient the Neutrino kernel was, I was sold. I had QNX on my system within an hour and rebooted into root. At first I was pleased with the interface and bundled apps, but I noticed something that unnerved me.

I first suspected that QNX was only using one of my four processors when I took off my case cover to do a routine dusting. Only one of the CPU heatsinks was hot (very hot, actually) while the other three were only warm to the touch. Running the system profiler program confirmed that only one CPU was being recognized. Under Windows XP all four chips had been in use and I could confirm this by feeling the heatsinks as well as viewing the task manager program. After reading that QNX supported multi-processor configurations, I was stoked. Now here I am running a uniprocessor system because of QNX. What gives?

I upgraded to QNX 6.3 but this didn't make a difference at all. (I'll be going back to 6.2.1 anyway since my thirty days with 6.3 are almost up.) My system's supposed to be fast and I have three blazing processors just waiting to be put to work. For now, they just sit idle and useless. This problem has to be a configuration option somewhere, specifically to do with SMP support. Can anyone throw some ideas my way?

Thank you.