This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Clock/interrupt latency
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: Daniel Lidsten <Daniel dot Lidsten at combitechsystems dot com>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 28 Aug 2003 11:46:46 +0200
- Subject: Re: [ECOS] Clock/interrupt latency
- References: <004B1D7A5257174C9044A1B7BD0E60EDA65E96@ratatosk.combitechsystems.com>
On Thu, Aug 28, 2003 at 11:32:11AM +0200, 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
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss