![[H]ardOCP](/images/blank.gif){kind=small}
- Date:
- Tuesday , October 14, 2003
- Author:
- Morry Teitelman
- Editor:
- Kyle Bennett
- Google +1
MSI K8T-Neo
The K8T-Neo is MSI’s introduction into the AMD64 world. Pairing up the VIA K8T800 chipset with an Athlon64, this board may be an nForce3 killer...
Subsystem Testing
Audio – CPU Utilization
A recent trend among motherboard manufacturers has been towards creating the all-in-one board. One of the components that can have an immense effect on system performance is the audio subsystem. A quality audio solution will have minimal impact on the system while in use, thus freeing the CPU to work on other higher priority tasks such as scene rendering during an intense deathmatch game. In order to best measure the real world CPU utilization of the audio subsystem, we use Ziff Davis’ Audio Winbench.
The results based on the synthetic benchmark were ok, but nothing amazing. Under most scenarios, the CPU utilization floated between an acceptable 3-4%. However, in some cases the measured value went as high as 6-8%. MSI’s implementation of the Realtek codec seems to be a bit lacking in some areas. Keep in mind that these results are based on a synthetic benchmark, and may not accurately depict performance seen on your home system.
Audio – Subjective Listening
Measuring the CPU utilization offers a good feel for the subsystem operation, but tells nothing of the actual quality of the sound generated by the audio solution. An ideal sound test requires audio covering the entire spectrum, from subtle to intense. For this test, I chose Fear Factory’s album Digimortal. This album is an in your face ride into digitized madness, with a good mix of pulse pounding bass and melodic intrusions.
The audio subsystem’s performance was ok during CD playback. However, the sound reproduced through the speakers sounded off at times, as if there was a latent echo present. No other distortion was detected. However, I would recommend thinking twice about using the onboard sound solution, unless you have no other choice.
Audio – Microphone Port Testing
The MIC-IN input was tested using a Labtec Desk Mic 524. Spoken word was recorded and played back using Microsoft Sound Recorder, with the Microphone Boost option disabled and enabled. The Microphone Boost option is found within the Advanced menu under the Microphone section within the Volume Control menu.
The microphone tests were dismal to say the least. Both with and without Microphone Boost enabled, the sound bite captured via the Microphone port contained an echo and a minimal amount of distortion. With some tweaking, you may be able to get the Microphone port working better, but my recommendation is to seek other solutions if you require a microphone input.
Audio – In Game Testing
In addition to CD or MP3 playback, users most often rely on the audio subsystem for gaming, whether it be for standalone first person shooter type or online deathmatching. To adequately test the quality of the audio subsystem during game type scenarios, we took benchmark measurements with sound enabled and disabled using the following benchmarks: Quake3 Arena and Jedi Knight 2.
The synthetic benchmarks showed cracks in MSI’s implementation of the audio solution, while the in game tests showed major fissures instead. The system performance in Jedi Knight 2 is definitely much better than that shown in Quake 3 Arena, but that does not say much when the results are as mediocre as these. Jedi Knight 2 showed an average frame rate drop of 15%, with the performance while using 333 MHz DDR RAM edging toward 20%. This is nothing compared to the lackluster Quake 3 Arena performance though. With audio enabled, the system performance suffered by 20% with 400 MHz memory and 25% with 333 MHz memory installed. This is a major loss of frame rate, even if you are hitting 150-200 FPS. My recommendation – pass on the on board audio for gaming purposes and seek out a nice PCI-based solution.
USB 2.0/IEEE 1394
In order to adequately test the capabilities of the on board USB 2.0 and IEEE 1394 connections, we chose to use an ACOMDATA HD060U2FE-72-USB 2.0/FireWire HDD connected first to the USB port and after to the IEEE 1394 port in conjunction with TCD Labs’ HDTach program.
In both cases, the performance was mediocre at best. The RAT (Random Access Time) was unusually high for both connection types, normally measured at 19-20ms. The RBS (Read Burst Speed) for both drives was on target, with the USB 2.0 closing the gap on the IEEE 1394a drive. The average read and write speeds were also within expectation, with the measured read speed 5 MB/s higher for the IEEE 1394a connected drive. The CPU utilization, like the measured RAT, was higher than expected. The USB 2.0 normally hovers around 15%, while the IEEE 1394a drive normally measures in at 1-3% utilization. Something seems like it might be not quite right, but not outside of a fix bundled with a BIOS or driver update.
IDE/ATA Performance
System performance relies very heavily on three major subsystems: the CPU, the system memory, and the system IDE interfaces. In order to test the IDE performance of this board, I used TCD Labs’ HDTach program. My test bench currently uses Maxtor 40GB ATA 133 model 6E040L0 hard drives on the IDE headers. On the SATA headers, I have Seagate 80 GB Barracuda SATA hard drives installed in the test bench. Multiple SATA and IDE drives were used for testing in RAID 0, RAID 1, and RAID 0+1 configurations on the Promise controller, as well as RAID 0 and RAID 1 configurations on the VIA VT8237 controller. Testing was also conducted using a standalone SATA drive on both the Promise and VIA VT8237 controllers, and an IDE drive connected in a primary slave configuration as well as in standalone mode on the Promise controller.
Note on all Promise based subsystem tests below: There is a known issue with the Promise controller used on the K8T-Neo and the HDTach drive benchmarking tool which causes wildly inaccurate RBS (Read Burst Speed) measurements, as seen in the tests below. Please disregard the RBS numbers provided for the Promise based results. Note that the issue has been reported, and is currently being researched.
Out of the entire collection of RAID 0 arrays configured with 128k block size, the mixed SATA/IDE array on the Promise controller by far outperformed the rest in class. The SATA only array on the VIA controller had the highest average read score, but the lowest average write score. The SATA and IDE only arrays on the Promise controller had almost matching average read and write scores, but were outclassed by the mixed drive array between 3-5 MB/s. Amazingly enough, all arrays that contained SATA drives scored an RAT (Random Access Time) of below 13ms, which is a decent time. The one negative with the Promise controller was the CPU utilization score. For all configurations, the Promise arrays scored just shy of 20% utilization, while the VIA array scored a bit over 13%. For 128k block sized arrays, the Promise seems to be a better bet due to the extremely low write speed on the VIA controller.
By far the best balanced performing configuration with a 16k block size again goes to the mixed SATA/IDE drive array. The mixed array boasts the highest average write speed, with its closest competitor almost 20 MB/s behind it. However, it lags the pure IDE array in average read speed by over 10 MB/s. We again see the VIA based SATA array matching read performance with the Promise SATA array, but lagging it in write performance by almost 15 MB/s. We also see the trend of the higher than normal utilization across the board on the Promise arrays, with the VIA’s utilization coming in just over 13%. The RAT (Random Access Time) measured for the arrays containing SATA drives continues to hover around 13ms. For the best bang for the buck, it again looks like the Promise mixed array will be the choice to make.
For RAID 1 configurations, the IDE based Promise array was the best performer out of all of them. The Promise arrays all scored above 60 MB/s in the average write speed test which is the fastest RAID 1 write speed scores I’ve seen to date. The RAT (Read Access Time) speeds seems to remain sub 13ms for the SATA only arrays, but jumps to 14ms for the mixed array. The average read speeds were almost half the write speed, coming in just over 35 MB/s for the IDE and the mixed drive arrays, and around 27 MB/s for the SATA Promise array. The VIA array performed more to expectations, with its average read score topping 38 MB/s. However, its average write score was half that, definitely making the VIA a bad choice in light of the Promise based array performances. The VIA’s strength seems to lie in the CPU Utilization department, beating out the Promise based arrays by 7%.
Because the Promise controller supports up to 4 connected drives, you are able set up a mixed SATA/IDE RAID 0+1 array. If you decide to go this route, the 16k block sized array seems to be the best performer. It boasts an average read and write speed of over 50 MB/s, while the 128k block sized array trails by 10-20 MB/s in both categories. The RAT (Random Access Time) for both measured a bit high at 15ms, but not outside the expected due to the fact that IDE drives are part of the array. We also see the unusually high CPU Utilization of 20% for both arrays that seems to plague the Promised based RAID arrays.
We again see the Promise based drives performing on par, if not better, than their VIA based counterparts. The biggest shocker for me was the incredible performance of the SATA drive on the Promise controller. The VIA based SATA drive’s performance is average for a standalone SATA drive. The Promise SATA drive matches it on RAT (Random Access Time), and read speed, but blows it away by almost 25 MB/s in average write speed. Even the IDE primary slave drive lags the standalone Promise based SATA drive’s write performance by almost 16 MB/s. The Achilles heel of the Promise controller seems to be the CPU utilization, as again we see the utilization on both Promise based drives to be hovering around 20%.
Network Utilization Tests
Hagel Technologies’ DU Meter software was used in conjunction with Windows Task Manager to measure the performance of the onboard Realtek Gigabit NIC. DU meter was used to measure bandwidth, with Windows TaskMan to monitor the CPU utilization on the test system. For the test itself, a 750MB archive file containing various sized .WMA audio files for the large file transfer test and 750MB worth of various sized .WMA audio files for the small files transfer test were used in conjunction with an Intel Gigabit NIC on the host system, and a crossover cable to connect the host system to the test system. A crossover cable was used to rule out any possible bandwidth losses due to hub or switch passage.
The Realtek NIC performed well as far as average transfer rate for a Gigabit based Ethernet solution. The average upload was much faster, beating the download speed by 10 MB/s. However, this increased speed comes at an unacceptable cost of an almost 50% CPU utilization, with spikes as high as 60%. The CPU utilization during download was not much better, averaging between 30-40%.
The large file transfer test results identically mimicked those of the small file transfer tests. We again see the unacceptably high CPU utilization for both download and upload as well. MSI’s choice of the Realtek chip seems to be less than optimal due to the high system performance cost incurred while transferring files.