Date: Thu, 11 Sep 1997 13:04:58 -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.970911124503.22949E-100000@adam.adonai.net> In-Reply-To: <199709111713.KAA12948@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: =>> 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. 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. =>> 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. The original request was for some code which could handle 1/1,000th of a second timings. I didn't care if he was working on a real-time or real-fast system. I only brought up the hard-real-time issue as an explaination of what my timing class was currently working in, and that it was performing in an environment needing 1/1,000,000th of a second accuracy. Lee
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970911124503.22949E-100000>