Re: PCI_LATENCY_TIMER

Doug Ledford (dledford@dialnet.net)
Tue, 29 Sep 1998 16:36:27 -0500


Gerard Roudier wrote:
>
> On Tue, 29 Sep 1998, Doug Ledford wrote:
>
> > For example, I have two different 3950U2B controllers in my machine right
> > now. Each controller has two separate PCI functions. Each function reports
> > MIN_GNT as 39 and MAX_LAT as 25. Multiply that times 4 and what do you
> > get? Impossible to meet. Why are they so particular, well, each funtion is
> > a separate Ultra2 wide SCSI controller and they operate entirely
> > independantly of each other, and fully in parallel, so the four channels are
> > capable of 320MB/s of data transfer. That number is so far above the PCI
> > busses 133MB/s there isn't a chance in hell that the PCI bus could keep up
> > with all four of them. But, that doesn't mean the MIN_GNT and MAX_LAT
> > values are wrong, just that the devices are fast enough that the PCI bus
> > can't possibly keep up with all of them.
>
> Doug,
>
> Thanks for your explanation of Adaptec interpretation of PCI.
>
> The initial post was about the 7880U that looks like an Ultra Narrow
> controller and, so, is only able to use 15 % of the PCI BUS bandwitch.
> This controller is specifying a MAX_LAT of 1.92 micro-seconds.

The same numbers are used on Ultra narrow or Ultra-Wide cards. At 40MB/s,
Ultra wide uses roughly 30% of the available bandwidth. But, I had that in
my last email, I also stated in my last email that the value of 8 in the
MAX_LAT register was wrong on the 7880 chips :)

Now, there is actually a reason why the older cards have this variable set
wrong. Specifically, the older cards where programmed under a different
interpretation of the PCI spec. In the older cards, the MAX_LAT register is
listed as being a register that indicates the minimum amount of time needed
in the LAT_TIMER register in order for the device to burst out its internal
buffer. AKA, MAX_LAT is calculated as the amount of time needed in the
LAT_TIMER register so that the card can still burst out a full amount of
data if the bus were to assert #GNT then immediately de-assert #GNT causing
the card to have one pass of LAT_TIMER length before being forced to return
the bus. Under that different interpretation, the values make sense.

> My opinion is that any acceptable interpretation of MAX_LAT leads to
> either this value being bogus, or that controller not being able to
> share efficiently the PCI bus with _common_ PCI devices.

The MIN_GNT and MAX_LAT values aren't about sharing. They aren't about
fairness. They are about what it takes for that particular device to
operate at 100%. Anything else in these registers would be a lie and would
actually make it *harder* to get the correct performance out of the PCI
bus. You don't want your cards being fair about PCI usage when specifying
what they *want*, you want them to ask for what they need. Whether or not
they get it is another matter.

> Your essay about 4 Ultra2 Wide (320 MB/s throughput) installed on a modest
> 133 MB/s PCI BUS is kind of off topic and makes no relevance.

Yes it does. It was meant to indicate a simple fact that is being
overlooked in all of this. The cards are suppossed to tell the PCI BIOS
what they *NEED* to operate at 100% performance. These four cards can *NOT*
operate at 100% performance simultaneously on the same PCI bus due to
bandwidth limits. In this scenario I don't want my cards lying about their
MIN_GNT and MAX_LAT values, I want them to tell the truth and give my BIOS a
chance to see the real congestion possibilities of the bus and set the
LAT_TIMER values accordingly.

> (BTW, such a system is probably unique on the planet is likely something
> that tests the limits of the PCI bus and certainly not the SCSI
> controllers performances).

My particular setup may be unique because I have all these cards plugged in
to test my driver, but it still doesn't compare to the systems they build at
Plutotech (where Justin Gibbs works) which include 20+ aic7xxx controllers
on a single motherboard.

-- 

Doug Ledford <dledford@dialnet.net> Opinions expressed are my own, but they should be everybody's.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/