Test Results

The two client machines used for the test included:

• Machine 1 - a 2.9 GHz Pentium 4 with 512 Mbytes of RAM, running an R1Q2 Quake 2 client in OpenGL mode at 1024 x 768 resolution
• Machine 2 - a 1.3 GHz Celeron with 512 Mbytes of RAM, running a stock 3.20 ID client in software rendering mode at 1024 x 768 resolution

Here is a summary of the results:

Compile Optimization Conclusions

The above results show that there is no significant ping difference between the gcc -O2 and icc -O2 behavior during relatively inactive periods, put perceived lag on the client side is reduced somewhat. Similarly, frame drop warning rates and recovery times after stress events are mildly better with the icc compiler. Results are somewhat more significant when going to a -O3 optimization level and even more dramatic when including the processor targeting options -axN and -axP.

The above tests are not a perfect model for behavior in a dynamic environment, where players will be connecting from across the company or across the globe. But they do serve to demonstrate the opportunity for improvement.

Clearly, ping is not the only measure of performance. While the improvements made to the test programs did improve ping somewhat, most of the impact was seen in the server's ability to maintain smooth gameplay, or to restore smooth gameplay after periods of intense activity. And this is what it is all about.

Additional Steps to Improve the Binaries

The gains demonstrated above may be significant enough for some. If still more performance improvement is required, there are a number of additional steps that can be taken. While these steps are beyond the scope of this article, they are worth mentioning as areas of future exploration, especially for developers of new game offerings.

One of these steps is to apply profilers to determine where the hotspots (bottlenecks) are in the game server program. Tools such as Intel's VTune Performance Analyzer product can be employed to locate the sources of program slowness, identify key algorithms that can be improved, and point toward other opportunities to optimize program behavior.

Another approach that can work hand in hand with performance analysis is addition of threading techniques to the software. Individual hotspots in the program can be threaded, using available threading libraries and new or modified code, to streamline program operations and to take advantage of the performance gains offered by new dual core processor technologies.

Other Ways to Improve Server Performance

There are, of course, fundamental things that a game server administrator can do to ensure that the game being hosted is optimally configured and makes best use of all the work that went into coding and compiling it well. Several key server configuration parameters may be adjustable for a particular game, significantly impacting overall performance. While these vary from game to game, they can include:

• Practical player limit (i.e. don't let the user adjust this number past their purchased limit or sell player count limit packages that exceed the game engine's ability to deliver)
• Hard ceiling to connected ping of players (i.e. players with ping greater than a specific limit are not allowed to connect or are disconnected during game play to protect playability for the rest)
• Limited bandwidth or disabled downloading of maps, models, audio, and other optional "level-specific" content.
• Limited bandwidth or disabled uploading of player-specific content, such as "skins" and "sprays", where such features are supported by the game.
• Cap on frames per second performance (may be expressed as max number of player updates per second)

A last option: you can always change the game. A novel approach to minimizing server performance impact from level-specific content download, adopted by Richard Stanway in his R1Q2 package, involves outsourcing of map / texture / audio downloads to an HTTP server. This means that the map download function can be optionally offloaded to a separate system, perhaps one on a separate subnet to minimize network impact, with transfers running at a higher UDP data rate than the game's existing TCP connections can support. The downside to doing this with an existing, released game is that it will probably require client-side changes as well. This sort of approach would work well applied to the design of a new game server engine, and could readily be applied to a rewrite of an existing engine where the server code has been released to the Open Source community.

This type of distributed data transfer between the game server and the client is also another excellent application for threading techniques. In environments supporting several Massive Multiplayer servers, these could even be scaled up to support deployment in clustered environments, with specific components of the cluster performing particular aspects of client updating and content download activity.

About the Author

Doug Helbling is a software engineer for Intel's software development product deployment team. He works to develop Linux product delivery solutions, various game mods and case studies. His latest project includes an optimization study of GarageGames' Torgue engine.

1) Webmin web-based interface for system administration http://www.webmin.com

2) Intel C/C++ compilers and related software products http://www.intel.com

3) R1Q2 Quake 2 release http://www.r1ch.net/stuff/r1q2