VIA Chipsets slow down PCI cards

[Dudster]

Came across this article today about really poor performance of PCI slots on VIA chipsets, both AMD and P4 (written before the KT333 so I dunno about that). Talks about how the bug messes with burst transfers which can cause problems with soundcards (sounds familiar) and lower the performance of PCI hard disk controllers and maybe cause other problems.

There are a few patches but details on them is sketchy so I dunno if my ASUS A7V (KT133) would benefit.

Thought this might help some people and I'm curious what other people's thoughts are.

[Peter M]

Same old bull. It's been long known (and tecchannel knows it too) that it's all about setting the chipset up right in BIOS. VIA's PCI controllers are highly tweakable in their arbitration behaviour - and if you get a board from a manufacturer who doesn't care much about optimizing these things, you'll end up with sub-par PCI throughput. It ain't the chipset's fault, no matter how often those headline junkies repeat that myth.




**profanity removed by surreal

[OuTpaTienT]

Peter.....language.

(just warning ya before the mods edit it for you.)

[FreakyOCR]

Yeah that's why nobody gets VIA chipsets for servers or ops where you need high i/o on the pci bus... via can't cut it...

[OuTpaTienT]

Originally posted by FreakyOCR
Yeah that's why nobody gets VIA chipsets for servers or ops where you need high i/o on the pci bus... via can't cut it...

Um, I think Peter just said that VIA can cut it. You just need to set them up properly in the bios.

[dunbar]

That is, if the BIOS lets you set them up properly.... the mobo design engineer is at fault for causing BIOSes which cannot allow all tweaks.

[RAR]

How do you set them up correctly? What are the best settings?

[JohnE.]

It's all about parking the bus: Darth VIA

JohnE.

(edit: I'm Anonymous Gerbil #25 (page 3) if anyone is that ambitious )

[Epyon9283]

If only I would have known that before buying an Abit KA7-100 and then an Abit KT7A. Both use the kt133 chipset. I wonder if the kt333 is affected since I have that in the motherboard I have now. When I had the KA7-100, I had to get rid of my sound blaster because of the horrible cracking(this was before there were any patches for it).

[Peter M]

Originally posted by JohnE.
[B]It's all about parking the bus

No it's not. The bus parking thing is another topic - there being some PCI cards (sound cards mostly) whose designers forgot that the PCI bus may perfectly well be COMPLETELY unclaimed and idle. On a chipset that never enters that state - instead "parking" bus ownership on a random device - you won't notice. VIA's chipsets do put the bus on idle when noone wants it. VIA implementing bus parking in the 8235 just works around other people's stupidities.

PCI performance is about balancing single device throughput (which means allowing single device to keep the bus for long times) against multiple device fairness (which means passing bus ownership around frequently).

While Intel's have a static preset for this behaviour (but added a programmable fairness tweak in the 8xx chipsets), VIA's PCI controllers have ever had it widely programmable - and many many BIOSes left this at utterly bad settings, mostly way too far on the "fairness" side of things. Not that anyone noticed - it's just that in recent times, PCI bandwidth is saturating more and more, and up there, right below the ceiling, you will notice.

regards, Peter

[JohnE.]

"It's all about parking the bus" - this was meant to be funny, not an all-inclusive absolute

While I don't claim to be an expert on all things PCI bus and therefore can't vouch for the truth or accuracy of the information in the article, after reading your reply I wondered if you had actually read the article (the one the "Darth VIA" link points to) wherein the author states, "It seems VIA's south bridge chips didn't include a PCI extension called bus parking that Intel implemented in its post-BX series of chipsets. Many PCI card makers simply assumed bus parking would be available to them" - as it would be on any post-BX Intel chipset.

I don't know enough about the really, really technical side of things regarding this issue to confirm or deny the articles accuracy, but from what I do understand, the fairly extensive research I have done and my own experience, I'm convinced that this issue is indeed an issue with certain older VIA chipsets and not the PCI card manufacturers products.

This is a rough chronology of my experiences with this issue:

* A few years ago I owned a Legend QDI i430TX board for which I purchased a Creative Labs SoundBlaster Live! Value.
* I installed the SoundBlaster on this Intel chipset motherboard and had absolutely no problems - no crackling, popping or hissing at all.
* I upgraded the processor from the original Pentium 233 to an AMD K6-2 300 and replaced the motherboard with a ChainTech 5AGM3 (VIA MVP3; 586B South Bridge), retaining the SoundBlaster card - lots of crackling, popping and hissing on every audio event, while gaming, during recording from the line-in, while listening to mp3's, etc.
* I researched and read most of the information available regarding this issue, trying every proposed solution, none of which worked for this particular motherboard.
* I came across "the" main thread regarding this issue at the VIA Arena Support Forums and began asking questions and sharing info with other users.
* John Gatt, the forums moderator, replied to every, "I'm getting crackling audio on my VIA chipset system" post with (in essence), "It's Creatives fault, buy a better soundcard".
* Not satisfied with this answer (considering the fact that the EXACT same SoundBlaster in the Intel chipset board exhibited no problems whatsoever) I contacted Tech Support at M-Audio and asked if they had any reports of this issue with their Delta series of professional soundcards to which I received an honest, courteous reply confirming that this problem can indeed afflict even their "Pro" soundcards on some older VIA chipset boards.
* I posted my entire correspondence with M-Audio on the VIA forum, clearly showing that this was not solely an issue with Creative Labs cards.

* The very next day John Gatt permanantly closed that thread.

* I eventually upgraded my system to an AMD K6-III+ 450 on an Epox MVP3G5 (VIA MVP3; 596B South Bridge), still retaining the same SoundBlaster card - some crackling, popping and hissing, but this time only while playing games or while playing mp3's while surfing the net (or any other I/O intensive activity).
* I then (holding my breath and crossing my fingers) purchased and installed an M-Audio Delta66 soundcard... it crackles if I use it for gaming but is fine when used for multi-track recording and playback. So, I now use the SoundBlaster for gaming and the Delta66 for digital audio.
* I came across the "Darth VIA" article and everything fell into place... my own suspicions are confirmed, my personal experience is validated and John Gatts' denials and behaviour now make sense.
* I attended (just last night, by coincidence) an M-Audio M-World 2002 tour stop in my hometown where I had a chance to speak with David M. (from M-Audio Tech Support) and found out that they (M-Audio) have been working closely with VIA (who admitted it is an issue with their chipset, but not publicly) recently to eliminate this problem in the newer VIA chipsets.

This issue goes way beyond simply tweaking the PCI latency via the BIOS that you seem to be alluding to in your post. I've tried *every* known PCI tweak possible solution and nothing has worked. The older VIA chipsets are flawed. M-Audio knows it, Creative knows it, VIA knows it and John Gatt knew it (and for quite some time I might add). End of story, IMO.


On a side note, I also found out that M-Audio is also working with Microsoft to try and solve the, "enabling ACPI causes latency problems for multi-track pro audio applications" and was told that the issue should be fixed in the next Microsoft OS release and that in the interim there may be a driver work-around (which would only apply to M-Audio cards I assume).

(whew, longest post I ever made anywhere, lol)

Cheers,

JohnE.

[OuTpaTienT]

Well, that's nice that you were able to read a post that "confirmed" what you already "suspected".

My question for you is why have I never experienced this problem? I've owned a few VIA chipset motherboards. I'm using one right now. Plus I've built a number of systems for others with this chipset. Almost always use SB sound cards. Also have a SB Live installed right now with my VIA chipset. Sound quality is very important to me, and this is an issue I would have noticed if it existed in any of system I've built including my current system.

I guess I'm just "lucky" huh? lol.

[Peter M]

It isn't that VIA "admitted it was a problem with their chipsets" ... au contraire, they went to the length of debugging the problem for Creative, and found out it's because the latter's PCI chips can't handle a truly idle bus. On chipsets that do "bus parking" (which is an entirely optional feature in PCI controllers), there are thus no symptoms. VIA then went one step further and - rather than fighting it out with Creative - opted for the customer friendly solution, caved in, and made their latest chip do bus parking instead of letting the bus go truly idle.

Then there's another source of disturbed sound, and that's a misbalance of throughput and fairness on the PCI bus. This is where the configurability of the PCI arbiter comes in - and if you're not a BIOS engineer who knows how to tweak things, you're at the mercy of your board maker if it's a tweakable (read VIA) chipset. [On the surface, you hardly see the tip of the configuration options iceberg btw. Grab the now public MVP3 chipset datasheet and see for yourself how many PCI related knobs and switches there are.]

In either scenario, not VIA's fault.

regards, Peter

[Peter M]

Oh btw, high end audio like the M-Audio series suffers from poor throughput as seen with poorly engineered BIOSes, and at least one additional problem: Interrupt latency. This is why it gets so much worse in MS operating systems with ACPI enabled - the ACPI capable Windows flavors pile all the PCI interrupt sources onto one vector, which makes interrupt latency go through the roof. This in turn causes FIFO overflows and underruns in the sound card, in the same way as a saturated PCI bus does. Crackle. Pop. Hiss.

[JohnE.]

OuTpaTienT...

You may indeed be one of the lucky ones. This issue doesn't affect *all and every* older VIA chipset and there are many systems with all the pre-requisites for this issue that do not exhibit these problems. It depends on motherboard manufacturer, model and revision, specific VIA chipset, etc. Unfortunately, there are almost as many unlucky systems, mine included.

Peter M...

"On chipsets that do "bus parking" (which is an entirely optional feature in PCI controllers)"

Yes, bus parking was optional but when it was implemented in Intel chipsets, everyone followed suit - except VIA - and there were thus no symptoms with Intel chipsets. While VIA can claim that they were in (strict) compliance to the PCI spec this did not make for happy and satisfied customers who now had to suffer with the prevalent symptoms of their "Strictly PCI spec compliant but still malfuntioning audio subsystems".

While it can be argued that, technically, this issue isn't really anybodies "fault" (except maybe Intels for starting the whole mess ), VIA's stubborness caused a lot of grief for a lot of people. My beef is that they pointed the finger at everyone else and said, "buy a new soundcard" when there was nothing wrong with the soundcards and they never attempted to fix the problem themselves until pressured into it when denial could no longer be sustained. Don't get me wrong... I love my little AMD/MVP3 system but it'll be a long time before I ever trust VIA again.

"opted for the customer friendly solution, caved in, and made their latest chip do bus parking instead of letting the bus go truly idle" - Something they should have done in the first place, just like everybody else, IMO.

"Oh btw, high end audio like the M-Audio series suffers from poor throughput as seen with poorly engineered BIOSes" - I'm sorry, but I cannot decipher that sentence and very little of what comes after it.

I misspoke... where I said, "enabling ACPI causes latency problems for multi-track pro audio" I meant to say, "enabling ACPI causes performance problems for multi-track pro audio" - stuttering playback and dropped samples when recording - not crackling, popping and hissing. The more tracks one tries to playback or record simultaneously and effects one tries to use, the greater the chance for stuttering and dropped samples. Disabling ACPI allows one to effectively use more tracks/effects simultaneously, dependant upon cpu resources.

High-end audio cards are like modern video cards in that they require an IRQ all to themselves for best performance, which ACPI in single-cpu systems running Windows 2000 interferes with. The problem is much less prevalent in Windows XP and should be history in the next MS OS. The problem is that MS doesn't make OS's for pro audio use and didn't anticipate this issue, it has nothing to do with "poor throughput", "poorly engineered BIOS's" in high-end audio cards or interrupt latency. Does a soundcard even have a BIOS?

JohnE.

[OuTpaTienT]

Trying to keep up with all the tech talk is making my head hurt.

[Peter M]

John,

top to bottom ... when a PCI card doesn't run right on systems that have no bus parking, then that's a hardware design bug on the PCI card side. Ain't no discussing that. By the PCI specifcation, Bus Parking behaviour is entirely optional - thus cards relying on it being there are broken. Period.

Also, it's not like EVERYBODY's PCI controllers do bus parking. There are plenty that don't - particularly when you look further up from desktop PCs. Plenty of PCI bridges and related gear for the big guns don't, with no harm done ... and noone uses Creative's sound cards in those anyway

"poorly engineered BIOSes" are found on (a finally decreasing number) of VIA chipset mainboards. If you don't configure the VIA PCI controller for a good balance between throughput and fairness, it'll suck. The higher the bandwidth demand of your PCI cards, the more you will notice. That's why high end audio suffers from this - and that's why if you want to point fingers at people, point them at the remaining mainboard makers that still don't get it right.

On a side track, PCI cards that require their own exclusive IRQ are broken by design (to be exact, their driver is). The PCI specification has been forbidding that at least since 1993.

However, I assume this card technically works on a shared IRQ, but suffers from Windows operating systems' ridiculously slow interrupt handling latencies. That's what MS need to fix - not only for high end audio, but also for many other heavily I/O bound gear. Finally making the move from ye olde pair of 8-bit ISA "PIC" interrupt controllers to "APIC" usage (not ACPI) will improve things too.


So, what are the action items?

* Have the PCI card makers read PCI specifications, and get their hardware right.
* Slap various BIOS engineers with VIA chipset manuals until they get it.
* Make MS sit their butt down and do something about their OS kernel's event handling latencies.

regards,
Peter

[JohnE.]

Peter,

Ok, I see what you're saying. I just don't agree that it's the fault of PCI card makers. Actually, I don't think it's really anybodies "fault" technically speaking.

Afaik, according to the PCI spec there's nothing technically wrong with implementing bus parking or with not implementing bus parking as it is optional. I say, "afaik" because I haven't read the spec and probably wouldn't understand enough of it if I did to know one way or the other, math not being my strong suit. I do think it was a bad business decision on VIA's part that was further compounded by their lack of action to fix the problem. Only now are they addressing the issue and changing their chipsets to enable bus parking so as to fall in line with the rest of the desktop market.

"thus cards relying on it being there are broken. Period." - Yes, on non-Intel chipsets. My SoundBlaster works fine in any non-older VIA chipset board (I'm talking desktops here).

"If you don't configure the VIA PCI controller for a good balance between throughput and fairness, it'll suck." - I'm not sure I understand - are you meaning adjusting PCI latency in the BIOS?

I misspoke somewhat again... high-end audio and video cards will give *better performance* when they have an exclusive IRQ but don't *require* one for operation. To me this only makes sense... I want my Delta 66 to have as much system bandwidth as possible when I'm trying to mix 8+ tracks of 24bit/96KHz audio. There's just no way around the fact that the more tracks you add, the more system resources that will be required. I don't consider anything to be "broken" when it has the capability to use as much bandwidth as it needs to achieve the results I want (smooth playback, no dropped frames, etc).

Now, if only MS will release an OS that helps my high-end card to achieve it's full capability I'll be a famous rock star in no time .

In any event, this has been an educational thread on a facinating subject. I'm always interested to learn more about this and related subjects.

Finally, "making the move from ye olde pair of 8-bit ISA "PIC" interrupt controllers to "APIC" usage (not ACPI) will improve things" - I'm intrigued... do you have a link to more info on this?

Cheers,

JohnE.

[Peter M]

Hi John!

Indeed, by the PCI specification (everyday reading at work for me), bus ownership parking is an optional ongoing. PCI agents must be ready to cope with an idle, un-owned bus. Cards that don't are technically broken - although they might work in environments that don't touch their bad spot.

Configuring the VIA PCI controllers has much more to it than just setting the latency. They are highly tweakable in regard to arbitration strategy, bus ownership timeouts, and many more subtle factors to a nicely balanced PCI bus. This makes them flexible enough to fit the weirdest applications, but also makes them prone to being off the desired behaviour - if the BIOS engineers don't take their time and optimize their choices for the environment their stuff goes into.

Re the IRQ sharing, I got you right I think, I didn't assume it _needs_ a unique IRQ.

The PC architecture has ridiculously slow interrupt handling to start with, slow operating systems don't make that any better obviously - and shared IRQs, while not too bad in hardware, also make critical things worse in slow OSes.

The APIC interrupt controllers, originally introduced for dual processor systems, use a sideband bus directly to the CPU(s) for interrupt signalling and acknowledge. This dramatically lowers initial interrupt latency, gives the PCI interrupt lines a direct path without squeezing them into the 15 ISA compatible IRQs, and also handles the chipset buffer flushing business (required when an IRQ triggers) much more efficiently.

Multi-processor capable OSes can run the APIC mode even with only one CPU in. Linux 2.4.x, Windows NT, 2K, XP can do it - if the system chipset has them (VIA's south bridges since the 596 included it, with the exception of the 8233A), and the BIOS enables the feature. It's been there for quite a while, but just now it's getting recognized and implemented.

But interrupt handling aside, high end PCI audio cards also suffer from the general throughput ceiling of standard, 32-bit, 33 MHz PCI. This bus has been with us for 11 years now, time to move on. Sadly, no commodity chipset offers anything faster.

regards, Peter

[JohnE.]

Ahh... ok, that explains why ACPI in Win2K isn't an issue on dual-cpu setups. Looks like it's time for an upgrade to WinXP for me

Here's the article I've been reading: Problems with single CPU systems and Windows 2000/XP (follow the links on the left: News & Infos>F A Q>Latest Additions)

I'm currently running an AMD K6-III+ 450 (oc'd to 550) on an Epox MVP3G5 with the VT82C596B South Bridge... is there anyway I can confirm that the system is using the APIC mode?

I've read a little about the upcoming Next Generation I/O but it's, sadly, still a long way off from what I understand.

JohnE.