Introduction

Now that we've exposed video card performance under the Linux operating system, it is time to shed light on another aspect of your system's performance: chipsets. Linux video card performance tests are becoming more and more popular, but arguably the most important part of your computer has seen very little coverage in terms of Linux testing. In this round, we consider Pentium III chispets saving an Athlon comparison for a future article. The three chipsets are the old, but still potent Intel BX chipset, represented by the Asus CUBX, the modern, on-board video sporting Intel 815 chipset, represented by the popular Asus CUSL2 and the outsider, VIA's Apollo Pro 133A, represented by QDI's Advance 10.

What makes this article especially relevant to Linux users is that many chipsets are not properly supported. It's especially disheartening to have your several month-long uptime broken by a hardware AGP bug that locks the machine. This is sometimes common even after chipsets have been available for quite a while; hardware bugs are often the hardest to track down. While Intel's chipsets are often well supported, the features of the 815 have taken until almost now to be supported. Development kernels are required for full ATA/100 support and the on-board/off-board video card duality can cause problems with agpgart, Linux's kernel module for AGP support, unless you use the latest kernels.

So, this brings us to what makes a chipset important to a Linux user. Above all, Linux users value their stability. Hardware bugs and software insufficiencies alike can lessen your uptime to near Windows NT levels. Perhaps next most important is the speed and quality of support for these chipsets. Intel chipsets have always enjoyed quicker support in the Linux kernel, so they have an up-front advantage here, but neither company hides information from Linux developers looking to support new features in the chipsets. Performance would have to fall in last place of these three in terms of importance. The reason being that Linux users don't enjoy the benefit of immediate support for feature X or enhancement Y, they must code support themselves. Thus, support is typically slower to become available and often not as completely implemented or stable as it would be for an operating system that manufacturers find "important."

In this article, we'll try to explain how each chipset performs in memory, disk and AGP performance while bringing up important usage and stability points along the way. Discard what knowledge you have of these motherboards and their Windows performance, under Linux, the varying levels of support can really tip the scales.

AGP Performance: Installation and Issues

We chose to use the NVIDIA GeForce2 GTS for testing AGP performance in this article. This decision is almost entirely based on the results of our last Linux article, the Linux Video Card Comparison, in which the NVIDIA cards dominated largely due to their well optimized drivers. We believe that their drivers better utilize the AGP bus for both 3D and 2D, in which the standard XFree86 drivers do not currently support AGP acceleration.

The biggest issue getting the GeForce2 GTS working was the kernel version issue. NVIDIA's drivers are only supported on specific kernels, of which the 2.4.0-testXX kernels are not included. However, we wanted the newer agpgart kernel support, the ATA/100 support and the more advanced memory management of the 2.4.0-testXX kernels for testing. Fortunately, we were able to find patches to get the drivers working with our kernel on IRC (#nvidia on irc.openprojects.net). With this patch, the module compiled properly and installed without a hitch.

Note that the newer kernels are required to get off-board video working on the Intel 815 chipset. Previously, the kernel module (agpgart) would only identify the on-board video. We are not aware of when this changed, but we were unable to get it working with 2.2.16 in our last comparison, but off-board agp support worked fine with 2.4.0-test11 in this comparison.

The second issue was that the VIA Apollo Pro 133A board would hang whenever starting X. NVIDIA's README file mentions that most of the time that X locks on startup, it's due to an AGP problem. After a bit of testing and re-testing, we were able to get the card working by disabling AGP 4X mode in the BIOS. That should be considered when examining the following benchmarks because the Intel 815 chipset is the only board with AGP 4X support. The other two boards were tested at AGP 2X (or less -- see below). Further, this suggests either incomplete support for the chipset in the kernel or perhaps an AGP bug that has yet to be addressed. This issue has plagued owners of VIA chipsets under other operating systems as well.

Finally, the BX chipset has been around for quite some time and was not originally intended to be used in conjunction with a 133MHz front side bus. As a result, there is no 1/2 multiplier for the AGP bus (although there is a magical 1/4 multiplier for the PCI bus). As a result, the BX benchmarks listed in the forthcoming pages are somewhat misleading because the AGP bus is actually running at 89MHz while the other two boards are running at 66MHz. The 89MHz bus translates to 712MB/s of bandwidth, a 34% increase over the 533MB/s of "standard" AGP 2X. Note that AGP 4X yields a peak transfer rate of 1.06GB/s. For further discussion on AGP standards and performance considerations, see our article on BX chipsets at 133MHz FSB speeds. We don't consider this to be a major problem, however, as this is still a common setup for gamers wishing to stick with their current BX boards, enjoy the extra performance with minimal overclocking, or take advantage of the tried and true nature of the chipset. Further, most cards work fine at 89MHz. The only exception that comes to mind is Matrox's new G450.

In addition, it is not possible to actually see the active AGP transfer mode with the NVIDIA drivers. While the XFree86 drivers allow specifying the AGP transfer rate (1X, 2X, 4X), the NVIDIA drivers set the mode themselves. Even where the AGP support is coming from is a bit of a mystery. NVIDIA's drivers provide AGP support natively in the kernel module (NVdriver) for many chipsets, but fall back to the kernel's standard agpgart interface for others. There is even a rumor that they use the standard kernel module (agpgart) on newer kernels rather than provide the interfaces themselves regardless of chipset. One should not assume that the bus is running at full spec, but rather take the scores as an indication of what is possible currently with the Linux platform and existing drivers.

Again, the BX chipset is running with an 89MHz AGP 2X bus, the 815 is running with a 66MHz AGP 4X bus (which may or may not be fully taken advantage of), and the VIA Apollo Pro 133A is running with a 66MHz AGP 2X bus. Any of these chipsets may be running at either AGP 1X or 2X due to lack of support. Without the debugging information, it is very difficult to verify.

The Test

Red Hat Linux 7.0 Test System
Hardware
CPU(s)	Intel Pentium III 733 EB
Motherboard(s)	Asus CUSL2 (Intel 815 chipset) Asus CUBX (Intel BX chipset) QDI Advance 10 (VIA Apollo Pro 133A chipset)
Memory	128MB PC133 Corsair SDRAM (Micron -7E Chips)
Hard Drive(s)	Western Digital Expert WD 313600 13.6 GB 7200 RPM Ultra ATA 66 (system) IBM Deskstar 75GXP 35.0 GB 7200 RPM Ultra ATA 100 (tested)
Video Card(s)	NVIDIA GeForce 2 GTS 32MB
Ethernet	Linksys LNE100TX 100Mbit PCI Ethernet Adapter
Software
Operating System	Red Hat Linux 7.0 (Linux kernel 2.4.0-test11)
Video Drivers	NVIDIA GeForce 2 GTS 32MB - 0.9-5 (XFree86 version 4.0.1)
Benchmarking Applications
2D	Xmark93 (using x11perf)
3D	Gears Quake III Arena SPECviewperf 6.1.2
Disk	Hdparm 3.9 Bonnie
Memory	Nbench 2.1
Overall	Linux kernel 2.4.0-test11 compilation times

3D AGP Performance: Gears and Quake

Gears

We will start the AGP benchmarks with Gears. Gears is less of a benchmark and more of a dirt simple OpenGL application. That's what makes it great for benchmarking; it's requires no texturing and very few triangles per frame. The result is that it is almost a purely AGP bandwidth limited test. The XFree86 programmers routinely use gears as a means of testing driver efficiency.

Unfortunately, this benchmark did not yield any interesting results. All platforms scored equally well. This is particularly interesting because each supports different levels of AGP compliance and the BX is running at a higher clock than the other two. There must be another factor limiting performance in this case.

Quake 3 Arena

Quake 3 Arena may provide a good real world benchmark of performance, but we're interested in stressing the bus, not the video card. So, the solution is to render at 640x480, thus reducing the amount of fill rate weight on the performance of the application. Yes, this does not provide the realistic usage viewpoint, but increasing resolution does nothing other than make the scores closer and closer. Note that in addition to being limited by the AGP bus, Quake 3 Arena stresses memory bandwidth considerably.

Here, the 89MHz AGP bus on the BX chipset appears to have given the BX a lead over the other two. The 815 beats the VIA by a relatively minor 9% that could be due to AGP 4X vs. AGP 2X differences or a general minor design advantage. The other factor in play here is memory bandwidth. As we will see later, the BX chipset has a very efficient memory controller, which also helps it beat out the VIA in this comparison.

3D AGP Performance: SPECviewperf 6.1.2

SPECviewperf is a large and varied OpenGL benchmark suite. These benchmarks are each supposed to represent a different aspect of research in industry or academia. To be fair, we will test all six benchmarks included with SPECviewperf 6.1.2.

While the Intel chipsets (815 and BX) trade off the lead, the VIA Apollo Pro 133A cleanly loses this round by as much 21%. Again, the VIA is running with the least impressive AGP transfer mode (2X, 66MHz) of the three, but given the closeness of the other tests, we must conclude that this points to a general design shortcoming in comparison to the two Intel chipsets. As the raw AGP benchmarks above all came out fairly uniform, we would assume that this points to a possible issue with memory performance. SPECviewperf is a large and detailed benchmark that stresses the performance of the memory bus as well as the AGP bus. Given the large ammount of data being pushed to complete these tests, it appears that the VIA is caving under increased load.

2D AGP Performance: Xmark

Finally, we consider 2D performance. The NVIDIA drivers actually provide for AGP accelerated 2D rendering in XFree86, while all other drivers (with the exception of the Intel 810 onboard video driver) use PCI transfers. Xmark is our benchmark of choice, as recommended by members of the XFree86 team.

No major surprises here. The BX, with the 89MHz AGP bus, beats the other two by a slim margin. Again, the comparison is almost too close to call but the VIA Apollo Pro 133A places behind both Intel chipsets.

Disk Performance: Configuration and Issues

As mentioned before, one of the reasons we chose to use a newer Linux kernel (2.4.0-test11) instead of the stable releases (2.2.xx) was that it contained better support for ATA/66 and ATA/100 transfer modes. Some of this work is available for older kernels in the form of backported patches, but we wanted it as good as we could get.

Linux kernels have actually generally lagged behind in IDE support more so than in other areas for a while now. There was a time in which SCSI was considered the way to go. Linux then gained DMA transfer capabilities and, in more recent times, support for the newer burst transfer modes. We were able to configure the kernel to run at ATA/100 on the Intel 815 chipset, ATA/66 on the VIA Apollo Pro 133a and ATA/33 on the venerable Intel BX chipset. The hdparm parameters used for the Intel 815 chipset were -c1 -d1 -m16 -X69 -k1, which enables 32bit transfers, DMA transfers, 16 block multisector transfers, UltraDMA mode5, and sets the keep flag (keep settings after an IDE reset). The VIA used -X68 instead of -X69, indicating UltraDMA mode4 (ATA/66). The Intel BX chipset used -X66 for UltraDMA mode2 or ATA/33 support.

Remember that these tests are designed to show disk performance that can be obtained with large block data transfers. This does not reflect average performance, but rather a general theoretical limit. Further, the performance listed in the ATA/XX specs is not meant to be sustained, but rather burst transfer rates. Many benchmark apps are designed to fit within this burst range to achieve the highest possible bandwidth available by the chipset. These benchmarks don't appear to be quite so optimized. Further, it is possible that the Linux kernel in its architecture or implementation restricts throughput to lesser levels than listed in the high speed DMA modes.

All tests were conducted on an IBM 75GXP. This drive supports fully ATA/100 and has a 2MB buffer, making it one of the best performing IDE drives available today.

Disk Performance: Bonnie and Hdparm Benchmarks

We will start with the Hdparm benchmarks because it is perhaps the most ubiquitous disk tool for Linux users. Hdparm provides the mechanism for specifying disk transfer modes used by the kernel. Further, it can test the throughput for both buffered disk reads and cache reads and writes. These tests were conducted using the buffered disk read test, thus measuring actual disk throughput.

We had figured that the Intel 815 and VIA Apollo Pro 133A chipsets would have an advantage over the BX due to their support for higher speed UltraDMA interfaces, which was demonstrated, but that in itself was not enough for the VIA board. The VIA, running at ATA/66, performed only 3.5% faster than the BX chipset despite having the higher performance rating. The Intel 815 cleaned up, performing 52% faster than the BX and 46% faster than the VIA Apollo Pro 133A.

Next up, we will examine the results of the venerable UNIX disk benchmarking program, Bonnie. Bonnie has been around for a long time and is respected, simple and wide spread. These results can be compared against lots of different machines at various locations on the web.

The block transfer modes are the important ones here, as they are limited more by the chipset than by file system. Yes, Bonnie works at the file system level while Hdparm does not. Again, we see the Intel 815 chipset dominating, but by a lesser margin than in the Hdparm benchmarks.

Memory Performance: Unixbench and Nbench Benchmarks

The only real memory benchmark we could find for Linux is part of the Nbench benchmark application, which is a port of BYTEmark for Linux. These are index values, meant for comparison with each other. There is no direct correlation between these numbers and real world performance, but it is nevertheless a useful tool for looking at low level performance.

Nothing really special here. The Intel 815 led each of the others by about a percent.

Unixbench, the all encompassing UNIX benchmark, contains a 'Process Creation' index as well. Process creation refers to actually creating process control blocks and memory allocations for new processes, so this applies directly to memory bandwidth. Typically, this benchmark would be used to compare various implementations of operating system process creation calls, but we can safely use it as a memory index as well.

Here, we see the two Intel chipsets bettering the efforts of the VIA chipset. This is getting to be a growing trend across various aspects of this comparison. This reflects the differences we witnessed when testing the chipset in Windows-land as well.

Kernel 2.4.0-test11 Compilation

Kernel compilation. Most Linux users will have to do it at some point in their Linux career. From a benchmarking perspective, it is interesting for a few reasons. First, it's a real world test. Second, disk, memory and cpu speeds all factor directly into the resulting times. Due to Linux's extremely aggressive caching, disk throughput is less of an issue, but CPU utilization while working with the disk becomes an issue. Further, memory bandwidth becomes the largest factor in overall time as the compiler needs it as well as the kernel's file system cache that is being used to minimize disk reads and writes. We're not going to give this benchmark a category. It's intended to provide a more overall feel for system performance dependent on many parts of the chipset.

Note that we're looking at compilation times here, so a lower value is better. Again, we see the two Intel chipsets outperforming the VIA, although not by an enormous figure. The VIA performed 6% slower than the BX chipset, which posted the fastest kernel compilation time.

Conclusions

Benchmarking under Linux, there are several other factors to consider when looking at these figures. First, these benchmarks are often not as well developed as their Windows counterparts, which means that the figures may not be the most optimal figures possible. Further, the general lack of information surrounding NVIDIA's drivers limits our ability to interpret results as being chipset related or driver related (lack of support, for example).

In general, it is pretty safe to say that the two Intel chipsets outperformed the VIA in all tests except for Disk Throughput, in which the BX lost due to it's age and lack of an ATA/66 or ATA/100 controller. It is amazing in itself that the BX chipset still exists, and even more so, that it can compete very well with such more modern chipsets. That is a major testament to it's design. If you have no need for ATA/100, AGP 4X or a 133MHz bus with standard speed AGP bus, the BX could be a good chipset to consider. However, most people would prefer the 815's ability to maintain a standard AGP bus speed while providing support for the more modern AGP 4X and ATA/100 standards.

Finally, there is stability to consider. The only problem we noticed was with AGP 4X support on the VIA Apollo Pro 133A. While we didn't notice any other lockups during our testing, Linux 3D drivers are often blamed for instability due to chipset bugs that have yet to be found or addressed in kernel abstractions. It is possible that this or a related lockup could happen in other situations. It is also possible that it was simply due to faulty VIA AGP 4X support in either the kernel or NVIDIA's drivers.

Also note that we noticed relatively poor memory and agp performance using the VIA Apollo Pro 133A chipset Windows as well, as reported in this article. This helps supports the claim that the chipset is just not as fast as either Intel chipsets, as separate benchmarks under completely different operating systems both favored the Intel chipsets.

We would have to pick the Intel 815 chipset as the best choice for the Linux user with a Pentium-III at the moment. However, that comes with the warning that one must use a modern kernel to get proper AGP support for this kernel without using the onboard video. That may scare some of the not-so-advanced Linux users away, at least until the distributions start shipping 2.4 kernels, probably sometime early next year. That is, of course, assuming that 2.4.0 gets released sometime in the near future.

Links of Interest:

• Intel 440BX 133MHz Motherboard Roundup (June 2000)
• VIA Apollo Pro 133A & VCSDRAM - Part 2: The Performance
• Linux Video Card Comparison
• SPEC, makers of SPECviewperf
• Bonnie, a disk benchmark
• Nbench, a system performance benchmark