This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Clock/interrupt latency


> > Hi,
> > 
> > I have a question regarding the clock/interrupt latency (on a 
> > MPC823e). When i run the tm_basic test then i get a very high 
> > variation in the measured times as you can see below.
> > 
> > If i look in the realtime characterization section in the 
> user manual 
> > then i find a variation of 3 to 5 times between maximun and 
> average to 
> > be normal, not as much as my measure.
> > 
> > ---- tm_basic diag------
> >     4.75    3.84  158.72    0.00            Clock/interrupt latency
> >     5.32    3.84   12.16    0.00            Clock DSR latency
> > ---- tm_basic ------
> > 
> > I tried to define diag_printf as printf and then i got the below 
> > measurements. How come that diag_printf has that effect on 
> my measure?
> > 
> > ---- tm_basic printf ------
> >    4.75    3.84    8.96    0.00            Clock/interrupt latency
> >    5.20    3.52   11.84    0.00            Clock DSR latency
> > ---- tm_basic ------
> 
> diag_printf uses a very simple serial driver which will work 
> even under the worst conditions of a very limited system 
> which is currently crashing etc.... To achieve this its very 
> simple, polled and with interrupts disabled. Having 
> interrupts disabled will thus affect interrupt latency. It 
> looks like tm_basic is for some reason printing while making 
> measurements.
> 
> How are you running tm_basic? With gdb? dbg over ethernet? Or 
> something simple like using redboot to load it into RAM and then go?
> 
>       Andrew

I know that diag_printf is a simple driver but since it is used as
default in tm_basic then i assume that no printing is done during the
measurements. As i understand the MPC then the decrementer isnt
maskable, which means that it cannot be put on hold (pending) so why
does one interrupt (max time) takes that long time. Even if diag_printf
disables all interrupt then i think that we will serve the decrementer
interrupt, am i wrong?

I am running eCos from RAM using an ICE debugger through a BDM
interface.

Regards, Daniel

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]