[RussEfarmer]

The net_graph command is probably something everyone already uses to see ping and fps easily (net_graph 1), but there are actually three other levels of net_graph that show a lot of good information about your network connection to the server. This thread will be explaining how to read the fourth level (net_graph 4) of net_graph.

Here is a screenshot of net_graph 4 broken up and numbered:



Here is what each number/section means:
1: This is the main area of the network graph. Each vertical line on the graph is a representation of each packet your client has sent and received to and from the server (after decompression), the colors in the line signifies the types and amounts of data moved. As a quick example, in the attached image you can see where I move my camera into the map, and the server starts sending me entity and player updates (green and red), but when I move back out of the map, I stop getting that data and only get voice and sound data.

The white numbers at the top of the lines are the decompressed size, in bytes, of the packet. They only appear for packets with sizes in the 95th percentile. Any data that doesn't fit any color in the graph legend is indicated by the blank space between the last color in the bar and the white dot at the top of the bar.

2: FPS and ping, duh

3: Quantity of data sent to/from the server. The in/out number is the size of the last incoming/outgoing packet, and the k/s number is the average amount of data being sent/received in kilobytes per second.

4: The quantity of lost and choked packets since you've connected. A lost packet is one that was completely lost in transit and had to be resent, and a choked packet is one that the client wanted to send on that tick, but couldn't, causing a delay to the next tick.

5: Server tickrate and frame time variance. Frame time variance is calculated as the standard deviation of server frame time across 50 server ticks. High variance could mean that the server doesn't have enough processing power to run at the tickrate it wants to. A server tickrate below 20 will turn this line yellow, and a server tickrate below 10 will turn this line red.

6: This is a measure of how strong your lag compensation is. A value of 100ms means that you are buffering and interpolating 100ms of entity and player movements. This means that every entity and player on your screen is 100ms old, but it also means that you can have packets take up to 100ms round trip to and from the server and still have hitreg work correctly, since the server will rewind time to when you shot, process it, and still have it show up correctly for you since it was within the buffered window. Events that happen outside of this buffered window up to 250ms are extrapolated (the server just guesses lmao), and anything after interp + 250ms works outside of lag compensation and is disregarded.

7: From top to bottom, this is your configured cl_updaterate setting, the actual cl_updaterate you are getting, the actual cl_cmdrate you are getting, and your desired cl_cmdrate. cl_updaterate is how often you want to receive updates from the server, cl_cmdrate is how often you want to send updates to the server. Most servers lock your actual cl_cmdrate to prevent exploits, since increasing your update rate breaks a lot of tick-based logic (Good example of that is the jump pack flying exploit, hackers crank the cl_cmdrate value higher than the server is supposed to let you, which makes the jump pack multiply your upward velocity way too often)

8: This extremely hard to see graph (green line) is a historical view of ping. High is higher, low is lower. A red vertical line indicates a dropped packet, and a yellow line indicates a choked packet (both of these increment the loss/choke counter)

9: This graph is how hard lag compensation has to work (technically called the lerp graph). The higher the blue section goes on a server tick, the further back the server had to rewind your actions to process them. Events that happen outside of the interp period are extrapolated, which are shown on the graph as an orange vertical bar. If you look very closely, there are white dots at the bottom of this graph, which indicates that a client packet was sent on that tick. You can see that there is a white dot 50% of the time, which lines up with the numbers seen in section 7 (66 updates received per second, top number, vs 33 updates sent per second, bottom number)

Most of this shit makes no sense and you should basically never have this open, but if you want to diagnose lag issues or tune your lag compensation settings for better hitreg, it's the best tool you can use.