Date: Thu, 11 Sep 1997 11:54:56 -0500 (CDT) From: "Lee Crites (AEI)" <leec@adam.adonai.net> To: Don Yuniskis <dgy@rtd.com> Cc: luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <Pine.BSF.3.95.970911113318.22949B-100000@adam.adonai.net> In-Reply-To: <199709111343.GAA29545@seagull.rtd.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Sep 1997, Don Yuniskis wrote: =>In the words of the world-renowned author, Lee Crites: =>> On Tue, 9 Sep 1997, Luigi Rizzo wrote: =>> =>> Can someone give a code snippet of the BEST way of running a 1000HZ for =>> =>> loop under freebsd, without consuming massive amounts of cpu time. =>> => =>> =>one way I can think of is to build a kernel with HZ=1000 (or higher). =>> =>Make your process run at high priority, wake up at every tick (through =>> =>setitimer or usleep etc.) do its task and go back to sleep. =>> =>> I will start off with a wide-open disclaimer: I have not as of =>> yet ported *ANY* of my real-time code to fbsd. I have not as of =>> yet tried *ANY* real-time programming on my fbsd box. I can =>> barely say I have tinkered around with it. =>> =>> With that said, I am interested in this subject because I *WILL* =>> be porting my real-time code here and I *WILL* be doing some =>> hard-real-time development on my fbsd box. =>> =>> According to Stevens (et al), hard real-time programming (which =>> is what 1ms timing is) is not reliably possible on un*x. Having => =>(sigh) Yet another misinformed "real-time" definition. Real time =>has nothing to do with the rate (i.e. frequency) of events nor =>the time required to determine a valid result. Rather, RT =>reflects the value function associated with the availability of =>the answer -- i.e. the timeliness of the answer is part of the =>*correctness* of the answer. While you are correct -- that hard-real-time programming involves the timliness of the answer, you are incorrect that this is a 'misinformed' definition. You cannot design a hard-real-time system with timings that exceed certain limits. There is a difference between the term 'hard-real-time' and the term 'timing'. And, generally speaking, hard-real-time systems require timing which has a granularity of better than 1ms, thus the common statement which I made above. While I was somewhat guilty of mixing metaphores, so to speak, the two issues are different. =>Most actual applications are SRT -- though often (wrongly) implemented =>as HRT. This is certainly correct. =>The biggest problem in any non real-time OS is the fact that none of the =>OS's services have typically been designed with any degree of =>determinism in mind. Even if I'm the only active process, how long =>will I *have* to wait for an I/O operation to be completed? Will =>all malloc()s return a result in some specific time interval? =>What sort of overhead is associated with the interrupt system =>(i.e. the "service" that the OS provides to handle my IRQ's). These issues are true of many os's, even some of the rtos's. The thing is being able to adequately account for the overhead, and any changes to it (the overhead) if/when it occurs. So, I'll step back and say it another way... In my career as a systems programmer, I have developed many real-time systems, some soft and some hard. My last system was a hard-real-time system which controlled a state of the art sonar system (I would assume most people would agree that processing the sound waves from a set of microphones as hard-real-time -- once the sound is gone, it's gone). In doing these real-time applications, I have developed some timing classes which have been able to keep me on-track. They are, or attempt to be, anyway, accurate to a degree where 1ms accuracy (the original request) was very possible. I have not ported them to my fbsd system as of yet. Right now they run (read: have been used on) on aix, sun, hp, ultrix, and osf. If/when I get it running on my fbsd system (which is going to be soon, since I am using them in an upcoming book), I can make them available on my web site. Until then, if you have questions on how it is working, I'll be more than happy to answer them. Also, having said this much, I assume the individuals who know about the latency issues and deterministic nature of the os internals are reading these messages (probably with some mild humor), and can answer questions on the suitability of fbsd to real-time programming. That being the case, I would hope they would make themselves known. =>All IMHO, of course. Ditto... Lee
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970911113318.22949B-100000>