[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interrupt latency problem



Christer Weinigel wrote:

>The reason for the scheduling delay being 10 ms is simple, the timer
>interrupt is set to 100Hz in the kernel, so if a process isn't
>scheduled to run immediately after an interrupt, it will usually take
>10ms until the next timer interrupt and the scheduler will notice that
>your process is supposed to run.
>
>Why your process isn't the top process to run is an interesting
>problem though.  It may be that your process it sleeping on some other
>event, and that this causes your process not to be scheduled.
>
Looking through my code, I noticed that I wasn't calling the code that 
would have changed the
scheduling policy and priority (very stupid error ! 8^(. After fixing 
this problem, I still see
delays of  one timeslice duration. Increasing the timer interrupt 
frequency to 1000 reduces this
delay to ~1ms, convincing me that this is a scheduler problem. What is 
interesting is that the
system shows this behaviour in bursts of 5 or 6, with the bursts 
occuring periodically every 25s.
If I set the timer interrupt frequency back to 100Hz, these bursts occur 
periodically every
250s. If I create some load on the system, I get fairly frequent short 
delays in the 1-2.5 ms
range. In short, it seems as if Linux does not really implement 
SCHED_FIFO correctly.

>If you increase the timer interrupt frequency you can probably reduce
>the effects of a missed scheduling.  The following patch will increase
>the frequency to 960Hz, but it does have the disadvantage that you
>waste more time on scheduling.  Note that 19200 must be evenly
>divisble by the frequency and that there are other limits in the
>kernel that stop the frequency from being much higher than about
>1200Hz, so you cant go up to 1920Hz.
>
With newer kernels (tested with 2.4.20 and 2.4.26, it seems to be enough 
to simply set HZ to
a different value (which should now be a multiple of 25000Hz, since Axis 
changed their timer
code).

>This is just a workaround though, it doesn't solve the original
>problem though.
>
My application could probably live with an occasional 1ms delay.

With kind regards,
Eric