Something else to keep in mind... If you're running in OpenGL or D3D with net_graph 1/2, you're going to take a fairly severe frame rate hit. If you run with net_graph 3 it should run a lot better, without the pretty colors.
Erik -----Original Message----- From: Patrick Devin Wigington [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 10:45 AM To: [EMAIL PROTECTED] Subject: [OT] netgraph, sorry for pic This is from a recent sdk: Changes to the Net Graph for HL 1016 In view of substantial changes to the networking protocols used by the Half-Life/TFC engine, we have redesigned the netgraph to provide a lot more useful information to end users. To turn on the netgraph, type net_graph 1 at the console. To turn it off, type net_graph 0 at the console. The netgraph may be positioned on the left, middle or right of the screen by setting net_graphpos to 0, 1, or 2 as needed. You can adjust the size of the netgraph by setting the net_graphwidth cvar. How to read the netgraph Area 1: Area 1 is the part above the white separating line. This gives you a sense of the general size of each packet your client is receiving from the server. The scale defaults to 5 bytes of data per pixel. You can change the scale by setting the "net_scale" cvar to something else. Along the edge of the screen ( not pictured ) there is also a set of green hash marks. The hash marks indicate 50 bytes per mark. If your net_scale is low enough, you will see minor hash marks for every 10 bytes. The colors signify the following: red: player specific data for you only yellow: other player data purple: other entity data light blue: event data dark blue: temporary entity data green: sound data gray: user defined message data white dot at top ( only if net_graph is set to 2 ) - signifies size of full packet size Area 2: This area shows numeric information about the performance of your computer and its net connection. The numbers registered are as follows ( based on the above snapshot ). As shown, the client is rendering frames at 23.4 frames per second. The client believes that it has a 459 millisecond round trip message time to the server ( this is a latency reading, rather than a pure ping, since it includes processing overhead on both ends ). The last packet the client received ( "in" ) from the server was 54 bytes long. The average data rate over the last second or so from the server has been 1.65 kilobytes/second and the last packet had 9 bytes of "player" data in it. On the other hand, the last command issued by the client was only 23 bytes long and the client is generating 1.75 kilobytes/second of upstream data right now. Area 3: Below the numeric readout is the well-understood green/red/yellow/blue readout that most users are familiar with. In particular, the height of the green line indicates how much latency exists in the connection for the specific packet received. The green lines max out at around 1000 ms of latency, so our player here with 459 ms of latency has a green line that goes about 50 % of the way up the area. The red vertical lines you see indicate dropped packets. In addition, if the client and server encounter severe connection problems, they can become so out of date that you will see blue lines similar to the red ones. Finally, if the bandwidth choke is active ( your rate setting is holding back packets at the server because your connection can't handle them ), then the green dot for the next packet you receive will be drawn in yellow instead. Area 4: Area four is correlated to how quickly the client is rendering frames. For each frame rendered, the graph indicates how much interpolation was used in drawing objects in the world. If you are not getting a sufficient number of server updates ( < 10 second ) or you drop enough packets, then the client won't be able to interpolate any more and will have to extrapolate instead. In that case, you'll see the lower part of the graph go above the grayish line ( above the dark blue area ) and turn yellow to orange / red depending upon how far out of date your data becomes. Area 5: The number here is the number of updates per second you are currently requesting from the server. The default is to receive 20 updates / second from the server. You can change this value by setting the cl_updaterate cvar from the console. Area 6: This number is the maximum number of command packets you will send to the server per second. The default is to send up to 30 command packets per second up to the server. If you are running faster than 30 frames per second, then multiple commands will be put into some packets. You can change the rate of sending command packets to the server by setting the cl_cmdrate cvar. In addition, with each command, we re-send the last few previous movement commands ( in case there is packet loss ) so that we can keep moving smoothly in the face of minor network problems. The default number of "backup" commands that we send is 2, but you can change this number by setting cl_cmdbackup to another number. You can send more than 8 backup commands and you should note that sending backup commands will increase your outgoing bandwidth usage. Area 7: The final area is the light blue and ( sometimes ) red line at the very bottom of the netgraph. This line is based on your framerate and your cl_cmdrate setting. For every frame where a command packet is actually send out onto the wire, a light blue dot is placed on the graph. If commands are accumulated for deferred sending, you'll see a red dot instead. Try setting cl_cmdrate to half your framerate to see the effect. Considerations for tweaking your network settings. First, the client and server framerates are now decoupled, so there is no need to use a low fps_lan or fps_modem setting. I.e., running your client at a high fps won't flood out your connection if you are on a modem. Second, the rate command is now a bit more accurate than it was before. As always, it is critical to set your rate appropriate to your connection quality. Finally, the engine now does a pretty good job of spacing out packets sent back to you to try and minimize the latency involved. Instead of skipping an update period completely ( i.e., if you are getting 20 updates a second, then instead of waiting 0.05 seconds ) if your connection rate won't allow sending another packet, we check for clearing of the data in the pipe much more often than that interval and send as soon as we can ( limited by the server's ticrate ). In essence, we expand the time between updates to use your specified bandwidth without introducing unneeded latency. -----Original Message----- From: Lance Pehrson [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 1:25 PM To: [EMAIL PROTECTED] Subject: net graph Will some one please point me to a detailed description of the net graph and its meanings
<<attachment: clip_image002.jpg>>
