This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Clock/interrupt latency
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Daniel Lidsten <Daniel dot Lidsten at combitechsystems dot com>
- Cc: Andrew Lunn <andrew dot lunn at ascom dot ch>,eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 28 Aug 2003 04:44:19 -0600
- Subject: RE: [ECOS] Clock/interrupt latency
- Organization: MLB Associates
- References: <004B1D7A5257174C9044A1B7BD0E60ED232DAE@ratatosk.combitechsystems.com>
On Thu, 2003-08-28 at 03:55, Daniel Lidsten wrote:
> > > 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?
>
Sorry, yes. On the PowerPC, decrementer interrupts can only happen
when interrupts (there is only one "master enable") are masked.
'tm_basic' is designed to take this into account, by taking time
measurements only when printing is not taking place.
> I am running eCos from RAM using an ICE debugger through a BDM
> interface.
>
> Regards, Daniel
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss