Originally posted by: Peter
It isn't the southbridge's fault, and it never was. Not the purported lack of "parking" (which merely works around the Creative SB chips violating the PCI specification in that regard), nor inefficient arbiters nor latency issues.
Well, I've heard about the problem from a number of sources, not just in respect to Creative's (horribly-designed) sound cards. From what I understand, "bus parking" as a feature, was an
optional part of the PCI spec, so Via chose not to implement it, but Intel always did, so peripheral-card mfgs also assumed that it was basically de-facto part of the spec. Regardless of the true underlying reason, Intel's PCI-bus performance has nearly always been tops, with SiS right behind them, and Via trailing far behind.
Originally posted by: Peter
The "problem" is that VIA's PCI arbiters have always been highly tweakable, and system BIOS engineers rarely give a rat's ass about setting that up properly. The hardware defaults to a rather harsh "fairness" mode that favors even bandwidth spreading between multiple PCI agents, at the expense of single device throughput. Use VIA's "RAID performance patch" to get it the other way round, in case your board's BIOS doesn't.
I thought that simply adjusted latency values, no? I wish I had some detailed KT400 chipset docs. Sigh.
Originally posted by: Peter
Intel's PCI arbiters aren't programmable in that regard, so no chance for the software guys to fsck anything up ...
I thought that they offered the usual set of fixed/rotating/round-robin priority schemes, no?
Originally posted by: Peter
VIA's chipsets aren't actually half as bad as the myth spinners have it. It's just as popular a bashing target as e.g. ECS as a board vendor is. Same problem - too few experts, too many parrots repeating what they've heard someone else say their friend had read on the 'net.
The actual, overall problem however is that we're saturating the bus bandwidth. Once you've hit the ceiling, you need to balance fairness against throughput, you can't have both. So if your choice of chipset configuration lets the IDE chip go full blast, don't expect your PCI soundcard to be happy.
If they're really, truely, not so bad, then: 1) why do so many people have problems with them, BIOS engineers for Via boards can't be uniformly bad as compared to their Intel/SiS-chipset board counterparts, can they? That would seem to defy the statistical "norms". 2) Why is performance so bad, even in cases in which PCI bus bandwidth is NOT being saturated? The mobo's chipset IDE ports aren't even supposed to be sharing bandwidth with the PCI bus. And yet, I can't get more than 21MB/s out of them, instead of 30+MB/s, for an ATA-33 device. Something is clearly wrong. Also, benchmarking with AIDA32, the DRAM memory read-speed is right on the money for an Athlon XP2000/KT400/PC2700, but the memory write bandwidth is about 3X lower than what it should be, and I have no idea why. Perhaps that factors into this mystery somehow.
I mean, I agree with you, I think that the PCI arbiter factors into this somehow, as when I don't have any USB 2.0 devices operating (my WiFi NIC), I can get the PCI IDE burst transfer rate ceiling up to ~75-80MB/s, from ~58MB/s, for an ATA-100 device. But it's still no-where near the ~95-99MB/s I should be seeing. It's like it's reserving bus bandwidth for the USB2.0 devices, at the expense of the other system devices, but doing it rather stupidly. (Fixed allocation rather than dynamic rotating priorities or something.)
Last time I wrote code to twiddle system chipsets was back in the days of my 486 UMC core-logic set, had to fix-up some values that the BIOS didn't set correctly for performance purposes. Need to dig into this some more I guess. It just bugs me that I don't have a 100% solid answer behind why this is happening.
Btw, my prior assertions that the USB in this board was running in PIO mode may well have been wrong, I'm starting to think that the problem might be IRQ-related, at times, which causes similar symptoms of a "laggy" system/mouse-cursor/etc., since in either case the lag is caused by a dependency on getting the CPU scheduled to service the device. In task-manager, with "show kernel times" enabled, with 100% user-mode CPU load, I often see the "red line" top 30% as well, sometimes running at a full even 50%, which seems quite high to me.
What's even more interesting, is that even when running using the MPS Uniprocessor HAL (should therefore be using fully-native I/O-apic mode, and MS System Info shows unique IRQs, legacy from 0-15, PCI from 16-32, onboard from 64-69, AGP at 128), I still sometimes seem the effects that would normally be the result of IRQ-sharing/contention between devices, when there theoretically shouldn't be any. However, the devices that appear to be sharing, are the ones shown sharing legacy IRQs during the POST screens.
From what I understand from reading the Intel MPS-spec docs (correct me if I'm wrong), the system BIOS configures enabled devices using legacy-compatible IRQ modes (and PCI IRQ sharing) during booting, but then the OS is responsible for transitioning to fully-native I/O-apic IRQ mode. My theory is that if some devices are disabled or forced to non-"AUTO" settings in the BIOS, then the BIOS'es configuration doesn't match what the Via I/O-Apic driver expects to see (some kind of IRQ map table?) in order to transition to fully-native mode, so it never does, and kind of punts, and the system ends up running under legacy IRQ mode, sharing PCI IRQs as though "Standard PC HAL" was used, even though the registry settings for individual native IRQs are still present, and various "system info" tools show them that way, even though the actual system isn't running that way. Does that make sense? I guess if I had chipset docs I could find a way to read the appropriate registers after the system had booted, to find out what was really going on.
Facebook
Twitter