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.


Looks like we'll go no further with memory timings in this game - it's probably already running as fast as it can go on an Athlon 3500+ and a GeForce 7800GTX. Just look at the results, they're within decimals of each other.


Looks like Serious Sam II is quite sensitive to memory timings, though not in the performance department. We only gain 1 to 2 fps by changing timings and Command Rate. However, it looks like memory timings does have an impact when you're loading a level. So, while 512 MB is enough to play comfortably, you'd want more - just in case. Let's look at what the load times are for these games.

	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
Battlefield 2	156007.67	115587.67	152692	-25.91%	-2.13%
Call of Duty	5202.67	5223.67	5061	0.40%	-2.72%
FEAR	46687	35371	33988.33	-24.24%	-27.20%
Quake 4	67705	66463.67	69854.33	-1.83%	3.17%
Serious Sam II	9843.67	9662.33	9960.33	-1.84%	1.19%
Average				-6.88%	-6.39%

Outside of F.E.A.R and Battlefield 2, load times are pretty similar (1 - 2 % differences). Looks like from these games, only F.E.A.R and Battlefield 2 will really profit from more memory - not just in performance but loading time as well. These games takes longer to load probably because the operating system has to write back the data into virtual memory on the hard disk. Quake 4 and Serious Sam are still very playable on a 512 MB system, but having more memory wouldn't hurt.

Performance - Capacity

Since we had to use not just higher timings but also higher Command Rate as well, the slower results with 4 GB is expected. The good news is that the performance difference is minimal at most. Since this game already runs quite fluidly on a 512 MB system, the additional memory from a 2 GB or 4 GB is wasted and unused.


Again, we're seeing the same story here. We have pretty much the same level of performance from these three memory configurations. One thing to note though, looks like the added memory does seem to help 'stabilize' minimum fps as well. But let's look at how the sequel stands up.


Looks like the best compromise will be to maintain Command Rate 1T while trying to satisfy memory capacity needs of your games. Out of three games so far, it's CAS Latency 3 plus Command Rate 1T that works best. You can still use this combo even if you have 2 1 GB memory modules. If you're planning to use 512 MB modules, make sure they are single banks so you could utilize Command Rate 1T.


Again the same story here, with up to a 4 fps difference from around 98 fps (around 5 %). That's not only insignificant but not noticeable as well. Of course, we haven't look at load times yet, so there maybe still reasons to go for slower, but larger memory modules and capacity.


The differences are even more insignificant in this game. Even differences between runs is less than 1 fps.


The same. Need we say more?


Looks like even 4 GB or RAM isn't going to help the stutter in Lock On. So, there's no point throwing more memory at this game. The stuttering might go away with a faster processor, but there's a slightly less expensive way - turn down some details. It might even bring the average frame rates up. Average frame rates of barely 30 fps isn't that comfortable to play with.


Looks like the same story all over again.


Ditto.


The same.


OK. Looks like games that runs fine on 512 MB will pretty much have the same level of performance with larger memory. Just as we figures, it's the timing and Command Rate that would influence performance on these games. While we do have to make a compromise by using Command Rate 2T and higher latencies (CAS Latency 3), the performance difference is insignificant at most. So, if we were to upgrade to a larger memory, is it worth it to max it out to 4 GB? Let's take a look at these games load times..

	In msec			In percent
	CL 2 1T 256 MB	CL 3 1T 2 GB	CL 3 2T 4 GB	CL 2 1T 256 MB to CL 3 1T 2 GB	CL 2 1T 256 MB to CL 3 2T 4 GB
Brothers in Arms	2215	2123.67	2285.67	-4.12%	3.19%
DS	3955.67	4202	3464.33	6.23%	-12.42%
DS II	8611	8304.33	8296.67	-3.56%	-3.65%
F1	19086.33	17256	18817.67	-9.59%	-1.41%
FSW	14034.33	14352.33	14503	2.27%	3.34%
HW2	4839.33	4858	4803	0.39%	-0.75%
Lock On	39924.67	8820.33	8870	-77.91%	-77.78%
N2003	3394	3186.33	3237.33	-6.12%	-4.62%
RBR	5190	5562.67	5396.67	7.18%	3.98%
SC	1090.67	1599.33	1546	46.64%	41.75%
SW:KOTOR	2230.33	2353.33	3214.33	5.51%	44.12%
Average				-3.01%	-0.39%

Overall, the answer is no. If 512 MB is enough for these games, throwing more memory into your PC won't help, be it 1 GB, 2 GB or 4 GB. However, not all games behave the same. Games like Lock On that loads lots of data into memory will benefit from the additional memory. While other games may appear to benefit from larger memory, in the real world that translates to between 1 to 5 seconds faster when loading - not much and not noticeable. So, it looks like we need to turn our attention to newer, memory hungry games.


Now, that's just plain odd. But of course, Battlefield 2 can throw some wild benchmark results, which makes a real pain to benchmark with. But if you look closely enough, you can see we have much higher minimum frame rates with the 2 GB and 4 GB than with the seemingly faster 512 MB system. And another thing the graphs can't show is how smooth the game runs with more memory - there's no lag whatsoever on both 2 GB and 4 GB systems. Even disconnecting and quiting the game happens pretty much instantenously.


Since this games runs perfectly fine on a 'limited' 512 MB system, it's pretty amazing that having memory in your PC can still push this game to higher frame rates. Of course, you probably won't notice that high a frame rate, but it's nice to have.


Looks the same, doesn't it? Well, look again - you can see we have a lot less differences between runs with larger memory - all of which are slightly above the 30 fps mark. the most gain. Now, all we need to do is look at the load times, but before that, let's take a look at the rest of the games.


Lower memory timings and Command Rate is still the main factor influencing performance in this game. However, what the graphs doesn't show is that with 2 GB and 4 GB, there's no stutter at all on the first run. That's good, since in reality you don't really play the same level over and over again to avoid stuttering.


Despite being a quite 'new' game, Splinter Cell: Chaos Theory behaves pretty much the same whether you have 512 MB, 2 GB or 4 GB with any kind of timing.


Performance graphs are poor indicators of just how smooth a game runs with large amounts of memory. But then again, they're meant to show performance over a span of time (average fps) and of course, can't capture per second frame rates (or with less than a second time measurements). We could display an fps progress graph, however, some stutter occur at random points (Battlefield 2) or occur in less than a second. So, even an fps progress graph can't really capture it. In this situation, a subjective evaluation is more appropriate - we can tell you that from experience during testing and gameplay, 2 GB and 4 GB plays exactly the same with no stuttering as opposed to 512 MB. At least in games that do need the extra memory such as Battlefield 2, F.E.A.R and Quake 4.

Let's look at the load times.

	In msec			In percent
	CL 2 1T 256 MB	CL 3 1T 2 GB	CL 3 2T 4 GB	CL 2 1T 256 MB to CL 3 1T 2 GB	CL 2 1T 256 MB to CL 3 2T 4 GB
Battlefield 2	152692	44108	44903	-71.11%	-70.59%
Call of Duty	5061	4910.33	4987	-2.98%	-1.46%
FEAR	33988.33	3594	3778	-89.43%	-88.88%
Quake 4	256521	19782	19767.33	-92.29%	-92.29%
Serious Sam II	9960.33	8270.33	8198	-16.97%	-17.69%
Average				-54.55%	-54.19%

Well, the most obvious differences will be in Battlefield 2, F.E.A.R and Quake 4. 70 to 90 % less time to load is quite something - from basically 4 minutes to just about 20 seconds in Quake 4. Of course, those savings are actually the same regardless. of whether you have 2 GB or 4 GB. The games (or all applications for that matter) only care about memory larger than what it needs, not how much larger. So, why choose 4 GB? Well, despite what the developers and everyone suggest, some people do like to run other programs on the background when they're playing, particularly if you're online. More programs running at the same time means you have to have more resources, so if you're one of those people, you might want to consider 4 GB instead of 2 GB. After all, the performance difference if you're using an Athlon 64 system is minimal and memory modules are cheap these days. Those who might need that extra bit of performance could opt for 2 GB, probably with 4 single banks 512 MB modules capable of lower latencies (2.5 or maybe 2). They are available, but you have to be willing to pay more money for them than the standard, value oriented modules.

Conclusion:

Having more memory won't provide you with higher performance (lag free gaming), but it will help stuttering issues with some memory hungry games. Only timings does, but your mileage may vary with your processor. However, not all stutter will disappear, only those related to memory. Stuttering caused by loading a map / level or saving a savegame will probably not disappear with having more memory. These are storage related stuttering, and we'll look into solving those issues in another article. As we said before, if you're experience lag in gameplay and you've updated your drivers and apply the latest game patches, you will likely have to use a faster processor and / or graphics card or turn down some details or the resolution you're using to play the game.

With an integrated memory controller, the Athlon 64 is less prone to memory tweaks. Processors with less bandwidth potential such as a smaller cache processor (like the Sempron) or a bandwidth starved one (higher multipliers) will probably benefit more than our Athlon 64 3500+. However, the impact will likely be at most 10%, which is consequently the same performance difference between the Athlon 64 3500+ and it's higher clocked sibling (the Athlon 64 3800+).

Even with lower timings and Command Rate, you will likely experience an increase in performance no more than 3 to 7 percent, with the most gain (overall) is achieved by changing Command Rate from 2T to 1T. Using low latency modules does provide some performance increases, but they either don't have as big of an impact or you have to pay more for these low latency modules.

That said, there are other benefits to having more memory - if your applications and games are able to make use of it. Much less stuttering (what we're focusing on this article) and far shorter load times are what we've shown here today. Newer games are making use of higher resolution textures and more texture layers (texture, specular, normal maps, etc). If you're planning to run games at their highest setting, preferably with a fast, high end graphics card, your PC must have the extra memory to store all those data. 2 GB should be enough for these new games and for most users, but if you can tolerate the slightly lower performance of using Command Rate 2T, you can upgrade to 4 GB. For lag free gaming, we still recommend 2 GB over 4 GB, since games requiring more than that is unlikely to appear within 1 or 2 years down the road.

Go to top