Date: Wed, 10 Sep 1997 15:17:02 -0500 (CDT) From: "Lee Crites (AEI)" <leec@adam.adonai.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: "Jamil J. Weatherbee" <jamil@counterintelligence.ml.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <Pine.BSF.3.95.970910145537.9159A-100000@adam.adonai.net> In-Reply-To: <199709091847.UAA19872@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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, 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. In fact, it was sockets which caused me to have to abandon the timer interrupt concept. Yes, I could build the incoming packet and/or split the outgoing packet properly. The problem is some versions of un*x do not handle the stream pointers properly. In fact, aix it doesn't handle them at all -- it just leaves them where they were. I have no idea what fbsd would do, but I will bet dollars to donut holes the person(s) who *know* the answer are on this list! Once I have the code working on my fbsd box, it will be posted on my web page for y'all to peruse. Lee
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970910145537.9159A-100000>