![[H]ardOCP](/images/blank.gif){kind=small}
- Date:
- Tuesday , August 04, 2009
- Author:
- Daniel Dobrowolski
- Editor:
- Kyle Bennett
- Google +1
MSI 790FX-GD70 AMD Motherboard
The MSI 790FX-GD70 looks to be another winning product for MSI. It's a feature rich solution designed for AMD's socket AM3 processors using DDR3 memory with the overclocking enthusiast in mind.
Subsystem Testing
NOTE: For all Subsystem Testing, an AMD Phenom II X2 550 (3.1GHz) Black Edition and 2 x 2048MB Corsair Dominator TR3X6G1600C8D ver 2.1 DDR3 1600MHz (8,8,8,24,1T @ 1.65v) memory modules running at DDR3 1333MHz (ganged mode) were used. The CPU was cooled with a Corsair Nautilus 500 paired with an Swiftech Apogee GT water block.
Sound Hardware
The MSI 790FX-GD70 is using Realtek's ALC889 audio codec. The ALC889 is an 8-channel solution which delivers 2ch 24-bit / 192kHz or 5.1ch 24-bit / 96kHz sound. MSI refers to this as True Blu-ray Audio. (Got to love marketing guys.) At any rate it is a capable yet software driven codec. While better hardware exists, as far as audio solutions go, one could do worse than the ALC889.
Audio – Subjective Listening
For subjective listening you want to listen to something that covers a range of sound types. For this portion of the review I went with Disturbed, Indestructible.
The ALC889 worked as it should. CD audio playback was flawless as expected. No hissing, popping, or other distortion was heard.
Audio – Microphone Port Testing
The onboard audio MIC-IN port was tested using a Logitech Internet Chat Headset. Spoken words were recorded from the Windows Sound Recorder found under the Accessories\Entertainment folder in the start menu within Windows XP. The recording was made with the Microphone Boost option disabled, then enabled. The Microphone Boost option is found within the advanced menu under the microphone section within the Volume Control Menu.
The microphone recording sample had a low volume level with the microphone boost option enabled. With the option enabled, the sample was audible, but distorted. This is a fairly common occurrence with onboard audio and is expected. Serious recording professionals will add in their own sound hardware anyway so this is of little concern for most people.
Drive Performance
To test the capabilities of the on board USB 2.0 connections, we used an ACOMDATA HD060U2FE-72-USB 2.0/FireWire HDD connected first to the USB port. SATA and IDE drive tests were performed using Western Digital Raptor WD1500ADFD hard drives on the primary SATA header and Samsung 40 GB SATA 3G with NCQ hard drives on additional SATA headers. The SATA drives were used for testing in RAID 0 16k block size configurations on all applicable controllers. Testing was also conducted using a standalone SATA drive on all applicable controllers, and an EIDE drives connected in a primary slave configuration on the appropriate controller All drive benchmarks were done using the open source Iometer program.
Unfortunately the SATA/RAID controller built into the SB750 and the JMicron controllers both caused me quite a bit of trouble. I was able to configure a RAID0 array for installing the OS on. After that is when the problems started. I was not able to get my Samsung Spinpoint drives to function on either the JMicron 322 or the SB750 in AHCI or RAID mode. I could get the RAID array configured on the SB750, but the system wouldn't actually write to it. I also couldn't get a single drive, or a RAID array even created on the JMicron 322 using the Spinpoint drives. I wondered if it was my OS (I test with Windows XP SP3) so I loaded up Windows 7 RC build 7100 on a spare drive. (Maxtor Diamond Max 10 300GB SATA 3G.) I had no problem with that drive, but still couldn't get the Spinpoint drives to function either independently or in a RAID array. So it didn't appear to be driver related.
Finally I utilized a couple of spare Western Digital Raptor WD1500ADFD drives and gave them a shot. Those worked but not without issue. When you run IO Meter on a volume for the first time it creates a work file. This file is the full size of the drive or array. In this case the file should have been 300GB. After an hour it was only 53GB. Needless to say something was screwy. (Editor’s Note: I do not find that to be unusual IOMeter behavior.) So I stopped the drive preparation and ran the test again. If you do this the test will run anyway without increasing the size of the work file.
In other words, while I believe the test results to be fairly accurate as I've found little difference between a larger work file and a smaller one from an aborted drive prep, the test results here are not comparable to those in any of our other articles. Essentially the only value in this test is confirmation that the RAID controllers worked. Though again, they only worked partially. The JMB322 doesn't even give me an option to place it in RAID mode or configure an array in its own BIOS. As a result, only AHCI single drive tests could be performed.
Interestingly enough the combination eSATA / USB port worked flawlessly as an eSATA port. The eSATA port is attached to the JMB322 and as a result it can be placed in RAID mode with the internal "blue" ports. What does it all mean when you get down to it? Well essentially the RAID controllers were a huge pain to work with. More pain than I've "enjoyed" in a couple of years now. This implementation just seemed "bad" all the way. One other issue of note that I discovered accidentally.
I was looking at erasing my Intel X25-M SSD's after hours of testing them quite separately, and decided to put them on the test system using the 790FX-GD70 to do it as I didn't want to bother messing with cabling in my gaming or work rigs. So I connected them up and booted from a CD with the HDDErase v3.3 utility on them. One of the requirements of this utility is that the drive controller be placed in IDE and legacy support be enabled. Well the controller can be placed in IDE mode, but no legacy feature is present and I wasn't able to use the HDDErase v3.3 tool on this machine. You have to use one of the first four SATA ports, which I did, and it is suggested that the optical drive be on port 4 and your SSD's on 1, 2, or 3. Which I did as well. I covered my bases as best as I could and still no luck. So Intel X25-M owners need to be aware of this potential issue. I threw the same SSD's into an X48 / ICH9R system and of course had no issues with the procedure I described above.
Network Utilization Tests
Hagel Technologies’ DU Meter software was used with Windows Task Manager to determine the performance levels of the onboard network interface. DU Meter was used to measure bandwidth and transfer speeds, while Windows Task Manager monitored CPU utilization on the test system. For the testing, a 750MB Archive file consisting of several compressed WMA/MP3 files was used for the large file transfer, and 750MB worth of MP3/WMA files were used ranging in sizes from 3 to 30MB was used for the small files transfer test. The test was performed using a plenum rated category 5e crossover cable to bypass any traffic, routing or other transfer issues and possible packet loss or corruption that can be caused by a router/switch or hub. The cables were connected between two test machines, one using the onboard NIC(s) of the board being reviewed and the other is an Intel EXPI9400PT 10/ 100/ 1000Mbps PCI-Express Gigabit Ethernet adapter installed into a test machine using an Intel DX48BT2 motherboard.
MSI chose the Realtek 8111DL PCI-Express 1.0a Gigabit Ethernet controller for both network interfaces. They are capable of 10/100/1000 speeds and offer full and half duplex operation and support adapter teaming.
LAN1
The small files download test showed a maximum transfer rate of 74.16MB a second and an average transfer speed of 57.58MB a second which is quite excellent. What isn't excellent is the horribly high 27% CPU usage that went with it. I ran the test three times to be sure, but in each case the CPU usage bounced from 17% to 50% averaging right around 27%-30%. I can't remember ever seeing CPU usage this bad on any board's integrated LAN. The small files upload test showed a peak transfer of 46.12MB a second with an average of 24.25MB a second. This isn't bad either and for a Realtek solution, it really is pretty good. This time the CPU utilization was better, but not good at 18%. It was all over the place too, but settled there for the most part.
The large files download test showed much lower performance than the small files download test did. Peak transfer speeds were a solid 47.19MB per second which is respectable but the average fell to 35.19MB a second. This still isn't too bad and is in fact better than the Realtek 8111C I'm used to seeing. It would seem that transfer rates on the Realtek 8111DL have improved over the "C" model, but again the cost was CPU usage. It came in at 23% in this test. Again the CPU usage fluctuated like mad but averaged at about 23% most of the time. I saw spikes upwards of the low 40% range at times. It never dropped below 17% which is still not all that great. The large files upload test yielded similar results with 40.68MB for the maximum transfer rate and 20.52MB a second which is more in line with the Realtek 8111C. CPU usage was the lowest I saw before at about 17%. I saw spikes in the high 20's and as low as about 13%. Not bad, but not good.
LAN2
The results of the second LAN port were nearly identical to the first in the small files download test giving a maximum transfer rate of 74.85MB a second and averaging 57.90MB a second. CPU usage was 25% which brings this test in line with the results achieved on the first LAN adapter. The small files upload test was again more of the same. The peak transfer rate was 43.56MB a second and the average was 25.99MB a second. CPU usage was only 19% which isn't the worst I've seen.
Just as it was with the small files download test the large files download test had a peak transfer rate which was decent at 75.95MB a second. The average fell in line with expected results at 56.10MB a second. CPU usage was ridiculously high at 46%. The large files upload test was much slower maxing out at 36.69MB a second and averaging 21.12MB a second. CPU usage hovered around 23%.
Certainly the Realtek 8111DL has the potential to out perform the Realtek 8111C that is so common on today's motherboards. Unfortunately it seems to do so at a cost of very high CPU usage. Hopefully this is a driver issue and nothing more. I'm running Windows XP SP3 at this time on the test systems, so it is possible that Windows Vista users will find a better balance of performance or even better, similar speeds, with less CPU usage.
Test Systems
The following system configurations were used for the Sandra memory benchmark graph, as well as all graphs listed under the Application and Gaming Benchmarks sections:
Graphs are labeled as follows: Motherboard - CPU Clock - FSB Clock - Memory Clock
Sandra Memory Bandwidth Buffered Integer
Note that all results above were obtained running the installed memory in Triple Channel mode, except of course for our AMD system which only supports dual channel DDR.
It shouldn't come as a surprise but the Phenom II's integrated memory controller just doesn't have the memory bandwidth the Core i7 does even when you allow for a third channel on the Intel Core i7 machines. We suspect the upcoming Core i5 with dual channel DDR will easily handle the Phenom II as well. The results are where they should be, and as we all know, memory bandwidth isn't everything.
Sandra CPU Dhrystone ALU (2009 v1542)
The performance looks low here, but again, it really isn't. The Phenom II is simply outmatched by the Core i7. The 790FX-GD70 is working properly, and that's what we are showing here.
Hiper Pi v 0.99B
In Hiper Pi, there are no surprises. The 790FX-GD70 performs as it should.
wPrime v2.00
The results here are actually quite good for the 790FX-GD70. The results here actually best results we've seen from the Core 2 Extreme QX9770 which is no small feat.