Strange timing results

[Daron Chabot]

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  
> time
> 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.


-- dc