Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!phaedrus.kralizec.net.au!news.mel.aone.net.au!grumpy.fl.net.au!news.webspan.net!www.nntp.primenet.com!nntp.primenet.com!news.sprintlink.net!news-peer.sprintlink.net!uunet!in2.uu.net!204.191.213.61!ott.istar!istar.net!gateway.qnx.com!not-for-mail From: doug@qnx.com (Doug Santry) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Embedded FreeBSD Date: 20 Jan 1997 12:06:11 -0500 Organization: QNX Software Systems Lines: 95 Message-ID: <5c08m3$dvk@qnx.com> References: <32B744C0.2DA9@wdc.net> <32DA62A7.A91@onramp.net> <5be62a$14b@qnx.com> <5bqs4v$oar@uriah.heep.sax.de> NNTP-Posting-Host: qnx.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:34338 In article <5bqs4v$oar@uriah.heep.sax.de>, J Wunsch <joerg_wunsch@uriah.heep.sax.de> wrote: >doug@qnx.com (Doug Santry) wrote: > ^^^^^^^ > >> You should try QNX. > >Ah. :-) hehe. >> But you can't get around the fact that FreeBSD can spend lots of time >> in the kernel which no amount of scheduler tuning can fix. The kernel >> is not premptable... > >Of course, Unix ain't a real-time OS. OTOH, with today's ever faster >CPUs, the question is whether one really needs a real-time OS, or >whether a (basically) timesharing OS is _effectively_ doing the same. Depends on your application. Some people *need* our hard response times. Not everybody ofcourse. Right tool for the job is my motto. >The difference is, of course, that in a timesharing system, you can't >have a _guarantee_ for any timing. It depends from the desired task some folks *need* that guarantee. >whether this is acceptable (or whether you can work around that >problem by putting time-critical parts into a device driver, since the >interrupt routines _can_ preempt other kernel activity) or not. I The kernel is riddled with splhigh() calls. I wouldn't trust a device that needs attention in under 2 microseconds on a Unix system. QNX can guarantee it on a 200 MHz pentium. That is the worst case interrupt latency. >love to draw an analogy to the Token Ring vs. Ethernet principles: >while with Token Ring, you get guaranteed response times, you're >paying much more for it (hardware and overhead), and it turns out that >Ethernet can basically get you up & running as well, despite of it >being based on a chaotic principle. Chaos is in fact predictable, as >we have learnt in the past. Ofcourse, if the network is super busy you spend a great deal of time losing packets on ethernet. It is well suited for some things and not others. Right tool for the job. >Get me right, i don't mind QNX. However, i also realize (and see my >.sig for this :) that many people working in the embedded area are >much happier to also know they have the kernel source, so they can >fiddle whatever part they need to tweak. Even if you don't need this >in the end -- it usually gives you a much warmer feeling to begin >with. We find our customers who are building embedded systems that they choose our product for 2 major reasons. a) Spend their time building their application, not the OS. b) QNX is *very* scalable. Everything from filesystems to the mouse driver is an ordinary user process that can stopped and started at will. Customers can simply run the 32k kernel and depending on their needs add features to suit their application. If you are making a product which you plan to sell by the thousand, then you can save tons of $$$ with a small memory footprint. I can't see a Unix being effective in 50k. >Hint, hint... maybe QNX should also sell the kernel source to its >customers. Of course, this only makes sense if you don't think you >can really sell source code, i.e. sell everything for the same price >as you do now. Nobody is willing to pay N thousand dollars ``just in They are actaully. When you are building the control system for a X-ray machine or a nuclear reactor you want it done right, not cheap. >case''. I think going this route might really improve your marketing >chances. Don't argument that people might steal your valuable >technology. Everybody who ever tried to `port' a simple device driver >from Linux to BSD knows that even those systems are already different >enough to make this a very time-consuming task. So `stealing' >something from QNX is certainly way out of the question -- and i >didn't ask you to release that source code without an NDA either. Geez, you went and got your flame proof out a little early didn't ya? :-) We don't distribute our source because our customers don't need it. They are good at building applications, we are good at building the OS. If there is a problem, they pick up the phone and talk to the guy that wrote it instead of wasting time finding somebody else's bugs. Don't get me wrong either. I love Unix. I have made contributions to the the FreeBSD kernel. But there are areas where Unix is simply not as good as QNX, they are real-time applications and embedded systems. QNX quite simply kicks butt in those areas. DJS