Battlefield 2:
Performance Analysis (Memory, Bandwidth, and Video)
Memory Usage
When the Battlefield 2 Demo came out, I took a quick look at how much memory the Battlefield 2 Demo required, and I also looked at how this might have an impact on disk activity. Recently, I revisited this initial analysis. This time I took a look using the retail version of the game, and I used a system that now had 1.5 GB of memory, instead of 1 GB.
I used the Performance Console, which is included with Windows XP, to capture a log file that recorded how much physical memory was available, what percentage of the swap file was being used, how often page faults were occurring, and how often the hard disk was being read from. The log was set to sample this data every five seconds. The first time around I played the demo for about 75 minutes on a 32 person server; this more recent test was on 50 person server, where I played for about 105 minutes, using the retail version of the game. The Performance Console allows you to display the results of this log file in a graphic form, and this is how I've presented the data, below.
[For more information on using the Performance Console, I've put together a little how-to guide for it.]
The computer that I used was an Athlon XP system with a processor running at 2.3 GHZ and a 256MB 6800GT video card. During the initial test, I was using 1GB (2x512MB) of DDR SDRAM, but during the subsequent test, I was using 1.5 GB of RAM (512MB+1GB). I played with graphics features set to high (except for Dynamic Shadows, which were set to Medium) at a resolution of 1024x768. Audio was set to hardware and high quality.
The graph, below, shows the results from my first evaluation, when I had 1 GB of memory installed. Notice how little unused physical memory is available or free; this is shown by the green line.
The available physical memory virtually reaches zero at one point, and we can see how Windows increasingly uses the swap file in order to free up more RAM. The red line shows the percentage of the swap file that is being used. Although this seems to stabilize after a while, there continues to be a trend for the available memory to decline.
The next graph, below, shows the same information, but I'm running this evaluation with 1.5 GB of memory installed. Although after playing for awhile my available memory again is quite low (100 to 200 MBs), it's lowest point was 126 MB, which is still better than the near zero amount of memory available, at one point, when only 1 GB of memory was installed.
You can also see that the percentage of my swap file in use doesn't really change very much. There are some small increases in the amount of swap file usage, but these coincide with the loading of a new round. (In the above graph, I finish up one round that is already underway, then I play two complete rounds, and I'm well into my next round, when I get disconnected from the server before that round is finished -- that's typical BF2 for you.) So, I don't think we see the same situation as we did with only 1GB of memory; in other words, we don't see the swap file being resorted to as a result of all the available physical memory having been used up.
The reason that we are concerned with whether a program needs to make use of the swap file to store information is because anything retrieved from the swap file is hindered by the relative slowness (compared to RAM) of the hard drive (which is where the swap file resides). When a program can't find what it is looking for in memory (RAM), this results in a page fault, and some of these page faults result in the system needing to access the hard drive to find whatever is being looked for. When playing a computer game, this situation typically is experienced as a hitch or stutter in the flow of the game's action, as everything must wait for the hard drive to provided the needed data.
The graph below illustrates page faults and disk read activity when playing BF2 using 1 GB of memory.
Although there is a fairly regular occurrence of page faults (the blue line), many of these do not seem to be resulting in any disk reads (the pink line), which is good. On the other hand, there are a number of page faults that do require a disk read, and they seem to be increasing a bit towards the end of my playing time. It seems likely that these are the cause of the stutters that I occasionally noticed while playing the game. (The large number of page faults and disk reads at the beginning and the end of the above graph are not really relevant, since they encompass the loading of the game at the beginning and the process of leaving the game and returning to the desktop at the end.)
Below, I have the results for the same factors when running 1.5 GB of memory. Besides the large amount of activity at the beginning and end of the graph (when entering the game and when returning to the desktop), you can easily see the three points at which a new round was started. While the round is underway, there continues to be a steady occurrence of page faults, but for the most part these do not seem to result in any hard drive activity. Typically, you'll see some continued hard drive reads early in a round, but after that it drops away to nothing. There are a couple of little spikes of disk activity towards the end of the first full round, but these are the only exceptions. Compared to the situation with 1 GB of memory, I think we can say that there is less disk reading activity during game play when there is more memory available.
Below, I have combined all the data for each testing session into a graph for that session. It is somewhat confusing to have so many items in each graph, but it does help one to look at the relationships among the factors. I've presented the data from when I used 1 GB of memory in the first graph and the data from using 1.5 GB of memory in the second.
Although the tests described above are fairly simple, I think we can draw some general conclusions about how much system memory is needed to run Battlefield 2. The game is playable using 1 GB of system memory, but the smoothness of the game play will be interrupted, sometimes, by the need to access crucial data stored in the swap file. Increasing your installed RAM to 1.5 GB seems to be enough to prevent the game's data from spilling over into the swap file. While 1.5 GB of memory seems to be enough, I don't think that installing more than this needs to be considered overkill. If you look at the last graph, you can see what appears to be a trend for the available physical memory to continue to decline, which makes me wonder whether you eventually might find yourself out of physical memory even with 1.5 GB installed. Perhaps we are seein that the game has a "memory leak"; that is, it is not freeing the memory space of data that is obsolete or no longer needed. In any case, I think it is safe to recommend 2 GB of memory as a nice round number for the amount of memory to use with Battlefield 2. Most systems require the installation of pairs of memory modules (for dual channel capabilities); so, installing a pair of 1 GB modules is going to be the best solution for most folks.
Network Bandwidth
I was curious to see how much network bandwidth this game required. After seeing how resource hungry this game was when it came to system memory and video card requirements, I was expecting to see some extravagant numbers in this department, as well. However, this really didn't turn out to be the case. The graph below shows the results. (This is from the same session shown in the preceding graphs where 1.5 GB of system memory was being used.)
As you can see, the network traffic stays at a fairly steady rate, about 78 kbps (kilobits per second) on the download side and about 24 kbps on the upload side. While this is more than an analog 56 kbps modem can handle, any DSL or cable connection will have more than enough room for this.
Assuming that this data is simply additive, it is interesting to extrapolate from the above and speculate on how much bandwidth a BF2 server would require. It looks like a 32 person server would need 2.4 mbps (megabits per second) on the upload side and 0.8 mbps on the download side, for a total of 3.2 mbps of traffic. This is a bit more than what two T1 lines (1.5 mbps each) can handle. Of course, the largest 64 person servers would require twice as much bandwidth, which puts the total up around 6.4 mbps of traffic, which is roughly the equivalent of a T2 line (6.2 mbps) or 4 T1 lines. I suspect that these numbers are actually rather conservative and that these servers actually require more bandwidth than what I've just estimated.
Video Options and Frame Rate
I also spent some time taking a look at how the various graphics settings in the game affect the game's performance or frame rate. I ran these tests on the same system mentioned previously (Athlon XP at 2.3 GHz, 6800GT video card, Audigy 2 ZS sound card, and 1.5 GB DDR 420 single channel memory). I ran these tests at a resolution of 1280x960, and I had the Audio options set to Hardware and High with EAX enabled. I used a setting with all the graphics features set to High (except that Anti-Aliasing was off) for the baseline, and then I compare how lowering a setting to something less affects performance. I used the game's timedemo feature to get my results. (See this overclockers.com.au article for more information on how to use the timedemo feature, and see this EA.UK BF2 Forum thread for more information on recording and playing back demos.)
The results are shown below.
Although there is a lot of data in the above graph, if you look at it for a minute, a few things start to stand out. For instance, it looks like some of the settings really don't have much affect at all. These include Dynamic Lighting, Texture Filtering, and even View Distance (this last one is a bit surprising). On the other hand, an option like Dynamic Shadows seems to be quite expensive, in that turning it down significantly improves frame rates (though the Low setting doesn't seem to do much compared to Medium). The Terrain settings also seem to have a significant impact on frame rates. Turning up Anti-Aliasing to 4X is rather costly, in terms of performance, at least on my 6800GT. On the other hand, running all the sound features using an Audigy 2 ZS (audio settings at Hardware, High, EAX Enabled) doesn't seem to have a heavy impact on performance, compared to running no sound at all.
In terms of real world performance, when I'm playing the game online, with the above mentioned system, I'm running the game at 1024x768 and have all the video features set to high, except for Dynamic Shadows set to Medium and Anti-Aliasing turned off. These settings result in an average of 60 fps in the timedemo, and for online play, they seem to provide a pretty good balance between performance and visual quality. However, there are moments when I experience some major frame rate hits with these settings. They don't seem to last very long, and they seem to be somewhat dependent on the map being played and other factors, such as where I am on that map and what is going on at that moment. I haven't been able to narrow down the contributing factors specifically; so, I really can't offer any suggestions to improve this.
Perhaps these frame rate dips need to be considered under the light of the general rule of thumb that says that any sort of average frame rate is bound to be misleading. In particular, it can't provide a sense for the range of frame rates encountered, and with Battlefield 2, this range is fairly extreme. For example, when running the timedemos, the range of frame rates typically went from 2fps up to 110fps. Obviously, it is the occurrence of those very low frame rates (especially the single digit ones) that are of concern to games, since these are the ones that destroy the flow of the game's action.
Some review sites, such as Kyle Bennet's HardOCP, have gone to a method of reporting their benchmark results that de-emphasizes the average frame rates and puts more emphasis on the overall distribution of frame rates, especially at the low end. (See Kyle's explanation of their testing philosophy for more details.). HardOCP is using graphs that show the various frame rates over the course of the benchmark session. Shown below is a similar sort of graph of the result of my "baseline" settings (the first bar in my Video Options Graph), which had an average of 49.9 frame per second.
The above graph is a bit messy (in terms of providing lots of information), and this makes it a bit difficult to take in at a glance, but it does counter the tendency for us to be too easily seduced by the simplicity of an average number from the above data. As you can see, the performance of my system is quite variable over the course of this brief timedemo, which only lasts a few minutes.
(Updated September 15, 2005)