The BIOS
The Phoenix BIOS used in the 915P-T12 is the most current BIOS to date, the Grantsdale-6A79DD49C which was released on July 29th, 2004.
Seeing as the 915P uses a Phoenix Award BIOS, the standard Award features are going to be available, such as advanced BIOS and chipset features, power management, and health status.

Here we see the advance chipset features, where the user can set their RAM timing settings, the Intel PAT mode, turn on and off the PCI-Express ports, and set the PCI-Express compatibility mode.

The Genie BIOS is where all the performance tweaking will be set, excluding the DRAM timing. The FSB can clock up to 380 MHz, although it's doubtful that anyone will ever reach an FSB that high on this board.
The PCI-Express frequency can be left for the motherboard set, or the user can fix the frequency from 100 to 140 MHz.
The 915P-T12 has a wide range of voltage control, the CPU voltage can range from 0.8375 Volts to 1.9500 Volts in 0.05 Volt increments. The DRAM voltage ranges from 2.6 to 3.3 in 0.1 Volt intervals, and the northbridge voltage ranges from 1.5 to 1.8 Volts in 0.1 Volt intervals.

One quirk I noticed was that the field that estimated the CPU clock with the modified FSB was giving me strange numbers, in fact, the frequencies it displayed were exactly concurrent with the wrong offset from ASCII 9, the thousands place in the label would go from : to ; to < and so on through the ASCII values. However, upon rebooting with the FSB modified, the problem is corrected.

Here we see the health monitor provided by the ITE IT8712F.
A note about the PCI bus limitations - before I received a PCI-Express card to use with the PC, I was using a PCI based Geforce 2MX while I was trying to overclock the system, I couldn't get the FSB past 220 MHz. I had originally thought that DFI had enabled Intel's CPU feature that causes the CPU to stop working if the FSB is too high. However I found this explanation somewhat lacking due to the fact that the computer would POST, verify the DMI pool, and only hang while trying to boot with a "no memory present" error. I didn't have the tools to test the frequency of the PCI bus.
Once I installed the MSI PCX5750, the 220 MHz FSB limit was lifted. Regardless of whether the BIOS's PCI Clock auto detect was enabled or disabled, the PCI clock must have increased with the FSB, and unfortunately there are no options for the PCI clock divider.
Subsystem Testing – Audio
The 915P-T12's Karajan audio has 8-channel audio output, and supports the Azalia audio codec. To see just how much load the audio processing put on the CPU, we benchmarked Unreal 2003's dm-Antalus at 640x480 with minimum detail to test the load on the CPU, and 1024x768 with maximum detail to simulate game playing. Sound was turned on and off and the average FPS are used to judge the load that is put on the CPU.
Unreal Tournament 2003: Antalus, Min Detail @ 640x480
|
|
Frames per Second
|
|
Sound Off
|
285.09
|
|
Sound On
|
272.51
|
Unreal Tournament 2003: Antalus, Max Detail @ 1024x768
|
|
Frames per Second
|
|
Sound Off
|
91.48
|
|
Sound On
|
91.43
|
With sound enabled at 640x480, the 915P-T12 takes a 12.85 FPS hit ( a 4 percent performance hit.) However at 1024x768 where most of the load lays on the CPU, the sound processing is almost negligible.
MP3, CD Audio, and in-game sound all seemed to be at least on par with every other integrated motherboard audio solution I've heard, if not better and audio recording was average. Unfortunately there still aren't any motherboards that I know of that have ASIO drivers, so an add-in card might be something to look into for audio production.
Hard Drive Performance
We used HD Tach to gauge read/write performance with a Seagate 120GB Parallel ATA ST3120026A. The drive was tested with a direct Parallel ATA connection, as well as with the Parallel ATA to Serial ATA converter.
|
|
Burst Speed
|
|
Quick Bench (8MB zones)
|
|
|
Without SATA Converter
|
89.3 MB/sec
|
|
With SATA Converter
|
79.4 MB/sec
|
|
Long Bench (32MB zones)
|
|
|
Without SATA Converter
|
83.3 MB/sec
|
|
With SATA Converter
|
79.1 MB/sec
|
With the Parallel ATA to Serial ATA converter on the hard drive, the maximum burst speed that could be achieved was 79.4 MB/sec, a good 10 MB/sec slower than the direct Parallel ATA connection. However, I wouldn't consider this shabby by any means, a decent amount of work goes into converting data from Serial ATA to Parallel ATA and back; I just wouldn't recommend running a system drive off of the converter if maximum throughput is required. With that out of the way, the speeds achieved with and without the Serial ATA converter are quite respectable throughputs.
The CPU usage in each instance was between 1% and 3% - seeing as HDTach's margin of error is 2%, it would seem that the CPU load will be about the same regardless of which ATA mode is used.
Network Performance
DU Meter was used to monitor the network speed, and Task manager was used to monitor CPU usage during our network performance tests. The two sets of files; 1.73 GB of smaller files, and an 834 Mb zip file were used for the small and large file transfer tests.
In each test, the corresponding Ethernet port was connected to a 2.4 GHz P4 in a DFI 845PE Infinity running Windows XP, and 512 Mb of RAM via crossover CAT-5E The 845PE's onboard gigabit Ethernet controller was used.
PCI Gigabit Ethernet
|
Small File Test
|
Avg. Transfer mB/sec
|
CPU %
|
|
Upload
|
12.82
|
5%
|
|
Download
|
15.53
|
4%
|
|
Large File Test
|
Avg. Transfer mB/sec
|
CPU %
|
|
Upload
|
32.11
|
5%
|
|
Download
|
21.79
|
7%
|
PCI-Express Gigabit Ethernet
|
Small File Test
|
Avg. Transfer mB/sec
|
CPU %
|
|
Upload
|
13.22
|
5%
|
|
Download
|
13.90
|
8%
|
|
Large File Test
|
Avg. Transfer mB/sec
|
CPU %
|
|
Upload
|
19.46
|
4%
|
|
Download
|
11.35
|
4%
|
Surprisingly, the fastest upload and download rates achieved were during the large file transfer over the PCI-bus based Ethernet controller. However, the maximum transfer rate for the PCI-Express's large file upload was a whopping 108.72 mB/sec, while the PCI controller's maximum transfer rate was 45.95 mB/sec. For some reason the transfer rates of the PCI-Express controller were all over the place, extremely fast speeds one second, dead slow another. Some Marvell controllers were having problems initializing at gigabit speeds, and while that was not the case in this instance, perhaps the next Marvell firmware will also correct this problem.
Across the board CPU usage was well within its limits if not on the low side, but the transfer rates definitely could have been higher, especially for gigabit Ethernet.
NEXT