This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Hard realtime issue in eCos
- From: "Kevin S. Martin" <ksmartin at fnal dot gov>
- To: ecos-discuss at sources dot redhat dot com
- Date: Wed, 25 Jan 2006 11:00:41 -0600
- Subject: [ECOS] Re: Hard realtime issue in eCos
Well, that's certainly very noticable!
You say you use 50% of CPU. Is anything else happening on the system
normally?
Is it possible to run this application in an artificial environment (say,
no network) on a test box, to see whether the glitch still occurs?
I have two systems, one running on a test bench connected to a switched Ethernet port
and the other out in the field (in the operational environment) hooked to a shared Ethernet.
The test bench system does not have the problem only the field system does.
I am assuming you mean "without". Have you tried with no network cable?
I understand that the application may be useless without it, but if you were
to do long runs during which you recorded latencies only over a period of
time, without the network, you could see whether the network can be ruled
out as a source of error; if the glitch happens with no network, then it's
probably not the network.
Yes, sorry about that, "without" is correct.
Since my test bench system doesn't have the problem and it is connected to the network
I have not bothered to test with no network cable attached.
It is probably possible that such a thing could happen, but I'd guess that
you could generate it. Is your network switched? Do you have an easy way
to, say, interpose another machine which logs absolutely every packet on the
wire that hits your machine, with close enough timing that you could compare?
Interesting idea. I'll have to look into this.
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?
It should be theoretically possible.
Does anyone out there know if there is a practical way to do this?
Is there any other possible cause for this "glitch" that any one can
think of?
1. Garbage collection. I don't know that there should be any, but I know
some C++ implementations use it for some things.
2. Other hardware. Do you have any local storage devices? For instance,
if you had a disk, a disk write could occasionally hang for a couple of mSec.
1. I don't do garbage collection in my realtime ISR code. Does the eCos kernel do
garbage collection in the background? I don't think so. Even if it did, would
interrupts be turned off while it did it?
2. I do have a flash disk. But I do not write to the flash disk from within my
realtime ISR code. If some eCos thread wrote to the flash disk could this cause
interrupts to be turned off for 2-4mSecs?
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