Tech-Hounds.com

The Quest for Lag Free Gaming - Part 1

At one time or another, all of us have complained of too low or choppy frame rates at least once when we're playing games. Low frame rates can be detrimental to the gaming experience, particularly if it happens at that critical moment when you've lined up for a frag and got fragged instead by the one on your crosshair. Naturally, we don't want any lag when playing games, so what can we do? A lot actually, but we must know what cause these problems in the first place.

When most people complain about lag, they either mean too low frame rates or choppy frame rates (stuttering). Actually, they are very different from one another - low frame rates are often caused by the lack of performance from either the processor or graphics cards in your PC. On the other hand, stuttering can be caused by a number of different things. Solving low frame rates problems are relatively easy: either get a faster processor, graphics card or both. A less expensive solution will be to turn down the details and / or resolution of the game you're playing. Stuttering problems are harder to solve - it can be anything from a software bug, either in the drivers or the game itself, to something else entirely. That's why people are always telling you to update your drivers and games with the latest drivers and patches.

So, if even after updating your drivers and applying the latest patches, you still have stuttering - what's next? Barring software bugs and hardware problems, stuttering problems are often caused by the game taking too much time retrieving or fetching data it needs - either from the memory or hard disk. In short, that could mean your PC's memory is too slow or too small. In this article, we look at what we can do to eliminate memory-related stuttering and what's the best solution to have a lag free gaming rig.

A Little Background

First, let's talk a little bit about the PC. Most games and applications you're using (more so if you're using Windows) will be 32 bit in nature. In fact, only until recently did Microsoft release their 64 bit version of their desktop operating system - the Windows XP Professional x64 Edition. There are updated 64 bit binaries for your 32 bit games to be use with Windows XP x64 Edition, but most games are still 32 bit in nature (and don't really benefit much from going 64 bit). Since we're talking about memory, we need to know that a 32 bit application can address (or make use) of 4 GBs of memory. However, most PCs (still) don't come with that much memory - we usually only see PCs with 512 MBs or 1 GBs of memory. So how do they do it?

Virtual Memory

Virtual memory, just like it's name, is not really 'real' memory. Instead, it is a file on your hard disk (or a partition in some cases) used as a placeholder to store data an application otherwise will store in main memory (RAM). It's works something like this: when an application runs, it will request a block of memory from the operating system, but it doesn't always use the entire block. When an application begin to fill the block with actual data and the amount of data is larger than the memory installed on your PC, the operating system will place that extra bits of data into virtual memory - a file on the hard disk. If (or more appropriately when) the application finally retrieves that extra data, the operating system will 'swap' the data in the memory with the one in the file. That's why we sometimes call virtual memory a swap file or page file.

Virtual memory is a must have for every modern, multitasking operating systems. We usually run more than one program at one time, so we will need very large amounts of memory to run them all. Take a look at Windows XP. Even at idle, there are about 20 processes (small applications) running at the same time. These are all 32 bit applications, meaning they can address (or make use of) up to 4 GBs of memory. Without virtual memory (and some creative memory management), we have to install 20 x 4 GBs of memory - a total of 80 GBs of RAM just to have Windows run idle (it's an overly simplistic example). By using virtual memory and memory management, we can get by with much less than that - around 130 MBs. Now, that's a HUGE saving!



Virtual memory does have its limits and these limits can be very 'limiting'. Suppose you only have 512 MB of memory (in addition to virtual memory), but the game you're running is using up to 1 GBs of memory (or more). Even with virtual memory, there's only place for less than half of that in RAM. You'd have to put the rest of it in virtual memory. If the game needs to access all of them at once, the operating system must swap between the RAM and the page file. In this situation, the processor will be able to quickly process the data in memory, but it may have to wait until the rest of the data (in virtual memory) is swapped from the hard disk - the hard disk is much slower than RAM. That's when you'll notice a sharp drop in frame rates - a 'stutter'. Frame rates will go back up once the hard disk finished reading (or writing) and all the data processed. With larger amounts of data, the hard disk will have to spend more time accessing data, so the 'stutter' can take more time. The worst scenario in this case will be if the game needs to access all these data all the time, then the operating system must continually swap data between RAM and virtual memory.



You can see an example of that scenario (or something close to it) in the picture above. For those unfamiliar to games, that's Battlefield 2 running at the highest detail (high resolution texture and geometry) on a 512 MB system. While there is (barely) enough memory to run the game, frame rates does suffer with hard disk access when the operating system is swapping data between the memory and hard disk.

If you look at both pictures, you'll notice they have different number of processes (21 vs 19). Running less processes (or applications) may help, but not if the memory used by one application is way too big (in our example above, it's about 1 GB). That's why game developers usually recommend you to shutdown all other applications before playing their game. That way, the game will be free to use all available memory and processor time. However, in our case, that wouldn't help much. We simply need more RAM.

Larger is better

The next question is how much RAM do we really need - especially to run games. Now, let's take a look at some memory 'footprints' - how much memory and page file used by several games.

	Windows XP	Battlefield 2	Brothers In Arms	Call of Duty	Dungeon Siege	Dungeon Siege 2
Memory available	382.55	39.47	181.18	12.14	287.68	124.56
Memory installed	512	512	512	512	512	512
Memory used	129.45	472.53	330.82	499.86	224.32	387.44
Page file used	172	1032	314	445	256	406
Page file normal	172	172	172	172	172	172
	0	860	142	273	84	234
Total memory used (estimated)	129.45	1332.53	472.82	772.86	308.32	621.44

	Windows XP	F1 Career Challenge	FEAR	Full Spectrum Warrior	Homeworld 2	Lock On
Memory available	382.55	168.9	178.96	365.41	169.41	142.15
Memory installed	512	512	512	512	512	512
Memory used	129.45	343.1	333.04	146.59	342.59	369.85
Page file used	172	355	556	320	373	406
Page file normal	172	172	172	172	172	172
	0	183	384	148	201	234
Total memory used	129.45	526.1	717.04	294.59	543.59	603.85

	Windows XP	Nascar 2003	Quake 4	Richard Burns Rally	Splinter Cell	Splinter Cell Chaos Theory
Memory available	382.55	249.26	13.68	288.52	299.66	78.21
Memory installed	512	512	512	512	512	512
Memory used	129.45	262.74	498.32	223.48	212.34	433.79
Page file used	172	260	656	322	242	415
Page file normal	172	172	172	172	172	172
	0	88	484	150	70	243
Total memory used (estimated)	129.45	350.74	982.32	373.48	282.34	676.79

	Windows XP	Serious Sam II	SW: KOTOR
Memory available	382.55	36.84	266.04
Memory installed	512	512	512
Memory used	129.45	475.16	245.96
Page file used	172	472	266
Page file normal	172	172	172
	0	300	94
Total memory used (estimated)	129.45	775.16	339.96

all numbers are in MBs

You can see that older games usually have smaller memory footprints than newer games - most of them will still fit comfortably within 512 MB of RAM. Higher details (both polygons and textures) means larger amounts of data and larger amounts of memory needs to be accessed. Games with total memory used lower than 512 MB should be (relatively) 'stutter-free' since we don't always have to access the hard disk. Games with memory footprints slightly larger than 512 MB should still be stutter free, since the game may only need small bits of data from the hard disk. For games with larger memory footprints, it would be wise to upgrade this 512 MB system to 1 GB or even 2 GB (like for Battlefield 2) to completely avoid memory related stuttering. Larger amounts of memory, while tempting, is not really necessary. Remember, a 32 bit application (and operating system) can only address up to 4 GBs of memory. The 32 bit version Windows XP does come with a feature that allows it to address more than 4 GBs of memory, but it won't be useful for games (particularly 32 bit games).

Maintaining Bandwidth

OK, you've set your mind up to get 2 GB or even 4 GBs of RAM. Of course, having more RAM means you have to use either larger RAM modules and / or more modules. Larger RAM modules usually have higher timings (higher latencies) and more modules means you have to use a slower Command Rate as well (2T as opposed to 1T). So, if you want to upgrade your RAM above 512 MB, you'll likely have to make that compromise. Lower timings and lower command rate are usually beneficial to bandwidth, so it will be interesting to see whether or not the compromise we make by having more capacity (slightly less bandwidth) is worth the bandwidth loss.

A typical motherboard has 3 to 4 memory slots (DIMM slots) to hold memory. Most modern chipsets such as the NForce 4 or VIA K8T800 cam support up to 4 GBs of RAM. So if you want to have 4 GB, you need 4 modules of 1 GB, preferably PC3200 DDR SDRAM modules. If you're shooting for 2 GB, you could either use 4 modules of 512 MB or 2 modules of 1 GB. The difference will be the command rate - the 1 GB modules may be dual bank modules so you'll have to use 2T instead of 1T. The other difference will be latency: 1 GB modules usually comes as CAS Latency 3 modules, while 512 MB may come as CAS Latency 3, 2,5 or 2 (if you're willing to spend the money).

Lower Load Times

There is one other metric we wanted to address in this article that while it doesn't affect gameplay performance, you as users will appreciate too: load times. By having more memory, the game will be able to make use of the additional memory and load all the data it needs entirely in RAM. This could make load times shorter. At least in theory. Take a look at this example: if an application has 640 MBs of data to load at one time on a 512 MB system, the rest (about 128 MB) will be written back to virtual memory (hard disk). Now, the game may not need all that data at once, so the additional data can be loaded in background while we're playing (without causing a stutter). However, during loading, the operating system must write back the data into the hard disk, adding more time to the loading process. In this situation, having more memory provide extra benefits that performance testing alone can't show.

Performance

Since we're basically evaluating system performance here, it's critical to test these games under settings which will best show performance differences with various memory configurations (capacity and timing). However, at the same time, we want to use settings people ordinarily use when they're playing games - not something like 640 x 480. So, we settle for our usual test setup equipped with a reference clocked GeForce 7800GTX. This graphics card is system limited with this setup, so it will be perfect. In addition to that, we only test using a resolution of 1024 x 768, 32 bit - no AA, AF or any other settings are enabled that will make the games graphics limited. This means not enabling HDR on Splinter Cell: Chaos Theory and Serious Sam II, no Ultra Settings in Quake 4, or Soft Shadows in F.E.A.R. All other settings are maxed out - full detail.

We'd like to thank both Tagan and Kingston for supplying with the additional power supply and 1 GB memory modules for this article. A little side note: these KVRX40064C3A/1G with Hynix chips is quite good for their price - able to run at CAS Latency 2.5-3-3-7 with SPD settings on our motherboard. That's remarkable for a value oriented 1 GB module (though the official spec is CAS Latency 3)..

Our test setup
AMD Athlon 64 3500+ socket 939
2 x 256 MB Kingston KVR 3-3-3 PC3200 DDR-SDRAM
4 x 1024 MB Kingston KVR 3-3-3 PC3200 DDR-SDRAM
MSI K8N NForce 4 SLI motherboard
ASUS EN7800GTX TOP 256 MB GeForce 7800GTX graphics card
(running at reference clocks - 430/600 MHz)
Maxtor DiamondMaxPlus9 80 GBs Serial ATA 8 MB buffer
ASUS E-616 DVD-ROM
450 watts ATX power supply
Tagan TG530-U15 530 watts ATX/BTX power supply

Windows XP Professional with Service Pack 2 installed
NVIDIA Forceware 81.98 reference driver
NVIDIA NForce 4 6.70 reference driver
Creative SoundBlaster Live! 24 bit 5.12.1.512 driver.
DirectX 9.0c

Performance - Timing

The results:

These are raw test results and so variations between runs are expected. These variations range from 6 to 9 fps, but only for the minimum fps. Even with the variations, the frame rate is still high enough to play games comfortably, despite the rather large difference with average frame rates. That means no stuttering. Overall, we can see setting CAS Latency to 2 combined with Command Rate 1T is providing us the highest frame rates, although the difference in real life is not really significant (around 1 to 3 percent). Oddly enough, setting CAS Latency to 3 and Command Rate 1T gives us slightly slower results than with Command Rate 2T.


With these results, we see a more 'normal' story. Just like we expected, using lower timings and Command Rate does boost memory bandwidth. We gain something like 3 to 5 frames overall. As for stuttering, the minimum frame rates are pretty low, but they're still around the 30 fps mark, so you won't really notice it. Most stuttering issues with this game are hard disk related, so we won't accomplish much with just memory tweaks.


In Dungeon Siege II, we see very little differences between memory timings. Despite using the same engine, this sequel to Dungeon Siege uses a lot more objects so bandwidth and memory may have little to do with performance here. Stuttering does happen, but again they are mostly hard disk related and there's nothing we can do, memory wise. From experience, we know even with higher resolutions and AA / AF enabled, the results stay pretty much the same (with the GeForce 7800GTX). This game is definitely system limited by default and only a faster processor can push higher frame rates in this game.


Although this game is quite old, it still a very good benchmark, both for system and graphics benchmarks. Here, we see slight differences between memory timings, with CAS Latency 2 and Command Rate 1T giving us higher overall frame rates. However, we see setting CAS Latency to 3 and Command Rate to 1T gave us the most gain. There is almost no variance between runs, and you can see minimum frame rates are still high enough for fluid gameplay. So, no stuttering issues in this game.


Although using CAS Latency 2 and Command Rate 1T gave us higher frame rates, we gain the most frame rate with CAS Latency 3 and Command Rate 1T. However, we must also note that the gain seems to be on the high side, so that's not much of an improvement. With memory use still within available RAM (512 MB), there's no stuttering in this game, you can see the minimum fps is still high enough for fluid gameplay.


Here, we're seeing a similar situation to Brothers in Arms. CAS Latency 2 and Command Rate 1T are not only giving us the faster frame rates, but also the most gain. The differences may seem big but they're not really that significant since we're already getting high enough frame rates (who needs 200 fps anyway). Again we can see most of the gain seems to be on the high side, although there are some differences on the minimum fps as well.


The most interesting thing from this benchmark is the minimum fps. With each successive run, we have a higher minimum fps. While minimum frame rates stays pretty much unplayable even with CAS Latency 1 and Command Rate 1T, we can see this setting 'cope' better with stuttering issues. Even so, stuttering is still present, and actually expected since the memory footprints slightly passes the 512 MB mark (around 600 MB), so the stuttering we see here might be gone if we were to have more memory. But we'll have test it again to be sure. Let's move on.


With just 1 fps separating the results, it's obvious this game is system limited and no amount of memory tweaking will provide us with higher frame rates. We simply have to use a faster processor. Variations between runs are minimal, but since we're only going round and round a race track, that's to be expected. All the game's data can still fit comfortably in a 512 MB system.


Unlike the two other racing simulation, Richard Burns Rally uses a rally stage instead of a race track. Even so, most of the game's data can still fit into a 512 MB system, so no need to fetch data from the hard disk. Looks like there's enough data being pushed that it shows a difference with lower timing and Command Rate. The most gain is seen with CAS Latency 3 and Command Rate 1T, although using CAS Latency 2 and Command Rate 1T does provide us with a very small increase (1 fps), which is not really significant and can still can come from normal variances between runs.


The original Splinter Cell pretty much paints the same picture. In a way that's good - even users with value memory can still push their memory to achieve slightly higher frame rates without changing their memory timings. But in all honesty, you really don't have to, since frame rates are already high enough. even with the default timings we've used (3-3-3-8-2T).


No significant or even noticeable differences here. The results are really too close to call which configuration has the higher frame rates. Overall, using CAS Latency 2 with Command Rate 1T seems to give us the highest frame rates, but again, it's really to close to call.

Now, we've seen the performance numbers from games with memory footprints still within 512 MB or slightly above it. Although CAS Latency 2 and Command Rate 1T theoretically should give us the higher frame rates, it's not always so. Sometimes, changing Command Rate from 2T to 1T is enough. This is most probably because we're using an Athlon 64, a processor with an on-die memory controller. Integrating the memory controller into the processor save enough cycles, that changing latencies will not give us that big of a boost. So, what about load times?

	In msec			In percent
	CL 3 2T	CL 3 1T	CL 2 1T	CL 3 2T to CL 3 1T	CL 3 2T to CL 2 1T
Brothers in Arms	2270.33	1853	2215	-18.38%	-2.44%
DS	4221.33	3237	3955.67	-23.32%	-6.29%
DS II	8855.33	8776.33	8611	-0.89%	-2.76%
F1	19409.67	18072.33	19086.33	-6.89%	-1.67%
FSW	14496	14219	14034.33	-1.91%	-3.18%
HW2	5183.67	6147.33	18.59%	-6.64%
Lock On	39541.67	39051.33	39924.67	-1.24%	0.97%
N2003	3460	3195.67	3394	-7.64%	-1.91%
RBR	6137.33	5044	5190	-17.81%	-15.44%
SC	1671	1044.67	1090.67	-37.48%	-34.73%
SW:KOTOR	2754.33	2320.67	2230.33	-15.74%	-19.02%
Average				-10.25%	-8.46%

Since time is the metric here, lower numbers are better and negative percentage values means less time loading. Overall, we still see the most improvement just by changing Command Rate from 2T to 1T (-10.25 %). On a game-per-game basis, the improvement can be less or a lot more - up to around 15 to 20 %. Of course, that might just be jittery fingers. In actually, the games with the most decrease in loading times are already pretty fast - around 5 seconds or less.


While it is tempting to jump to the conclusion that CAS Latency 2 and Command Rate 1T is mostly responsible for these results, that doesn't necessarily be true. Particularly since we're seeing a lower minimum fps and a much higher maximum fps. Under the same load, it looks like changing Command Rate won't do much in this game. But what's more important of all, this game still stutters like hell for about half a minute or so with a 512 MB system. Only when the hard disk stopped trashing around, do we have a somewhat stable frame rate. So, Battlefield 2 can still be ran at high details on a 512 MB system (if you're patient enough).


A much more older, but more stable game, Call of Duty is keeping to the tradition of the game engine it uses - Quake III Team Arena. This engine (and of course most games based on it) is very sensitive to changes in processor clocks, front side bus and memory timings. Here we see the same ting as before: changing Command Rate to 1T alone is enough to boost frame rates.


These results maybe too close to call, but we can see a trend - lower timings and Command Rate does boost performance (slightly). Looks like it might even be handy to boost minimum frame rates as well. But with frame rates that low, you'll definitely can still see stuttering time to time in F.E.A.R. So, it looks like this game also can use the memory upgrade to at least 1 GB.


You really have to hand it to both id and Raven, even with all the details in Quake 4, the game still runs smooth and behave predictably with each run. Of course, using a GeForce 7800GTX helps. We can definitely see the same trend here: Command Rate 1T is enough to gain just a little bit of performance. However, these are actually results from second, third and fourth runs - in the first runs, stuttering happens (predictably) at some parts of the level. So, if you really want to eliminate stuttering in Quake 4, you should use more than 512 MB of RAM.