Re: [uCsimm] Hard Real time Linux

From: Ǽ (kwonsk@mutech.co.kr)
Date: Wed Feb 23 2000 - 21:13:34 EST


Hi, Jeff Bauknect

... and of cource, this mailing list might not best for
your needs about exact context switching time or relative solutions.
maybe 10 microsecond context switching is REALLY HARD for ucsimm.

Thanks
kwonsk.

----- ޽-----
: Jeff Bauknecht <jbauknecht@premisenet.com>
޴ : ucsimm@uClinux.com <ucsimm@uClinux.com>
¥: 2000 2 24 8:36
: RE: [uCsimm] Hard Real time Linux


    The problem is context switch time. With Hard real time systems it is <10 microseconds. I am trying to find out context switch times in Linux also. There will be several processors and DSP's many pegs many holes.
        -----Original Message-----
        From: owner-ucsimm@uClinux.com [mailto:owner-ucsimm@uClinux.com]On Behalf Of Tom Walsh
        Sent: Wednesday, February 23, 2000 2:58 PM
        To: ucsimm@uClinux.com
        Subject: Re: [uCsimm] Hard Real time Linux
        
        
        Jeff Bauknecht wrote:
            My company has been looking at different operating systems for our next
            product. We are probably going to have a PowerPC processor (860). The
            product is going to be a PBX. The real time extensions to Linux are getting
            better. We have one problem that is keeping Linux from being our solution.
            That is a conference bridge. A conference bridge takes several audio
            sources sums them together, averages them and sends them back out. This is
            processor intensive. It has to be hard real time. LynxOS has put out
            Bluecat, but it is only soft real time. This might be to encourage people
            to use their LynxOS for the hard real time applications. Is anyone aware
            of a solution for this? I.E Hard real time extensions for Linux?
            Thank You

            Jeff Bauknecht
            PremiseNET, Inc.

            I have been pushing Linux here at work and need help.

        
            Not all solutions have to be a 'single chip' one, nor can they be, it sounds to me that your solution is that of a multiple processor one: a processor that passes data around on the IP network and the other processor to do the heavy work of summing the voice data.

            Round pegs + square holes type of problem, like trying to do DSP with a PIC controller.

        Regards,

        TomW
          

              
            This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/

--
Tom Walsh - WN3L - Embedded Systems Consultant - tom over_at mytoys(.)com
'www.mytoys.com', 'www.openhardware.net', 'www.cyberiansoftware.com'
"Windows? No thanks, I have work to do..."
          

This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST