> I had 312 messages in my mailbox this evening and each of yours must be
> counted as sized as 10 times the average message size. :-)
> So, I may have missed that. I remember you spoke about old boards and
> I did'nt know that the 7880 was so old.
The 7880 (as well as many others) is a first generation PCI chipset from
Adaptec, 7895 is second generation, and 7890/1/6/7 are third generation.
> > > 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
>
> No fairness requirement leads to PCI devices being allowed to speficy 254
> as MIN_GNT and 1 as MAX_LAT that makes these PCI parameters irrelevant.
Bullshit. Since when is fairness a requirement to telling the truth? You
do the calculations like I did in a previous email and you stick the results
into the registers. No fairness, no exaggerating things with outrageous
claims of MIN_GNT 254 and MAX_LAT 1, just the results of the calculations
and then let the PCI BIOS do its job, that's what it's there for after all.
> > operate at 100%. Anything else in these registers would be a lie and would
>
> A device telling that it may achieve 100% when the PCI bus is dedicated
> to itself is not a lie but _the_ truth, since any other device, even slow
> will have some impact on performances.
Wrong, another device on the PCI bus *MAY* impact device A's performance,
but only if the actions of device B interefere with the MIN_GNT and MAX_LAT
timings of device A. It is entirely possible that with two PCI devices that
are each less than half as fast as the PCI bus, that both devices could
operate at maximum efficieny on the PCI bus.
> > 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.
>
> You are playing with words in a insane way.
>
> Here are my needs:
>
> 1) If I get 1000 M$ I will be 100% happy.
> 2) If I get 10 M$ I will be 99% happy.
> 3) If I get 1 M$ I will be 98% happy.
>
> I _want_ 1000 M$, but I _need_ only 1 M$ to be quite happy. The
> additionnal 999 M$ that I want are just wasting money for you with regards
> to their efficiency to make me happy. So 3) is a lot more relevant for
> you if you want to make me extremally happy. ;-)
>
> In my opinion, PCI devices are expected to be as fair as I am when
> specifying their needs, in order to allow the PCI BIOS to make a
> reasonnably good work.
I'm playing with words in an insane way?
Come on Gerard. This whole "fairness" thing is a crock. Think about it.
I'm suppossed to modify my MIN_GNT figures down to some "nicer" value and my
MAX_LAT values up to a "nicer" value for the PCI bus so that some imaginary,
possibly non-existent, but certainly unknown other PCI device that might or
might not be sharing a PCI bus with me can have some of my time? Bullshit.
The PCI BIOS *CAN NOT* know what the real requirements of the PCI devices
are if they modify their settings for unknown conditions. That's the whole
reason for having the PCI BIOS set the LAT_TIMER register at boot time
instead of hard wiring the LAT_TIMER value on the card just like you do
MIN_GNT and MAX_LAT. The cards need to tell the PCI BIOS what they *REALLY*
*NEED* (and note, I did say NEED in my original email, not want, and
certainly not anything fictitious like you put in your response) in order
for the PCI BIOS to have any chance of setting things on the PCI bus
properly. Trying to be "fair" about things ahead of time is a crock because
you don't have the faintest clue what else will be on that PCI bus besides
yourself. All you can do is be honest about your needs and let the PCI BIOS
decide how things are going to be actually handled.
--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/