stein@dhw68k.cts.com (Rick 'Transputer' Stein) (03/15/90)
In article <53078@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >Non-deterministic means that you cannot (even theoretically) predict >the exact sequence of system states; it does *not* mean that you cannot >predict the behavior of output variables within a useful epsilon (or in >some cases even exactly) or that the output variables will necessarily >be wrong. I generally agree. I once wrote a multicomputer simulation where the message passing was hosed-up. The sim started to converge, but all of a sudden, it bounced around, started to converge, bounced around, etc... And this was just a simple numerical solution to a PDE with real clean boundary conditions. It was like a highly nonlinear (e.g., chaotic) system. You know, strange attractors and the like. That's what I call non-deterministic: failure of a simulation to provide the identical answers for a fixed set of input conditions each time you run it. That's what you get when your message-passing is hosedup. > >If you have parallel processors observing the same external inputs, you must >anticipate and provide for the fact that they will *not* always detect external >transitions at the same system clock time. If these inputs cause interrupts, Ah! My favorite subject, parallel systems with clocks. Can you imagine running a real-time multicomputer simulation. I'm talking about 64K separate processors, each with its own unique clock. How do you synchronize all these cpus to within, say 64 usecs? Kinda' like lining up 64K people with different watches and asking them what time is it? You'll need "split-second" synchronization for real-time multicomputers. But I think Warnock is talking about the shared-memory ghettoblaster variety, and these sucker all derive strobes from a single source (chicken-shit if you ask me :-}). >Of course, nobody said designing such systems to be correct was easy... ;-} Its a bitch, trust me! >-Rob --rick -- Richard M. Stein (aka, Rick 'Transputer' Stein) Sole proprietor of Rick's Software Toxic Waste Dump and Kitty Litter Co. "You build 'em, we bury 'em." uucp: ...{spsd, zardoz, felix}!dhw68k!stein
harrison@sunny.DAB.GE.COM (Gregory Harrison) (03/16/90)
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)