[ECOS] Re: Hard realtime issue in eCos

[Kevin S. Martin]

>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