Date: Thu, 11 Sep 1997 10:13:51 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: leec@adam.adonai.net (Lee Crites) Cc: dgy@rtd.com, luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <199709111713.KAA12948@seagull.rtd.com> In-Reply-To: <Pine.BSF.3.95.970911113318.22949B-100000@adam.adonai.net> from Lee Crites at "Sep 11, 97 11:54:56 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In the words of the world-renowned author, Lee Crites: > 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 No... *any* real-time programming involves time in the "correctness" of the answer. The difference between HRT and SRT lies solely in the shape of the value function at the t=deadline. > 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'. Nonsense! The magnitude of the times involved is totally irrelevant to whether a system is RT or not! An application running at 10KHz can be *non* realtime while one running at 0.000000000001Hz *can* be realtime! (for example: a spacecraft on it's way out of the solar system with a "deadline" years in the future!) > 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. No! This is the *biggest* fallacy in the real-time issue! The actual times involved are not important to the definition. I can design a bar-code reader that has to react to events at 10Khz on a 2MHz processor and, in *one* application, this is HRT while in another it might be SRT or not even real-time, at all. Likewise, running a digital filter on a data stream at 100KHz, etc. It's not the fact that it's "1mS" or "10uS" that makes something "real-time" (that's how folks always confuse "real-fast" with "real-time") but, rather, the *consequences* of the timeliness of the algorithm. > =>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 Yes. I contend that most RTOS's are simply lean MTOS's with fast context switches and *not* truly deterministic. > 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). Yes, but one could simply *capture* the echos and process them at your leisure in a *non* real-time environment (subject, of course, to the needs of the "analyst"). I had to do this with radar echoes in the mid 70's. On the other hand, I have a current application that controls 75 discrete processes at 100Hz (the *entire* process being controlled lasts 10ms and 75 of them are running concurrently. You *can't* deal with the data after the fact, etc.) I tried to raise this issue to (hopefully) get the original querant to rethink whether "real fast" was the issue or "real time"... --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709111713.KAA12948>