From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dfedbe83126d2210 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-27 18:47:46 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news1.sttln1.wa.home.com.POSTED!not-for-mail From: "DuckE" Newsgroups: comp.lang.ada References: <8QcM7.77531$XJ4.41637211@news1.sttln1.wa.home.com> <3C03AF1C.4F9CFA81@Raytheon.com> Subject: Re: Anyone using Ada with Real-Time Linux? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Wed, 28 Nov 2001 02:47:45 GMT NNTP-Posting-Host: 24.248.45.203 X-Complaints-To: abuse@home.net X-Trace: news1.sttln1.wa.home.com 1006915665 24.248.45.203 (Tue, 27 Nov 2001 18:47:45 PST) NNTP-Posting-Date: Tue, 27 Nov 2001 18:47:45 PST Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:17076 Date: 2001-11-28T02:47:45+00:00 List-Id: "Mark Johnson" wrote in message news:3C03AF1C.4F9CFA81@Raytheon.com... > DuckE wrote: > > > I've been looking into using Ada with one of the real-time flavors of Linux. > > [snip] > > > > I have an application that acquires data at 1 msec intervals, processes the > > accumulated data and transmits a summary of the data across a network every > > 330 msec. The application is currently written in C and runs on VxWorks. > > Moving the application to a different target, still under VxWorks means > > shelling out another $30K to Wind River, plus $200 per target (at least). > > If I can come up with a less expensive choice using Ada, ths may provide an > > opportunity for a swithc. > > If you "must" sample at 1 msec, you have two alternatives... > - use a hardware timer to trigger I/O Sampling is triggered by an external input (not a clock). The signal is generated by an incremental encoder. On each encoder signal we read up to 1024 bytes of data. The maximum frequency data becomes available is 1KHz, thus the 1 msec sample rate (worst case). > - create a small data acquisition task under your choice of RTAI or RT Linux > In either case, run the rest of your application as RT_FIFO under Linux. To give > you an idea of Linux performance, I suggest... > http://pets.lineo.com/ > for some data from a year ago. Look for "worst case latencies". I was generally > able to reproduce the results they got. If you want, you can download a disk > image from... > http://www.lineo.com/download/ > and look for Atomic RTAI. Its a bootable disk w/ a kernel built w/ RTAI and > various instructions for running tests. If you want to go this way and need > support, I suggest talking with either FSM Labs or Lineo for RT Linux and RTAI > respectively. If you will roll your own - I suggest the various mailing lists > for each product. > This is certainly a valid approach, but in looking over the RTAI approach, it occurred to me that there are likely sufficient primitives available that an Ada run time library could be developed to work in the real-time environment (semaphores, threads, etc). I was wondering if this had already been done. It would certainly be a nicer solution if I could do all of the work in Ada using tasking, protected types and interrupts. > If an occasional late sample is OK (data is time stamped), then a stock Linux is > OK if you are careful. Being careful includes... > - set up your disk parameters for DMA > - stay out of low memory situations > - little or no disk I/O > - build with the kernel preempt and/or low latency patches > A few good sites for reference include... > http://www.tech9.net/rml/linux/ > http://kpreempt.sourceforge.net/ > for recent kernel preemption, cpu affinity, and some lock time patches. > http://www.uow.edu.au/~andrewm/linux/schedlat.html > http://www.linuxdj.com/audio/lad/contrib/2.4-install-notes.html > for low latency information and patches. Looking at RTAI and RTLinux it appears that having the real time layer under Linux might actually keep things simpler than having to be concerned about the behavior of stock Linux. > Its my experience that you can still get a few stinkers on the order of a > microsecond or so if you get unlucky. For our large Ada system, that isn't a > problem - our fastest rate is 80hz (12.5 msec). We use a hardware clock to stay > in sync with real time, and hardware timers to trigger DMA transfers for the few > cases where we have a hard real time requirement. > --Mark > Thank you. SteveD