tunning PCI latency ...

StefanEßer se at FreeBSD.org
Thu Nov 11 16:02:05 PST 2004


On 2004-11-12 09:38 +1030, "Wilkinson, Alex" <alex.wilkinson at dsto.defence.gov.au> wrote:
> 	0n Thu, Nov 11, 2004 at 11:01:24PM +0100, Stefan Eßer wrote: 
> 
> 	On 2004-11-11 12:22 +1030, "Wilkinson, Alex" <alex.wilkinson at dsto.defence.gov.au> wrote:
> 	> Hi all,
> 	> 
> 	> Is it possible to change the latency of PCI devs in RELENG_5 ?
> 	> i.e in the same respect it can be done in Linux with setpci(8).
> 	
> 	What do you try to achieve?
> 
> I wanted to experiment with changing the amount of time PCI devices were allocated
> to burst data across the bus and the effects of doing so.

Hmmm, you are aware that the latency timer value is irrelevant
unless there are multiple competing bus-masters?

It is not a time slice assigned to a device, but the minimum time
slice that the device gets granted in case of competition (i.e.
once it gets to use the bus, a higher priority master will have
to at least let it have that many cycles).


The master latency timer in the host bridge may have a lower value
than the device latency timer, causing the latter to never trigger.

The sum of all latency timers must be low enough to permit all
possible bus-masters to access the bus before their internal fifo
buffers overflow. That puts a maximum on the sum, which in theory
depends on the maximum latency value reported by the device with
the (in relation to its nominal effective transfer rate) smallest
buffer. Lower values will just cause the bus to be given up early
and will cause a higher fraction of address vs. data cycles.

Normal latency timer values (in the range of 16 to 32 cycles)
should get you 75% to 90% of the theoretical bandwidth, while
the maximum latency for 2 or 3 competing bus masters is at most 
2 micro seconds (less than 200bytes at Gigabit Ethernet data
rates).


I don't think that changing the latency timer is going to make
any a difference, except under extremely high bus load ...

Regards, STefan


More information about the freebsd-current mailing list