VIA releases patch for Promise RAID performance
VIA has released the PRPP - Promise Raid Performance Patch. There is a single paragraph explaining the patch and no further explanation on the front pages of either of VIA's sites. Here are the goods:
This patch, for all Microsoft Operating Systems, will increase the burst rate. This may not be noticeable in overall Hard Disk performance benchmarks as burst rate is not measured separately and only makes up a small percentage of Hard Disk performance.
The file is the familiar VIAPFD.sys, which I believe was originally created to alleviate the SBLive! and 686B PCI issue.
The text says the patch corrects burst performance. On the other hand, the text makes no mention of frequent interruptions occuring on the PCI bus or of the difficulties associated with those interruptionsdifficulties including trouble with sound cards, graphics products, Highpoint controllers and SCSI controllers. Far and away, Promise IDE controllers were providing the best of the worst scores on VIA's PCI bus. Those of you looking for a difference between the VIAPFD.sys file in the 4.37 version of VIA's 4-in-1 drivers and this patch won't find a file version difference, only a file size difference. As you can see, there is very, very little to go on. I assume that this file may simply be George's existing latency patch repackagednot a perfect solution, but I suppose it is something.
As for George, it seems he may have discovered the larger problem:
I'm starting to believe the claims of a problem with the VIA PCI bus, as documented by TecChannel. I believe I know which timer is interrupting the bus, and I know how to disable the timer, but I believe that SoundBlaster audio will suffer if I do. If I'm right, then the problem is as follows. VIA's PCI controller contains an "arbitration" timer that will detect when a PCI device has used the bus too long. This timer should be triggered when another device needs to use the PCI bus. But VIA's timer is being triggered when no other device needs the bus. As a result, no device can continuously use the bus for longer than the length of the timer. I wish I could prove whether another device needed the bus and triggered this timer, but I don't have the tools to do so.
And so the search for the truth continues.