Testbed and Methods
For our tests we assembled the following platform:
- AMD Athlon 64 X2 3800+ CPU (2000MHz, Windsor F2)
- DFI LanParty UT NF590 SLI-M2R/G mainboard;
- 2x1024MB Corsair TWIN2X2048-6400C4 memory;
- Chaintech GeForce 7900 GT graphics card;
- Western Digital Raptor WD740GD HDD;
- Tuniq Tower 120 CPU cooler;
- Sunbeamtech Nuuo SUNNU550-EUAP (550W) PSU;
- WinXP SP2 OS.
We used the chipset driver version 9.35 and the graphics card driver ForceWare 93.71.
Of course, the CPU was overclocked to the maximum that the DFI LanParty UT NF590 SLI-M2R/G mainboard allowed. However at 288MHz clock generator frequency we couldn’t set the memory synchronously as DDR2 800, because in this case its frequency would exceed 1150MHz and it would fail the tests. The memory was set as DDR2- 666 with the working frequency of 958MHz and 4-4-4-12-2T timings.
We ran the tests on this system and then we decided to perform identical tests on an ASUS M2N32-SLI Deluxe mainboard at the maximum CPU speed of 2.9GHz. However this time it was the ASUS mainboard that prepared a surprise for us: the divider setting the memory as DDR2 666 didn’t work.
So, we couldn’t really compare these two mainboards with one another in any way. We couldn’t set the memory as DDR2 800, because its working frequency would be too high, but if we left the memory as DDR2 533 or 400, the lagging because of the lower memory speed would be too high and the overclocked processor wouldn’t be able to make up for it.
However, we did find a way-out here. ASUS mainboard, unlike DFI mainboard, works just fine at frequencies above 300MHz. if we reduce the multiplier but increase the clock generator frequency we will be able to slightly raise the memory speed. The multiplier was dropped down to 9x when ASUS mainboard surprised us again, in a pleasant way this time :) At 9x clock multiplier the divider for DDR2 666 memory setting suddenly got operational - a definite BIOS issue.
As a result, the CPU on ASUS M2N32-SLI Deluxe worked at 322MHz with 9x clock multiplier, and the memory ran at 966MHz with 4-4-4-12-2T timings, i.e. slightly better parameters than those we had on DFI LanParty UT NF590 SLI-M2R/G mainboard.
The tests were run in F.E.A.R. game with default settings using the built-in performance benchmark with graphics and physics set to the maximum. And as for the tests in the game called Faces of War 2, we would like to say a few words about it before we move on to discussing the actual results.
The game Faces of War 2 came out in early fall, although not that many gamers and testers have actually noticed it right away. It is a game about WWII, but not a classical strategy, like the Company of Heroes, where you have to get resources, build troops and send them to battle. It is closer to a tactical game. During the gameplay you control small groups of soldiers or machinery that have to fulfill certain tasks. The graphics and physics in this game are absolutely outstanding.
In fact, even the first version of the game called Soldiers: Heroes of World War II that came out two years ago, was really cool already. The game would load the system so heavily that we had to contact the developers in order to find out if there was a way to record a demo to be later used as a benchmark. They said it wasn’t possible, because all the calculations are real-time ones: the soldier can shoot and hit or miss the target, he may shoot or throw a grenade, etc. however, the new game called Faces of War 2 you are offered a small movie based on the gaming engine before your mission starts where you are told about your task. It means the demo can be recorded and used as a benchmark!
For our testing needs we selected the movie played before the capture of the Walcheren Island mission. This is a real island, it was very well armed and its coastal batteries wouldn’t let Antwerp to function as a port. In the fall of 1944 the allies tried to capture it. We don’t know a lot about those war days and the game is certainly not an exact reproduction of those events, but it was definitely a big battle. This movie is the richest in action and loads the system really heavily: artillery shots, air attacks, explosions, soldiers, etc…
Since the game has now built-in tools to measure the system performance (at least I don’t know of any), we used FRAPS utility to record the fps rates. We ran the tests a few times to see if the results were consistent, and although they differed by tenths and hundredths, we are mostly interested in the integer values obtained.
We selected the tactical game mode, which is a more complex mode than the arcade, and the demo was run a few times. The action in this movie is the same: the landing barges approach the coast – one of them explodes, three aircrafts fly – one of them is hit… However, we noticed, for instance, that the pieces of the hit airplane are always scattered differently and although it falls almost in the same place, it is always a slightly different location nevertheless. In one case it may fall right on top of the artillery device, and in another case it may miss it and the artillery will keep firing. And there was one time when two planes were hit at a time!
In other words, all the actions that ought to happen in this movie are preset, but all the actual events are really being calculated in real time. This is not a once-and-for-all demo, where all the actions have already been precalculated and the system doesn’t have to do much, which is exactly the type of demo we would usually use for our tests. This is an actual calculation of each and every action, real (to the point when it can be considered real in contemporary games) physics, and as a result one of the few real benchmarks out there.