I have some prototype PCI bus PLD-based fast data acquisition hardware which I
had on test at the Vienna workshop. When it is configured as a latency tester, a
24 bit counter/timer clocked at 33 MHz triggers an interrupt when it reaches
maximum count. It then rolls over to zero and starts counting up again. The
interrupt handler starts by reading the count twice. This gives a PCI bus read
latency around 25 cycles (under 1us) which is subtracted from the first count
read to give the interrupt response latency. The handler then resets the
counter to zero, re-enables interrupts and exits. The handler is the only real
time task on the system. Latencies seen with varying system loading over
millions of interrupts range from under 4us to around 50us on my 100MHz Pentium
test system running RTL-2.2.13-2.0. Running it right now I've got 33 latency
readings over 30us in 100,000 interrupts, min 3.5us, average 8.3us, max so
far 45us. Linux loading is X, KDE, ls -lR /, kernel compile, ping -f localhost.
I haven't checked the measurement hardware yet with a scope, but the minimum
and average results look credible so I reckon the maximum is too. What this
says about PCI bus latency I don't know, but it is the total effect which
matters to an application.
One outcome of the Vienna workshop was a decision to set up a real time linux
testing mailing list ([EMAIL PROTECTED]). We want to establish standard
performance test procedures based on appropriate timing devices (Pentium
TSC, PLD-based counter/timers etc). We need first to identify worst case
conditions and interesting measurements. The limited discussion so far is
archived on www.realtimelinux.org. If you would be interested in contributing
please subscribe to the list.
John
On Mon, 03 Jan 2000, Kal wrote:
>Paul Koning wrote:
>>
>> I wonder if people have examined the worst case timing properties of
>> PCI... assuming it has any. Lots of buses have no reasonable or
>> defined worst case behavior.
>>
>> paul
>
>Typical 33 MHz PCI hardware latencies are 10-20 uSec according to an IBM
>datasheet. Add to this any delays caused by the 'readPCI' code running
>on the CPU before and after the read. The PCI 2.1 Specification has two
>equations for calculating bus latencies after a device wins arbitration
>of the bus:
>
> worst case:
>
> latency (bus clocks) = 16 + 8*(n-1)
>
> n = number of 32 bit words transferred
> bus clocks = 1/33 MHz or 1/66 MHz depending on your PCI bus speed.
>
> typical case:
>
> latency (bus clocks) = 8 + 8*(n-1)
>
> The arbitration latency is:
>
> m * Latency Timer
>
> m = number of masters ( max is 8 )
> Latency Timer = typical is 22 bus clocks
>
> Your total PCI bus delay is the sum of the two latencies.
>
> - Each device can have a different timer setting. Check the settings
> of your devices.
> - Some devices can do an endless data transfer without a timer.
> - Normal Linux can start a PCI data transfer that can run into
> a real time Linux interval.
>
> Experiment with your system setup. If you need shorter delays stop
>any unnecessary Linux PCI transfers, and plan the transfers better.
>
> The PCI 2.1 Specification is available for download at:
>
> http://akulin.npi.msu.su/docs/standard/pci21.pdf
>
> Latencies are covered in section 3.5.
>
> - Kal.
John Storrs, Laboratory for Micro Enterprise
125 Culham 1 Site, Culham, Abingdon OX14 3DA, UK
tel/fax 01865 407085 email [EMAIL PROTECTED]
www http://www.i-way.co.uk/~storrs
--- [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/
