* Ada Interrupt Rate Survey
@ 1990-01-05 14:59 Dave Hawk
1990-01-09 15:59 ` Tom Griest
0 siblings, 1 reply; 2+ messages in thread
From: Dave Hawk @ 1990-01-05 14:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Ada Interrupt Rate Survey
1990-01-05 14:59 Ada Interrupt Rate Survey Dave Hawk
@ 1990-01-09 15:59 ` Tom Griest
0 siblings, 0 replies; 2+ messages in thread
From: Tom Griest @ 1990-01-09 15:59 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1990-01-09 15:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1990-01-05 14:59 Ada Interrupt Rate Survey Dave Hawk
1990-01-09 15:59 ` Tom Griest
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox