SiS748 Compared to Via KT400 or KT600

[Peter]

I thought so

Back in the days of 440BX, we weren't nearly saturating the PCI bus. Drives had smaller caches and lower media I/O throughput, so even on an UDMA5 channel, you'd never get those 95 MB/s, and we'd hardly ever run into a situation where isochronous agents (sound, TV cards, etc) were kept off the bus for long enough to throw them out of sync.

That figure is about the maximum you get from a storage controller on standard PCI - I've seen that same ceiling on anyone's chipset, from ALi over VIA, SiS and Intel to ServerWorks, with IDE, SATA, and even the finest of SCSI controllers. There's a lot of housekeeping accesses in storage, that's where the delta to the theoretical 133 MB/s ceiling comes from.

440BX does suffer from the same balance problems as everyone else's PCI busses once you near saturation - only that it has no means of shifting the balance this or that way. VIA's do - shame that careless implementers ruined the party.

 

[VirtualLarry]

Originally posted by: Peter
I thought so

Back in the days of 440BX, we weren't nearly saturating the PCI bus. Drives had smaller caches and lower media I/O throughput, so even on an UDMA5 channel, you'd never get those 95 MB/s, and we'd hardly ever run into a situation where isochronous agents (sound, TV cards, etc) were kept off the bus for long enough to throw them out of sync.

That figure is about the maximum you get from a storage controller on standard PCI - I've seen that same ceiling on anyone's chipset, from ALi over VIA, SiS and Intel to ServerWorks, with IDE, SATA, and even the finest of SCSI controllers. There's a lot of housekeeping accesses in storage, that's where the delta to the theoretical 133 MB/s ceiling comes from.

440BX does suffer from the same balance problems as everyone else's PCI busses once you near saturation - only that it has no means of shifting the balance this or that way. VIA's do - shame that careless implementers ruined the party.

So you're saying that running only a single ATA-33 CD-ROM (with some normal OS HD paging/registry activity in the background), will saturate the PCI bus? Somehow, I doubt that. Via's PCI-bus implimentation (or my mobo BIOS's configuration of such), is shite. (Actually, according to Via, the KT400/8235's IDE channels shouldn't even be taking up PCI-bus bandwidth, only V-Link bandwidth set aside above and beyond the PCI-bus bandwidth. So that makes this all even more puzzling.)

My 440BX's PCI bus implementation was much better - I actually have been able to pretty-much saturate the PCI bus on the 440BX chipset pretty easily, and everything just keeps humming along. No so with Via. A good tool is Adaptec's SCSIBench32, you can start doing transfers (read-only) from various storage devices as the same time. You can clearly see what goes on when you start to reach the saturation point. Doing a lot of I/O-intensive things all at once is a good measure too, burning disc-to-disc, while reading another disc, or watching a DVD movie, etc., along with network downloading going on in the background.

Is there a tool that will identify the actual speed/bandwidth that the V-Link bus is currently running at? Kind of like Via's HyperTransport tool?

I have reason to suspect that the V-Link on this bus (8x V-Link) isn't running at full speed, which is the major root cause of most of my I/O bus bandwidth problems. This particular board has had multiple BIOS revs due to common complains of IDE CRC errors being reported; I suspect that they were never able to find the real cause (bad board layout, noisy signals, perhaps), and so they just down-clocked the V-Link bus instead, resulting in a major hit to I/O bandwidth, but stablizing the chipset IDE channels. That's just my speculation at this point, but it could explain it. (It still wouldn't explain periodic slowdowns/mouse lag though, that's still probably something else.)

 

[Peter]

IDE in general is a bandwidth hog because the IDE bridge chip needs to keep bus ownership back-to-back from starting the command execution on the drive until the last data word arrives. This is a lot more time than the actual data transfer takes. So yes, even a 5 MB/s HDD will saturate the 100 MB/s bus it is on as you're continuously reading from it at its maximum speed. Doing things like DVD viewing doesn't do that simply because these drives read ahead and serve the next read access from their buffers w/o bus hogging latency.

Besides, you're preaching to the choir ... being a BIOS engineer I know fairly well how to assert and try out my bus throughputs

Back to the point: It isn't the VIA _chips_ that give you poor throughput, it's how your board's BIOS sets them up. They can be fast if programmed to be fast. Tried VIA's RAID performance patch yet? If you suspect your particular board has a layout fsckup covered up by braking the V-Link speed down, you'd have to find a utility program that can read the registers for you. Try CPUZ, WPCREDIT, WCPUID. I'm afraid I can't read the datasheet out aloud here
Still, even 1st-generation V-Link speed of 266 MB/s shouldn't be that limiting ... Intel are using a southbridge link of exactly this speed to this date (ICH6 finally increases).

 

[allanon1965]

well i have decided to stick with the asus board that is using the nforce chipset, seems to be a little better performing in my games......thanks for the education fellas, it was very interesting reading!

 

[nemesismk2]

bump