Path: utzoo!attcan!uunet!crdgw1!ge-dab!sunny!harrison From: harrison@sunny.DAB.GE.COM (Gregory Harrison) Newsgroups: comp.realtime Subject: Re: Non-determinism not "bad", per se. (Was: What is "real-time" really?) Message-ID: <3830@ge-dab.GE.COM> Date: 15 Mar 90 20:07:30 GMT References: <98692@linus.UUCP> <1990Feb24.195542.21454@newcastle.ac.uk> <53174@sgi.sgi.com> <1208@tobor.cs.utexas.edu> Sender: news@ge-dab.GE.COM Reply-To: harrison@sunny.UUCP (Gregory Harrison) Organization: GE Simulation & Control Systems Dept., Daytona Beach, FL Lines: 31 In article <1208@tobor.cs.utexas.edu> mok@cs.utexas.edu (Al Mok) writes: > > > There are two steps in applying the deterministic/predictable approach. > etc. Thank you for devoting the time to communicate from your expertise, and thanks to all for the same reason. I am working on a real time system, and the information you all have provided is aiding me tremendously. I have learned many things from you all. I am currently using the time-frame approach toward sheduling real time flow. I know that a few of my operations take longer than others but I want to maintain synchronization on a 200 msec frame time. Inside this frame is 10 runs of my nonlinear, three integrator simulator, plus I/O. It responds to external stimulii, and hopefully provides an accurate simulation. Frame overflow exception could be handled better, now that you mention it. Currently I let the overflowing frame bump into the next frame, and eat up its free time, but your posting leads me to investigate further in order to perform some kind of self-altering algorithm that prevents the frame overflow exception from occuring again, or at least ensuring that real time execution is not glitched. The frame overflow exception may occur, but the system should get back into sync with the REAL TIME at the earliest possible opportunity. Thank you all for your info, and for adding legitimacy and discipline to my efforts. Greg Harrison (My opinions are not intended to express those of my employer)