Ada Interrupt Rate Survey

Ada Interrupt Rate Survey

[Dave Hawk]

   I am interested in learning what the current "state of the art" is
for feasible interrupt response rates for Ada based systems on 68xxx 
and 80x86 microprocessors.  I am interrested in Ada systems which run
directly on the hardware itself with an Ada vendor's run time (no 
intermediate OS such as Unix or OS/2).  If you have knowledge of an 
Ada system using interrupts on one of these microprocessors could you 
please post a brief response to this basenote listing:
    1.) Approximate interrupt rate,
    2.) Processor and clock speed,
    3.) Name of compiler vendor,
    4.) A comment on margin (i.e. are you near the limits of
            what the system can do, or do you still have
            processor time to burn?)

Thanks,
David Hawk
Hewlett-Packard Co.
Avondale, Pa.

Re: Ada Interrupt Rate Survey

[Tom Griest]

Regarding David Hawks posting on Interrupt Rates for Ada programs:

>>    1.) Approximate interrupt rate,

            The system I am currently working on has several different
            interrupts, the highest rate is 500Hz.  The implementation
            uses "fast" interrupt entries in that the compiler essentially
            generates code to save/restore registers, places this around
            your Ada "accept" statement, and vectors directly to this
            code.  Thus, the interrupt rate is the same as for assembly
            language, and incurs only the overhead of processor interrupt
            handling and register preservation.  In our case this is about
            10 usec. round-trip.  Latency is primarily determined by how
            long interrupts are disabled during runtime calls and are
            typically held very short (under 20usec) but I don't have a 
            number for the worst case possibility.

            The maximum interrupt rate is therefore limited by what
            is done during the interrupt.  If an entry call is made during
            the interrupt, it is treated in a special way and is effectively
            deferred until after the interrupt is completed.  Such a call
            is believed to have low overhead (we have not measured it
            recently, but we recall numbers well under 100usec).  Our
            application must process interrupts very frequently in order
            to prevent the loss of data.  Less frequently it wakes up
            another task to perform extended processing on the data received.
            
 >>   2.) Processor and clock speed,

            We are using a 16MHz 80386, currently running in "Real-Mode".
            Accesses within 4KB memory pages incur no wait states, switching
            pages forces a wait state.

>>    3.) Name of compiler vendor,

            DDC-I Inc.

>>    4.) A comment on margin (i.e. are you near the limits of
>>            what the system can do, or do you still have
>>            processor time to burn?)

            Our application is very close to margin, and to a limited extent
            is designed to degrade gracefully as it exceeds the available
            CPU cycles.  (The processing load is highly dependent on the
            number of targets and rockets that require tracking, what
            flight phase the rockets are in, and even computations that
            vary depending on parameters like square roots performed in
            software.)  Our system has the ability to become distributed
            to obtain additional processing resources, but this characteristic
            has little or no impact on the way in which interrupts are
            processed.  However it is used to offload rocket trajectory 
            calculations, graphics processing, and various other operations 
            and therefore can provide isolation from the activities with 
            high interrupt rates.

            The system is strictly real-time and when rocket calculation
            deadlines are missed, it degrades very rapidly.  In particular,
            the processor closes the servo loop between the rocket attitude
            data and the trajectory planner of the rocket to intercept the
            target.  These equations are based on accelerations computed on
            presumed fixed intervals between reports.  If the intervals
            become aperiodic, the rocket stability suffers substantially and
            the hit rate is dramatically reduced.  Also, if the update 
            deadlines are missed during the final ingress phase and targets
            change acceleration then the extrapolated positions will be 
            incorrect resulting in missed targets.
            
Tom Griest
LabTek Corporation
griest@ajpo.sei.cmu.edu