Slashdot Mirror
QNX RTP Running on iPaq
An anonymous reader sends in: "iPaq just got new gracious looks. QNX microkernel and the gracious Photon micro GUI did wonders to iPaq. Get a sneak preview here. If you are in Boston next week, be sure to drop by Embedded Systems Boston to try your hands at the qPaq... ;)"
Your laughter is borne out of ignorance. Everybody publishes OS times for their OS when running in kernel mode only (which offers zero protection from processes run amok). But CE and EPOC don't run in that mode--you can't on these platforms since they're open and could be running malicious code.
To wit, look at QNX (http://www.qnx.com/products/os/qnxrtos.html#Perfo rmance) and On Time
(http://www.on-time.com/index.html?page=rtk45.htm) . Great numbers, but only
for kernel mode operation.
For protected systems using the MMU, it seems all the big players don't publish numbers. Why? Because this is a tough environment and the numbers look like shit. QNX offers nothing on their site about their Neutrino product performance. Neither do Mentor or Wind River.
Even the RT Linux folks are flaky here. http://www.zentropix.com/support/document/helpdox/ rtai.pdf claims they can
deliver a 4 uS average interrupt response time with 13 uS of jitter,
resulting in 17 uS worst case interrupt response time. This is on a 233 MHz
Pentium II.
Microsoft are claiming 7.5 uS worst case ISR latency on a 90 MHz Pentium II for CE (http://msdn.microsoft.com/library/techart/real_pe rf.htm). We're
seeing similar numbers on a StrongARM platform at a similar clock.
Clearly, CE is probably on par with the QNX/PSOS/VRTX crowd.
So, until Symbian actually publish some numbers on their interrupt performance, we can assume that, like code size, they are merely FUD'ing the industry.
As for the topic at hand, however, it's wonderful to see something like QNX running on iPac, maybe make one worth getting after all ;)
you can pay me to put cool stuff together for you i will set up linux or do all that 'hard' stuff to get cool stuff to work so you dont have to actually know or care how the technology works
This must be Thursday, I never could get the hang of Thursdays.
Since we are talking about personal preference it would probably be a good idea for you to scatter a few IMHO's here and there in your response. ;)
Your little story is very cute but it is not very concrete as a reason against the GPL. All that your example demonstrates is that companies should be more forthcoming with their specifications.
It's all well and good that QNX was able to afford the cost of paying their engineers to manufacture drivers for their OS. If these drivers are as 'rocking' as you make it seem wouldn't it benefit more people if they were made available to the general public?
It seems to me that the closed-source method you propose results in large amounts of duplicated effort. This is neither cost effective nor efficient at producing the most optimal drivers.
To paraphrase your last sentence:
One must NOT confuse open-source and the free software philosophy as they are two different things.