This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Hard realtime issue in eCos
- From: "Kevin S. Martin" <ksmartin at fnal dot gov>
- To: ecos-discuss at sources dot redhat dot com
- Date: Tue, 24 Jan 2006 16:56:23 -0600
- Subject: [ECOS] Hard realtime issue in eCos
I'm running eCos on a i386 target (100MHz 486). My application runs at
1Khz and lasts for ~500uSec (i.e. it uses 50% of the CPU bandwidth). The
application code executes (at 1KHz) as a result of a hardware interrupt
and runs as a ISR (i.e. at interrupt level).
99.999% of the time the interrupt latencies have a range of 20-40uSec
which is fine and acceptable. However, at a rate of about once every 2-4
days there is a "glitch". I don't know what causes the "glitch" but when
it happens my application's interrupt is held off for 2-4mSec :O. This
totally breaks my realtime signal processing and causes the application
to "trip".
The only other processing going on in the system (other then kernel
processing) is the network. The system is on Ethernet. Normal network
communication to the system does not cause this problem. I have
exercised the system (via the network) up to the point of the CPU being
100% utilized with affecting my high priority realtime application.
Is it possible that on rare occasions there is a network "storm" which
causes many network interrupts, one right after the next, causing my
applications interrupt not to get handled? If so, how can I see this and
then of course stop it?
One idea that I had was to run the Ethernet driver in polled mode rather
then interrupt mode. This would prevent a network "storm" from affecting
my high priority application. Can this be done?
Is there any other possible cause for this "glitch" that any one can
think of?
Thanks,
Kevin Martin
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss