Date: Thu, 11 Sep 1997 12:08:54 -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: <199709111908.MAA20883@seagull.rtd.com> In-Reply-To: <Pine.BSF.3.95.970911124503.22949E-100000@adam.adonai.net> from Lee Crites at "Sep 11, 97 01:04:58 pm"
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: > =>> 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 timeliness 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 > > Calm down, Don. Take a few long breaths and clear your mind for > a moment. We are saying the same thing. No! *I* didn't put silly "1mS" numbers to in any way pertain to whether something was RT, HRT, SRT, etc. I suppose I can dig out your post and requote the literal reference you made -- I'll leave that for you to verify! > Re-read what I said above: "There is a difference between > 'hard-real-time' and the term 'timing'." > > =>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!) > > You keep confusing my statement and talking about timing. I > don't care if you have 5 billionths of a second or five billion > seconds to come up with the answer. I differentiated the two > above. *You* "quantified" RT at the 1mS/1KHz level. I merely point out that this has nothing to do with the issue. That;s the essence of the "real-fast" misconception... > =>> 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 > > They might not be important to the definition, but they are > *everything* in the process. If your timings are wrong, your > real-time system falls apart. While the definition of real-time > might not include any kind of delineation concerning time > periods, the actuality of developing a real-time system is chock > full of actual -- and real -- timing issues. You can't ignore > that. And hyperventalating over the timing issue doesn't lend > credit to your statements. Reread (carefully) my statements and then reread *yours*. Perhaps you've been a bit sloppy in what you've written vs. what you *intended* to write. But, when it ocmes to this issue, I try to be *very* precise in my language. I repeat: the actual maginitudes of times, rates or frequencies has ABSOLUTELY NOTHING to do with whether a system is RT, SRT or HRT. The sole criteria is the shape of the value function in the vicinity (and beyond) of the deadline. --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709111908.MAA20883>