I got your reply to my post, but I thought I'd reply here instead.
Felix Miata wrote:
> Terry Mathews wrote:
>
>
>>>The PCI performance deficiency survived many VIA chipsets.
>>>
>
>
>>And VIA fixed it in their chipsets. The latest VIA 4-in-one drivers
>>integrate the PCI timing latency patch, and will install on all VIA
>>
>
> later . . .
>
>
>>chipset-based mainboards including the MVP3 which is the oldest VIA based
>>PCI motherboard I can think of off the top of my head. Also, until the
>>advent of Ultra160 RAID cards and Ultra133 IDE controllers, there were no
>>devices capable of moving data fast enough to expose this problem. VIA did
>>
>
> A bus is designed for multiple devices, so the inability of any single
> device to fill the bus when the real issue is what happens with a real
> from a RAID array or a HBA with a bunch of 15,000 RPM drives is a red
> herring.
>
I dont' understand this. Not that you don't have a point, but I think
there are a few words missing in there, and I can't guess what they
might be. To me it is relevant that at the time many of VIA chipsets
were developed most single cards couldn't burst transfer anywhere
near the PCI limit. And since we're talking about 'burst' transfers
more than one card can't really effect the results because while
bursting the card has the bus mastered and locked so the other cards
can't get at it.
>
> I don't even consider them since they refuse to fix an acknowledged BIOS
> bug that prevents OS/2's use of both channels of LSI chipped SCSI HBA's
> in their motherboards. That leaves (due to experience) is Soyo, AOpen,
> Intel and Tyan. Some popular brands I refuse to consider due to stupid
> web site design that makes finding things or sharing links (frames
> obstacle) too tough.
>
>
>>I could've stated that better. The "patch" is a fix to the VIA 4-in-one
>>drivers in Windows
>>
>
> And that helps owners of systems that never have had nor ever will have
> windoze installed exactly how?
>
>
>>that when run flips a bit in the VIA chipset that makes
>>the PCI bus timing more agressive. Chipsets don't contain any writable
>>storage areas. BIOSes do though. All ASUS, or any other motherboard
>>manufacturer has to do is program the BIOS to flip that tiny bit in the
>>chipset and all is fixed (Well, tweaked technically since nothing was broken
>>to start with). I know ASUS did it, as the fix is integrated into my latest
>>A7V133 firmware.
>>
>
> So if the motherboard maker is any good, the BIOS will overcome entirely
> any potential "interrupted PCI bus transfers" performance limitation the
> tecChannel article discussed? If that is true, I find it hard to believe
> it was ignored in the article.
>
Well this is maybe where we're miscommunicating. Hardware these days is
getting more and more complicated. HW designers know that no matter how
good your spec is there will things that change. Bugs in the spec.
things they will want to change to tune their products, etc. Because of
this, and the fact it is very expensive to 'respin' a chip they design
nearly all of the chip to be configurable through changing the values
in it's registers.
They supply the MB and BIOS manufacturers with sample code, and docs to
use when writing the BIOS or OS Driver code that initializes these
registers. Actually it is entirely possible that the BIOS initializes
them correctly, and Linux inherits the right settings already. It *may*
be only the Windows drivers (remember that articles tests were run on
Windows) that resets some of the registers to values that impede
performance. So the fact that the patch is 'windows only' may not be a
problem.
Even if current BIOSes also get it wrong. It's possible that there will
soon be BIOS upgrades that will contain the same fixes. Also just like
windows drivers can change the values in the registers, there's no
reason why a Linux driver can make the same changes. I think someone
already said they thought that some linux driver had actually been
modified to do just that.
For that matter, the Linux Driver may have had it right all along.
I don't know. Only running the same tests on Linux would tell.
-Kyle
--
_
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc. |||||
Enterprise Server Products [EMAIL PROTECTED]
1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o) fax: (781) 442-1542
-------------------------------ooO(_)Ooo-------------------------------
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
