This is part 3 in a series.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment
3. Understanding the Netgraph (You Are Here)
   
4. Optimization Guide
5. Everything else advanced and so far not covered

The Netgraph: Friend or Foe?

net_graph 3 can be either your best friend or your worst enemy. It provides priceless data on exactly will either optimize your experience or drive you crazy. Understanding the netgraph is the key to the former and a little restraint is the key to avoiding the latter.

First things, first - What is the netgraph and how do I get to it?

To enable the netgraph,  open your console the via ‘~’ key and type net_graph 3. It’s that simple. In the bottom of the right hand corner, you should now see something that looks like this:

Looks rather daunting. Some of the numbers are self explanatory, but most are fairly cryptic.

Decrypting the Netgraph

To help understand the netgraph, I have borrowed the infamous labeled netgraph from Whisper’s Wiki

The numbers mean the following:

1. fps: Client side FPS. This is how many frames per second the game is producing at this giving moment in time. Anything above 60 is not important in a visual sense, due to monitor refresh rates and limitations of the human eye. But as I mentioned yesterday, client FPS limits your ‘out’ packets.

As you can see in #5, the FPS is limiting the out to 78.6packets/s even though cl_cmdrate is set higher.

2. ping: is the average time in milliseconds for round trip time for packets. Meaning, it is the time it takes for you to send and then receive a packet from the game server. Keep in mind this is just the raw time for you to the server. It does not includes any client or server calculation times.

Keep in mind net_graph ping differs from scoreboard ping. Scoreboard ping is a one way calculation, net_graph is roundtrip.

3. in: Size, in bytes, of the last incoming (server to you) packet (snapshot) received by the client.

out: Size, in bytes, of the last outgoing (you to server) packet (snapshot) sent by the client.

In all honesty, 3 is worthless. There is no way to effectively influence these numbers, so you might as well forget about them.

4. in: Average incoming bandwidth in kilobytes/sec

out: average outgoing bandwidth in kilobytes/sec

4 is also worthless. As long as these numbers look relatively proportionate to the numbers you see above, you have nothing to worry about.

5. in: Average packets (snapshots) being received (server to you) per second.

This number should be very close to your cl_updaterate setting. There are times when it will be different:

Good Examples

• When the server has a lower tickrate than your cl_updaterate
• When the server has a lower sv_maxupdaterate setting than your cl_updaterate

Bad Examples (Choke will be produced)

• Server or client cannot does not have adequate bandwidth - the client will not see all in packets.
• Server does not have enough resources to sustain the server fps and the server environment.

out: Average packets (snapshots) being sent (you to server) per second.

This number should be very close to your cl_cmdrate setting. There are a few times when it will be lower:

Good Examples

• sv_maxcmdrate is lower than cl_cmdrate
• When the server has a lower tickrate than your cl_cmdrate.

Bad Examples (Choke will be produced)

• Client FPS is lower than cl_cmdrate
• Any of the aforementioned bad examples

6. Loss: Any packets (snapshots) that are lost somewhere between the server to you. This almost always results from a problem with routing, your network connection, your ISP, your router, etc. Rarely is a problem with the game.

7. Choke: In its purest form, choke is the game engine trying to send more data than it can. Expect a full look at this in the explanation guide.

Net_graph 2

For anyone who likes to use net_graph 2. Here is an explanation from the developer’s wiki.

Under the net graph, the first line shows your current rendered frames per second, your average latency, and the current value of cl_updaterate. The second line shows the size in bytes of the last incoming packet (snapshots), the average incoming bandwidth, and received packets per second. The third line shows the same data just for outgoing packets (user commands).

That’s all folks

That covers the comprehensive and in depth view of the net_graph. Expect more information on optimization this Sunday. I’m out of town tomorrow, so you’ll have to wait a few days. Sorry.