Strange timing results
daron at nucleus.usask.ca
Fri May 19 21:25:24 UTC 2006
On 19-May-06, at 2:46 PM, Alexandre Constantino wrote:
> Regarding time granularity, what kind of time resolutions should I
> expect to obtain on a fast CPU like a 2,4 GHz ?
> I ran a test where i had 2 tasks: one task was CPU bounded, the other
> had a higher priority and slept for one tick, 1,000,000 times.
> Using a tick of 50 microseconds, and a timeslice of 50 ticks
> (although i
> would assume the timeslice to be irrelevant in this case since tasks
> have different priorities) the sleeping task was unable to awake in
> on 19 iterations. That is, a fail rate of 0.000019%
> I changed the microseconds per tick to 10, the fail rate was about the
> same. With 5 microseconds per tick, the system "blocked".
> A small resolution like 10 microseconds will inevitable lead to a huge
> overhead by dealing with the tick routine... However I was
> expecting to
> achieve some smaller granularity on a fast CPU. Or is this some PIC or
> PIT issue?
Currently, the rtems i386 BSP does not utilize the on-chip APIC,
relying instead on the external hardware: i8259 PIC, and an i8254 PIT
for the generation of system "tick" intervals. Thus, access to the
PIT requires reads/writes over a (relatively) slow I/O bus (ISA ?).
In contrast, the on-chip APIC should possess much faster access times
and it has a single down-counter running at the cpu frequency
(scalable, of course).
I've measured RTEMS interrupt latency on a PIII 450 MHz to be 7.5
microsec and 33.4 microsec, in the average and worst-case
respectively, on a heavily loaded system.
More information about the users