Re: PCI_LATENCY_TIMER

Gerard Roudier (groudier@club-internet.fr)
Wed, 30 Sep 1998 19:29:45 +0200 (MET DST)


Hi Doug,

I am quite unable to sustain your email throughput and I will have to give
up this thread since I have more urgent things to do.

Just before leaving this thread I will tell you the following:

Imagine I have a PCI system with a video grabber and some Adaptec fast
controller. Then the following may happen:

- The PCI BIOS may victimize the video input in order not to be too bad
with the adaptec with regards to its MAX_LAT desir.

- The Adaptec will be quite happy, but I may experience problems for
video conferencing.

- The adaptec will get good benchmark results even when other PCI devices
are heavily used (but one seems very broken).

If I were the typical customer Adaptec is targetting I would think that
the Adaptec is fine and that the video grabber is shit.

Let me tell you _loudly_ that the _need_ for an Ultra2 controller to be
fully operationnal for almost 100 % of _real_ SCSI systems in not 80
MB/second, but probably something less than 40 MB/second.
The SCSI protocol allows full data flow control as you know.

Specifications are intended to allow _real_ system to work and devices are
required to supply informations that fit _real_ system needs.

My opinion is that an Ultra2 controller that tells that it needs 80 MB/s
throughput to be full operationnal for the _reality_ of user systems needs
is a _liar_, and I am not going to change my mind on this topic.

Such a liar also is an O/S that donnot print any error message when
it detects hardware failure, for example.

Another example:
If users had knowledge of how unfair may be binary-only drivers in order
to get good benchmark results just for Marketing issues, then the Linux
World Domination would have been achieved since years, in my opinion.

kill -9 ThreadId(PCI_LATENCY_TIMER),
Gerard.

On Tue, 29 Sep 1998, Doug Ledford wrote:

[ ... ]

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

Indeed, they are not mine. ;-)

-
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/