5 replies to this topic

[TheShipsMast]

This is a brief description of how Servers and Clients interact, FPS, Ping (FPS) Boosters and how the parts all work together.

The Engine
The Half-Life Multiplayer Game Engine is composed of a Server and one or more Clients up to 32 maximum that are communicating interactively on a semi-real-time basis on the internet. Communication between Server and Clients uses UDP protocol which is very suitable for this type of communication.

The Server is a rendering machine without any graphics. The Client is a rendering machine with graphical and acoustic subsystems that is also interacting with the player through keyboard and mouse.

Normally, the Server runs at a default rendering cycle of 100FPS (Frames Per Second) or 10ms per frame. With various intentional and accidental innovations available, the Server can be run at much faster cycles, up to a maximum of 1000FPS. There are some hardware and operating system limits on what the FPS maximum a Server can achieve.

Running the server at 500FPS or 1000FPS has no direct impact on the client machines FPS, each machine renders frames independently. The Server FPS rate is set via the CVAR sys_tickrate (min 0, max 1000).

If the computer that the Server is running on has the horsepower available, running higher FPS (up to the max setting of 1000) will do several beneficial things. Let's take a look at what is going on here and why this happens.

The server is running a map, caching resources, rendering frames, receiving status updates from the clients and sending out updates to the clients.

The client is running the same map (checksums must match), rendering it's own frames sending out updates and receiving updates from the server. The client is also graphically and acoustically displaying the frames (the server doesn't) and interactively working with the player.

In addition, the client renders all the animations and positions for models, sprites, sounds, animated textures (like water) and mobile entities within the field of vision of the player. This includes weapons and shots in flight.

The server keeps track of all these but doesn't have to render anything for them, just update the client about positional changes and events.

So we see that there are actually two different and independent (and yet dependent) rendering systems that are communicating back and forth.

Let's say that the Server is rendering frames at 500FPS. That means that a snapshot of everything going on is available to send to the client every 2 milliseconds (1000FPS is every 1 ms).

The client is actually interacting in two different ways with the server. The client sends updates of the client position and actions at 30 times a second (cl_cmdrate since that doesn't require a data response from the server.

So with a cl_updaterate of 20 that means that every 50ms or so the client is going to request an update from the server. We then add the travel time (1/2 ping) from client to server and then there is (with the server rendering at 500FPS) at most a delay of 2ms before that update is rendered and sent back to the client with the additional 1/2 ping delay.

At 100FPS, there is a 10ms maximum delay for this to happen.

Now since all clients are rendering and requesting updates independently, each randomly (to each other) will be sending these updates to the server, so think of this as a "storm" of update requests all arriving at different times to the server.

The rate at which these updates are sent back and forth are controlled by the CVAR "rate on the Server side. The Server side settings put a cap on anything the Client sets. Rate is measured in bytes per second. On the average, a player with a rate of 7500 sends and receives a maximum of about 7.5Kbytes per second to the server.

If the server is running at 100FPS then there is a 10ms period for these requests to accumulate while the server renders the data and then sends out the updates to all the clients in the current queue. If the Server is able to render the current frame before the end of the sys_ticrate interval it effectively sleeps the rest of the time.

This means that if there are a lot of clients, the server will have to send out a large burst of data every 10ms which can put a strain on the server uplink.

If the server is running at 1000FPS, then effectively as soon as each client sends in an update request, the server can then deliver the update for just that client almost immediately which results in a lot of smaller, more distributed bursts of data through the server uplink (the total average is the same though).

This effectively does three things, it decreases the demand on the uplink (so you can have less congestion), it slightly decreases the relative ping adder that each client sees (from 10ms to 1 or 2 ms) and more important, it keeps the client slightly more up to date as far as what is happening, which improves accuracy and decreases lag.

(Note: the server may actually send out the currently pre-rendered frame as soon as it receives a request from the client and not wait for the next frame. I have not been able to verify this either way other then empirically and the way I'm describing it is how it seems to be functionally behaving).

So in summary:
1. Server is rendering frames at 100FPS or 500FPS or 1000FPS, updates are available every 10ms or 2ms or 1ms.

2. Clients are rendering frames at (default) 100FPS and displaying frames at (typically) 30 to 100 FPS depending on the CPU and graphics hardware they have and what is happening on the map.

3. Clients are sending update information (cl_updaterate) to the server at (default) 30 times a second.

4. Clients are requesting updates from the server (cl_cmdrate) at (default) 20 times a second (which is 50ms between updates). Server is sending out update information to the client. During that 50ms interval (and ping travel time), the client is rendering visible frames, predicting events and interacting with the player until the update is received.

5. Clients send data to the Server and the Server sends data to the Client at the rate set by client-side CVAR rate.

6. Servers running at higher FPS will be able to send update information to the client sooner and slightly minimize congestion on the server uplink.

7. Clients will send to the server and will receive from the Server the same amount of data no matter what FPS the server is running at. This of course assumes that the server has reasonable limits set (sv_maxupdaterate).

8. Server CVARs sv_maxrate are immediately put into effect, there may be a slight delay before the changes are visible (if there is any visible effect to be seen).

[tef]

Christ Shippy, u really ARE a geek

Where's #9 then?

9. To get the best performance when playing CS:S on the [BIATCH]Server, since the server is set to X,Y,Z, you should set your client to A, B, C

Oh, and 10.

10. Once you've done that, buy a decent PC coz that 286 yer running on just doesn't cut it any more sonny, and

11. You'll still be shite and die in the first 10 seconds anyway

[TheShipsMast]

thanks..

I think

9. I dunno what the rates are on the server - it was like that when I arrived guv'nor

10. aww, I like my 8086, it runs sweeeeeeet

11. aye, prolly.. still cant shoot fer shite!

[tef]

9. Didn't u optimise the config files recently?

10 & 11

[DeViL_DoG]

lmfaoooooo fuck me once again im baffled by numbers

[TheShipsMast]

6, 8, 93, 12