Re: Anyone using Ada with Real-Time Linux?

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On 27 Nov 2001 09:19:03 +0000, Simon Wright <simon.j.wright@amsjv.com>
wrote:

>dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
>
>> On Sun, 25 Nov 2001 20:50:12 GMT, "DuckE" <nospam_steved94@home.com>
>> wrote:
>> 
>> >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.
>> 
>> A question to wise men. Is above achievable under "normal" Linux,
>> provided that only Ada application is running and tasks are
>> dispatched by Ada RTS? Will hard disk I/O be a problem? TCP/IP
>> socket I/O?
>
>The main problem is the 1ms period. Under Linux 2.2 you can set the
>kernel jiffy down to 0.5 ms by altering HZ to 2000 in asm/param.h,
>alter linux/kernel/sched.c:sys_nanosleep to remove the busy-wait on
>short delay requests up to 2 ms, and rebuild the kernel. You really
>ought to rebuild the standard library too, since Linux doesn't have a
>complete sysconf, but it seems to work pretty well (we've not used
>this in production work yet, just in a testbed).
>
>The reason for setting HZ to 2000 is that GNAT uses nanosleep to
>implement delay, and nanosleep delays for 1 more jiffy than you
>expected so that it can be sure to delay for at least the time
>requested.
>
>The final trick is to run your tasking Ada program as root. This puts
>it into the SCHED_FIFO real-time dispatching class (to borrow a
>Solaris-ism). There is a way to get SCHED_RR instead (under 3.14a1,
>anyway; I expect it's one of the configuration pragmas if it's
>anything like Solaris).

Thank you for this information.

[We are considering which OS platform to choose for an embedded "soft"
real-time system. Our requirements are: 5 ms for the DAQ & control
task and almost "no matter" for the TCP/IP tasks]

>Whether this would fit the requirement I don't know; there might be
>unavoidable delays, as Dmitry says.

I heard that the Linux kernel is (or will be) preemptive. If so, there
[I suppose] should be no big problem with I/O?

Regards,
Dmitry Kazakov