Bill Huey wrote:
>
> > I don't know what a "specifically RT technique" is and I don't care
> > how its done -- if the kernel can promise to always respond to an interrupt
> > within some bound, then the kernel offers a hard realtime guarantee.
> > And, for what it's worth, my professional opinion is that this is incredibly
> > hard to do and never worth doing in a kernel that also wants to offer
> > high speed networking, files systems, and guis.
> > I'm sure Ingo will tell you that his patch is designed to make long
> > latencies _rare_ not impossible.
>
> > ---------------------------------------------------------
> > Victor Yodaiken
>
> Damn, I accidently fired off the mail without CC to the list. ;-)
>
> Then what's need is to introduce a new terms in the discussion,
> "soft realtime".
Soft real-time is also something all of you use every day.
Most telephone switches are soft real time.
They mostly react within 10 ms.
As an example see
www.erlang.org
It is a functional interpreted language designed to program that
kind of systems. (It is also used in Ericssons ATM switches)
BTW - it is really slow if you try to do standard benchmarks,
but suddenly when you have a real system. Then it is ok - and you
can easily add more processors...
/RogerL
-- Home page: http://www.norran.net/nra02596/- 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 : Fri Jul 07 2000 - 21:00:13 EST