[EMAIL PROTECTED] wrote:
>
> The purpose of the oneshot is to make it convenient to have several
> tasks with no large common divisor in their periods. For
> example if
> Thread 1 starts at time 0 and has period 400
> Thread 2 starts at time 70 and has period 500
>
> a periodic interrupt of 10 is needed to ensure an interrupt at
> both time 400 and time 570.
> In oneshot mode the clock is reprogrammed every interrupt so we
> would set the timer for 400 and on the interrupt reset it for 170 and
> on that interrupt reset it for 230 etc.
> The drawback to oneshot is that, on UP x86 machines, the clock is
> incredbly slow to reprogram-- sometimes as much as 12 or so microseconds.
> So if you have one task or a good gcd, use periodic.
I was wondering if the reason for the up to 12 uSec delay is due to the
fact that the 8254 timer is located on the other side of the PCI bus
from the CPU, on the South bridge. Since RTL cannot stop Linux PCI
accesses from starting just prior to the start of an RTL interval, I
think that Linux PCI accesses are interfering with the setting of the
timer. A simple solution may be to set the Master Latency Timer in each
PCI device (including the North and South bridges) to about 1 uSec (32
decimal or 20H). This should reduce the 12 uSec delay to about 1 uSec.
The default setting for the Master Latency Timer is zero, which disables
it. When disabled a device can send for as long as it wants.
This 1 uSec setting should only be a problem in a heavily loaded PCI
system. But, since we are more interested in latency than bandwidth
this may be a more preferable setting for RTL.
- Kal.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
