Date: Thu, 11 Sep 1997 06:43:26 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: leec@adam.adonai.net (Lee Crites) Cc: luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <199709111343.GAA29545@seagull.rtd.com> In-Reply-To: <Pine.BSF.3.95.970910145537.9159A-100000@adam.adonai.net> from Lee Crites at "Sep 10, 97 03:17:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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. In a HARD real-time (HRT) system, the value function abruptly goes to -infinity at the instant in time coinciding with the task's "deadline". In other words, having "an answer" at any time *after* the deadline is *worthless*. In a SOFT real-time system (SRT), the value function merely *decreases* at the task's deadline. In other words, the value of an "answer" diminishes the further in time you go beyond the deadline. Most actual applications are SRT -- though often (wrongly) implemented as HRT. > said that, I have a nice hard-real-time timer class I developed > which is being used as the basis for controlling sonar systems > that runs in the microseconds (with a +/- 130 microsecond > accuracy) on several platforms (next platform is, you guessed it, Yeah, and anyone who's had to implement a software UART at 9600 baud has done similar :> Again, speed isn't the important part. Nor is low latency. Decoding barcodes from raw video, on the other hand, is *quite* challenging! :> Consider the sio handler -- all it *really* has to guarantee is that the processor gets around to servicing an interrupt *before* the receive FIFO in the UART (which may only be two characters deep) overflows. So, a latency of almost a whole character time is acceptable. *But*, once that deadline is passed, the "value" of servicing the interrupt (for that particular character) drops to less than nothing -- the character is gone and can't be recovered. On the other hand, *processing* the received character can be done at a *very* leisurely rate (subject to the user's level of patience). And, in some cases, even the dropped characters can be accomodated (e.g., a PPP link vs. a direct shell) > fbsd). It is self tuning in that it takes into account it's own > overhead and readjusts future timings based on that. > > Anyway... > > The big question is what are you doing in the loop? > > I had a millisecond heart-beat timer which sent a timer interrupt > to my process (which seems to be what you are asking for). Keep > in mind that when the timer interrupt hits, all of your blocked > i/o gets triggered as well. This is probably what you want -- > otherwise you would have no need for the interrupt. And, of > course, you will have to check the return code (most likely -1) > and errno (EINTR or EAGAIN ?!?) with each blocked read -- > including sockets. 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). Since you can't get hard and fast numbers on these services designing *any* sort of RT system is problematic. Now, if you just think you have a "fast application", then buy a faster processor, etc. But, even if your code is running on a rocket headed for mars (i.e. *years* available to compute certain functions), you need to be able to *quantify* the environment your code is going to be subjected to... All IMHO, of course. --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709111343.GAA29545>