QNX: The PlayBook OS

A year and a half ago RIM jumped on the opportunity to purchase an OS vendor called QNX (pronounced Que-NIX, like UNIX with a Q in front). RIM saw a growing gap between its BlackBerry OS and what Apple/Google were working on and realized it needed something new to effectively keep up with the joneses. The age old debate between build vs. buy kicked in to high gear and RIM took the route with less internal risk: acquire QNX.

QNX's Neutrino 6.5 OS is the basis of the BlackBerry Tablet OS running on the PlayBook. QNX features a very small (by modern standards) microkernel of around 100K lines of code. By comparison the modern day Linux kernel is around 14M lines of code. QNX argues that by limiting the scope of the kernel it can ensure greater stability and less vulnerability to bugs in the code. QNX is functionally a modern OS, however everything beyond the base kernel is supplied in the form of separate, self contained services. Even drivers are excluded from the microkernel.

QNX is, as a result, a very modular operating system. Additional features are added simply by bundling extra services, however for specific markets you don't incur any complexity or security penalty as unneeded services are simply turned off.

Because it's so modular, QNX has no issues being used in everything from the PlayBook to high end Cisco routers. Obviously the requirements of a tablet are very different from a router, so RIM actually implemented an updated version of QNX 6.5 into the PlayBook with some tablet specific features. The QNX team worked on improving media playback and GPU performance in QNX, features that will eventually make their way into QNX 6.6.

Another benefit of the modularity of QNX is that each service runs effectively sandboxed. A crash within a single service won't bring down the whole OS. Restarting a single crashed service can be done quickly. A small kernel should also be able to boot quicker, however the PlayBook itself has a longer boot time than Honeycomb because the entire OS image is validated using a crytographic hash on boot up. As a result of this image validation, the PlayBook will always boot into a known secure environment. Should the image validation fail, the PlayBook will typically install a previous known-good copy of the kernel stored on a separate partition.

Communication between services/processes happens via a structured messaging system. This is of course one of the benefits of a microkernel OS: inter process communication is usually quite good, because it has to be.

In QNX every task or thread has a priority. While a handful of priorities are reserved for system level events (to prevent an app from taking priority over refreshing the screen for example), everything else is defined by the caller. QNX argues that unlike in monolithic non-realtime OSes, task/thread priorities are nearly always respected here. Inevitably you'll have a number of tasks that have the same priority, and there the scheduler will just round robin between them. The one guarantee QNX offers is that any task with a higher priority will execute in accordance with that priority. This is ultimately what makes QNX a realtime OS.

Large monolithic OSes often give you the same promises, however QNX argues that they don't always hold true to them. There's always some system process that's interrupting things or a runaway task that prevents your screen from updating as quickly as you need it to. These days with hefty multi-core CPU architectures, hiding scheduling latency due to a system process interrupting something else isn't too difficult. On tablets/smartphones it's more of a problem given limited CPU resources, but ultimately it'll diminish there as well. There is arguably a power efficiency benefit here but at a high level that's a difficult thing to measure.

The QNX OS itself has been ported to everything from x86 to PowerPC. Although the PlayBook uses an ARM based OMAP 4430 today, it looks like RIM is pretty open to moving to other microarchitectures should the need arise.

File System

On the PlayBook RIM implements the latest version of the QNX file system. The setup supports 64-bit LBAs (effectively no limit on single file size given current NAND capacities) and 1K file names.

File system performance is difficult to measure at this point given that we're dealing with pretty low performance NAND as well in devices like the PlayBook.

A Functional Bezel TI's OMAP 4430
Comments Locked

77 Comments

View All Comments

  • Andrew911tt - Thursday, April 14, 2011 - link

    You have the Xoom at a price of $799 but you can get the 32 GB wifi version for $599

    http://www.amazon.com/MOTOROLA-XOOM-Android-Tablet...
  • MTN Ranger - Thursday, April 14, 2011 - link

    Excuse my off topic question.

    Anand, I notice you use Lafayette Village in your videos a lot. Do you live/work near there? We enjoy having drinks at the Village Grill and my wife loves the Upper Crust Bakery. I have taken photos there and think the architecture is great.
  • Anand Lal Shimpi - Thursday, April 14, 2011 - link

    I'm not too far from there. It's the most interesting thing that I can photograph quickly outside of my dogs playing :)

    Take care,
    Anand
  • jensend - Thursday, April 14, 2011 - link

    I'm serious- this is probably the best commercial OS out there. Of course, these days most people judge an OS mostly by its included applications and the collection of software written for it, which doesn't look so good for QNX, but as far as the actual OS is concerned QNX is extremely well designed.
  • baba264 - Friday, April 15, 2011 - link

    I would tend to agree.

    I was very impressed upon reading all the nice features that this OS has and that are still lacking in mainstream PC OS.

    The the tight kernel, the sandboxing, the thread management, the corruption protection all of it sounded real nice. Of course since it wasn't the focus of the article, many question remain, especially performance wise, still it sounded like an impressive work.
  • vision33r - Friday, April 15, 2011 - link

    Because people are used to the iPhone / iPad and App Store being the standard.

    QNX is a good OS, it is tight and lean. There won't be a fragmentation problem like Android has.

    The only problem is that RIM will restrict the device's functionality so that it cannot replace a Blackberry device and risk losing lucrative smartphone sales.
  • B3an - Friday, April 15, 2011 - link

    "You can't really hover to expose controls with a touchscreen so what you end up doing is a lot of quick tapping to try and bring up controls, change the setting you want and get back to playing the video. It's frustrating and doesn't work all of the time. None of this is RIM's fault, but now that tablets are at the point where they can start to behave like notebook/desktops web developers will have to rethink the way they build websites. "

    I'm a web designer and specialise in interactive websites and apps, but touch screens have the ability to hold this area back and make it less elegant/messy for other devices with no touch.
    The problem is not with web sites designed for non-touch devices but the need for a touch device to support hover in some way. For instance this could be done if a touch screen could detect a finger hovering over an area of the screen within say half an inch of the screen surface. That could work well if done right.

    As sites get more interactive and advanced hover controls in the UI make more and more sense. because of interface complexity rises and the need for more buttons and stuff all over the place.
    The thing with Flash is that being as it's far more capable than HTML5 for interaction (and with pretty much anything else too) is that it's Flash that is more likely to use hover controls in some form. But some HTML5 things are stating to use it, like the default skinned Chrome HTML5 video player for instance. Hover just makes perfect sense for certain things and touch screens need to fix this, not us web designers.
  • ElementFire - Friday, April 15, 2011 - link

    This is a seriously well-wrought review. I'm especially glad you dedicated an entire section to Bridge, and addressed the free tethering question. As you stated, this is huge (assuming the carriers permit it), as it's the closest thing to truly unlimited browsing data plans (for no additional charge!) as we'll get now.

    It's a pity that Android apps need to be re-signed by RIM before they'll run. It makes sense from a security perspective (you don't want malicious apps running amok on an enterprise platform), but I'd have preferred if RIM had severely limited Android VM capability and allowed all apps to *try* to run, rather than requiring re-signing; the vast majority of Android app-developers won't have the impetus to resubmit their apps to yet another platform holder.

    The last point I wanted to make was video conferencing: it's a serious letdown to only ship with point-to-point video chat (and even then, only between PlayBook owners!). If you're aiming at the enterprise, I'd expect VoIP/SIP capability and the ability to run WebEx natively. Does the PlayBook support any implementation of Java Runtime Environment?
  • name99 - Saturday, April 16, 2011 - link

    "Pretty much no smartphone or tablet we've tested is particularly speedy over WiFi. Even the Motorola Xoom, at the top of our performance chart, manages a meager 36Mbps. Part of this has to do with the fact that all of these devices are power rather than performance optimized and part of it has to do with NAND performance limitations."

    Is this not simply a reflection that none of these devices use 40MHz wide channels, they all stick to 20MHz wide channels? I'm not certain about this, but given how the numbers cluster, I would bet this is the case.
    (And, of course, none of these devices use multiple antennas for wifi.)

    The flash has nothing to do with it. iPad flash can write sustained at a little under 20MB/s (ie 160 Mbs/s) and I imagine other tablets have similar specs.

    In theory, the most power efficient way to run wifi is to do get your transmissions done as fast as possible --- in other words use 40MHz and multiple antennas and run at the maximum data rate possible. Of course this requires that the chips being used be maximally efficient in their overhead, so that essentially all power is being burned in RF transmit, not in the receivers, the decode logic and so on. It may well be that the chips supporting 40MHz, let alone MIMO, simply haven't been around for long enough to have their power usage tuned to where the 20MHz chips are.
  • tipoo - Sunday, April 17, 2011 - link

    Most routers and laptops will default to 20MHz anyways.

Log in

Don't have an account? Sign up now