yodaiken@fsmlabs.com wrote:
>
> On Wed, Jul 19, 2000 at 03:47:01PM -0400, David Mansfield wrote:
> > David Balazic wrote:
> > >
> > > The first sentence my professor maid on the real time computing
> > > course was :
> > >
> > > "A common misconception : Real-time computing is fast computing."
>
> This is the standard lecture, but don't take it too far. You can control
> a robot with deterministic latecnies under 50 usecs, but not with
> deterministic latencies of 10 minutes.
>
> > To summarize, I agree that the 'audio people' have a real-time
> > requirement. I claim that the kernel already has real-time
> > requirements. I also claim that any real-time system is only a
> > probability curve of making the deadline, and that the 'audio people'
> > only want to shift this curve to make the deadlines they are looking for
> > fall into the probability of failure they find acceptible.
>
> You understate the difficulties by using this form of argument. I'd
> like my 1992 V4 Ford Ranger Pickup to fly at Mach 3 at 35,000 feet.
> The truck already leaves the ground for short periods
> if I drive over bumps. So it already has an aircraft requirement and
> I only want to shift the flight curve to a level I find acceptable.
> Should be simple, no?
>
The US military's solution to your problem was solved with the
successful rolling out of the F4 Fantom fighter. The plane was
essentially a large block of metal, with a few advantagously aerodynamic
surfaces, and big f****** engines. If you had engine trouble in a Fantom
...you had trouble. By this method of doing things, all we need to do,
is simply have everyone run dual proc. G4's and PPC linux ....umm no.
Nothing agains the G4's (I'd love to have one) but this is not a
solution. Something more graceful must be come up with. I don't think
that "Real-Time" is the answer, and besides, I'm not sure that would
help beyond a certain point. After all, CPU's are truely not the
limiting factor in most PC's these days, its the bus, and the things
attached. Sure, some help is on the way with DDR chipsets for AMD cpu's,
but what about storage? Our current hard drives are not the solution.
More data must be able to be passed faster, and somewhere in there, we
have to leave a way for the system (and software!) to respond to
requests from the user even while in the midst of this rush. Efficient
prioritizing, and resource management is the answer to this, not
"Real-Time". Unfortunately, as easy as it is to say this, it will be
much harder to make a reality.
-- Drew Sanford Systems Administrator Planetwe.com Email: drew@planetwe.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:12 EST