Introduction

These are similar to those in my K6-2 article, but I have made modifications to specifically account for the K6-x+ series.

(a) CPU cooling is critical. being 0.18µ devices, the K6-x+ parts dissipate less energy than their older K6-2/K6-III brethren, which equates to cooler operation. However, they still require a fan and heatsink, and for the overclocker a quality cooling product is a must. Don't short-change your K6-x+ processor just because it doesn't get as hot.

(b) Case cooling is important. Your processor heatsink is very inefficient if the fan only blows hot air onto it. High case temperatures also shorten the life of other peripherals, especially video cards and hard disk drives.

(c) Do not overclock a laptop. File this one with such great axioms as "Do not put car keys into electrical outlets" and "Razor blades should be placed out of the reach of young children." K6-x+ processors can be found in several laptop products, but remember this: Laptops are designed for weight efficiency, yet some processor cooling method must be applied thus adding weight. A balance must be struck, and consequently many laptops operate near their thermal limits. An overclock could apply Very Bad Things to that expensive notebook.

(d) Be aware of the 2x = 6x multiplier remap. Super7 boards peak at a 5.5x multiplier, but the K6-x+ parts continue the tradition inaugurated in the CXT-core K6-2: Set the motherboard to 2x, and the CPU will respond with 6x. You will need this in order to attempt the 600MHz (6.0 x 100MHz) and 672MHz (6.0 x 112MHz) clock speeds.

(e) Know your core voltage limitations. Processor core voltage tolerance decreases as design-rule decreases. All K6-x+ processors are spec'd for 2.0V operation, but as necessary, a higher setting can be used. I would suggest a good rule-of-thumb is that 2.2v and less are reasonably safe, 2.3v are okay but may have long term consequences, 2.4v are questionable, and 2.5v and higher are asking for trouble. This is subjective; others may disagree with my cutoff points. Regardless, use good judgement. A 0.2 or 0.3V increase is a lot for a 0.18µ core.

(f) Don't have unrealistic clocking expectations. As noted earlier, most K6-x+ processors will easily make 550MHz or higher. But, although there are many tales of 600MHz overclocks and upward, your processor may just not "take" at a given setting. Don't assume you are guaranteed xyz speed, and then go nuts on voltage settings trying to make it happen.

The system employed for benchmarking consists of the following hardware configuration:

AMD K6-III+/450 ACZ

Alpha Socket7 fan/heatsink

Shuttle HOT597 (VIA MVP3 chipset, Award BIOS, 1MB cache, ATX form factor)

2 x 64MB PC-100 single-bank SDRAM DIMMs (112MHz capable @ CL2)

Voodoo3 3000 AGP (3dfx Voodoo3 chipset, 166MHz clock, 16MB SDRAM)

Creative Labs Ensoniq AudioPCI sound

Maxtor DiamondMax 4.2GB (5400RPM, 512kB cache)

ATX mid-tower case

200W ATX power supply

Basic keyboard and PS/2 two-button mouse

Seeing as how the advent of low-cost Athlon/Duron platforms has made high performance accessible even to budget-minded consumers, it is probably fair to say that a 'typical' Super7 user either cannot afford a faster machine, or is content with older and/or less-demanding applications. So, in establishing performance trends, it was desired to mix a variety of both older and newer applications with a few purely synthetic tests.

Here I have included several gaming-based benchmarks but no business-application testing suite. Winstone numbers could have been obtained, but the program is heavily dependent on I/O latencies and the test system's slow hard drive would hinder the program.

RC5 is a client program for a Distributed.net project that was established in conjunction with an RSAA challenge to break a 64-bit encryption key. Here the RC5 client used was version v2.8009-460-CTR-00060723. RC5 results reported here are the average of six runs.

RC5 operates primarily "inside" the processor, and as shown here the results tend to scale evenly with processor speed. The scatter-plot is almost linear, although there are slight jumps at the 112MHz bus-based operating speeds. RC5 results scaled upward by 32.9%.

CPUMark is a processor benchmarking utility, released by Ziff-Davis, which performs synthetic tests and then returns a 'rating' number.

The numbers returned were consistent for any run at any clock speed. Note that operating speeds based on the faster 112MHz bus - i.e. 448, 504, and 560 - are rated as being slightly faster than 100MHz-bus based speeds. CPUMark increased by 33.4% across the range of tested speeds.

These synthetic benchmarks are suggesting that CPU performance alone is scaling almost linearly. This is reasonable, since operation "inside" the CPU is determined purely by clock speed. However, as the hybrid and real-world benchmarks will show, once the system becomes dependent on a variety of factors and not just processor clock, bus speed will become a deciding factor.

Sandra is a suite of synthetic benchmarks, and attempts to test optimal performance of a system. Results produced by Sandra have questionable value in cross-platform comparisons, but within a single system Sandra's tools can be useful for purposes of observing performance scaling.

I have run two of Sandra's benchmarks: Processor and Memory. The Processor benchmark returned consistent results in multiple runs, but the memory benchmark was subject strange behavior. First-run results following a reboot would be values that I would expect based on experiences presented in my K6-2 article (which employed the older Sandra 2000 Standard). However thereafter the results would drop a few MB/sec in both ALU and FPU for each successive run. This I cannot explain, and have reported only first-run results for the memory benchmark.

The Processor benchmark appears to scale according to actual processor operating frequency only. No spikes or other anomalies were observed, although the 66MHz bus speed was enough of a hindrance that the 400 (66) scores are just slightly lower than the 400 (100) results. Both ALU and FPU performance in the Processor benchmark increase by 33.4% across the range of tested clock speeds. The Memory benchmark shows, as expected, that the highest bus speeds have the highest bandwidths. This bandwidth will become a much more important factor as we progress into the hybrid and real-world benchmarks.

3DMark 2000 and 3DMark 2001 incorporate a mix of specialized tests and game demos tested at both low and high detail levels, based on Remedy Entertainment's MaxFX game engine. The program then generates a single score based on the results of these various tests. The per-test results can also be reported, but that degree of detail is overkill for our purposes here.

3DMark 2000, being a year older and DirectX 7 compliant, is naturally less demanding overall than the DirectX 8 compliant 3DMark 2001. With either benchmark, some tests required features not supported by the Voodoo3 and were thus automatically skipped. 3DMark by default operates at 1024x768 screen resolution at the highest supported 3D color depth. For the Voodoo3, this is 16-bits-per-pixel.

Already we can see that once we begin to incorporate "real-world" testing conditions, system bus bandwidth becomes important. The 400 (66) setting continues to score lower than 400 (100), but now it can also be observed that speeds based on 112MHz bus (448, 504, and 560) have a distinct advantage. Consider the following:

The jumps at 112MHz-based operating speeds are made more obvious. Although the system scores much higher in the older 3DMark 2000 as compared to the newer and more demanding 2001 incarnation, the increase between 400 (66) and 560MHz is pleasantly close - 28.2% for version 2000, 32.8% for 3DMark 2001. The discrepency between the 2000 and 2001 scores is primarily explained as a video card limitation; 3DMark 2001 requires a fully DirectX 8.0-compliant 3D accellerator (which as of this writing means an NVidia GeForce3) in order to score high marks. Without it, a number of 2001 features are being run in software emulation or skipped entirely. Note, though, that the scaled line graphs show nearly identical behavior, meaning that system performance is reaonably consistent under both benchmarks.

Final Reality is an older Direct3D game. The benchmark/Demo version incorporates a mix of game landscape and vehicle motion, including flight, with 3D shape/effect tests. By current standards the game is not complex; texturing quality and animation detail are distinctly Quake2-ish, although Final Reality goes the next step and adds 3D reflections and some lighting effects, complex mathematical shapes with animated distortion, and a rudimentary fogging effect based on multiple transparency layers. The Final Reality benchmark runs at fixed internal settings and then returns a score in "Reality Marks".

The familiar trend displayed by 3DMark shows up again, with clocks based on 112MHz posting small advantages. Final Reality results increased by 22.0% across the range of tested speeds.

Expendable, the first of our real-world benchmarks, is an older Direct3D game in a third-person shooter format with an angled, overhead view. For eye candy, it incorporates numerous flares and other 3D lighting effects, as well as bump-mapped surfaces, although good artwork and layout are responsible for much of the game's visual appeal.

Though not extremely demanding by Super7 standards, the game's internal timedemo feature is simple to use and returns consistent results. Expendable timedemo was run at 640x480x16, with all other settings left at default. Results are reported as Minimum, Maximum, and Average. I have shown only the 'Average' value is obviously the most significant.

Again, it is readily observed that operating frequencies based on 112MHz bus continue to have an advantage. Here, this is due to the fact that Expendable is not a demo playback, as with many other games, but rather a command list of user inputs that the engine executes. In other words, character AI, item spawns, and so forth are being calculated on the fly; hence the program rapidly and alternately reads from and writes to the system memory, while placing relatively little load on the graphics card. Results scale 30.0% across the tested range of operating frequencies.

Most persons are familiar with the look and layout of the Quake-series games. Suffice to say both Quake2 and Quake3: Arena (Q3A) are OpenGL-based, and the older Quake2 mainly uses colored lighting and transparent water for special effects. Most of the rendering is two-layer based. Q3A is much more complex, employing all the 3D eye-candy that we have become accustomed to in the past couple years, including reflections, flares and other 3D lighting-effects, and 3D fogging.

MDK2 is a newer OpenGL game that brings comic book-styled adventure to a first-person shooter format, although a third-person view of the main character is offered. The demo employs only a modest number of visual effects, mostly based around superb texturing and a few 3D lighting effects including shadows. However, judging by the smoothness of the game's many rotund surfaces, a very high polygon count is being employed.

A 3dfx-specific driver and a default OpenGL driver are offered, but after discovering that that the 3dfx-specific driver returned results only slightly higher than the default device, I opted not to test it so as to remain consistent across all of the benchmarks used in this review. Save for disabling sound, all other settings were left at their default values. Tests were run at 640 x 480, 800 x 600, and 1024 x 768 screen resolutions. The benchmark automatically runs a short timedemo and then reports the average frame-rate.

MDK2 is a little different from the other benchmarks; while bus speed still makes a difference, the game seems to prefer raw processor speed more than anything. 448 only slightly outperforms 450, and 504 does not bite at the heels of 550 as it does on many of the other benchmarks.

Mercedes-Benz Truck Racing is a first-person racing game that simulates the thrill of driving a Mercedes-Benz freight-hauler cab, sans trailer, as fast as possible. This of course means that the vehicles liberally over-steer, so for the beginning racer most of the track-time will be spent either spinning or ricocheting.

The game renders via Direct3D and employs some lighting effects including shadows, as well as transparencies and a high polygon count. Save for disabling sound, all settings were left at their default values, and the game was tested at 640x480, 800x600, and 1024x768 screen resolutions. The benchmark automatically runs a demo and then reports average frame-rate.

MBTR displays the same trends observed in the previous benchmarks, although this game seems to benefit more from bus speed: Note that performance at 504 surpassed that measured at 550.

We have now investigated how the K6-III+ processor performs at a variety of clock speeds in a variety of synthetic and gaming-related benchmarking applications. The numbers returned by the various benchmarks deserve final comment:

The synthetic benchmarks stated the obvious: Performance increases as the system clock speed increases. But these showed nearly linear trends, due to testing only one system element, i.e. the processor. Real-world performance is dependent on more factors than raw CPU speed. As both the hybrid and real-world test demonstrated, bus speed is important. 112MHz bus-based processor speeds tended to equal, and in some cases outperform, faster operating speeds based on the slower 100MHz bus. The logical question would then be, why would a "mere" 12MHz make such a difference?

The increase in bus speed breaks down three ways. First, the FSB, which refers to the transfer of data between the chipset Northbridge and the CPU, is increased. In addition to talking with the CPU and memory, the Northbridge also communicates with the PCI bus, the Southbridge, and by extension all system components. Second, data transfer between the Northbridge and the memory has also been increased. Third, the AGP interface to the graphics card is spec'd for 66MHz operation; at 100MHz, this is achieved by using a 2:3 divider. At 112MHz, the system is still using that 2:3 ratio, which means that the AGP interface is running at (2/3) * 112 = 75MHz.