Because i became annoyed by some peoples wrong help to new players on servers i feel kinda forced to post this:

Original written by Rex*Cramer

Time to get rid of needless handicaps. To sum it up: With high speed connections like DSL or Cable there is no reason to limit anything. I just could stop here, if there wouldn’t be all the rumours like “I can’t play with mp 60, I’m used to 100” or “enemy is using timenudge, can’t hit them”.

Let’s have a closer look at the different settings and keep in mind that it's all about frames.

cl_maxpackets:

This variable is directly connected with com_maxfps which affects jumping. In OSP com_maxfps must be no greater than 125. Luckily, this is ideal for the movement. It's also the maximum for cl_maxpackets. In general, the client can't send more packets than it has fps.

You should adjust cl_maxpackets to your frame rate. 125 fps and cl_maxpackets 125 is the ideal situation (you need an upstream bigger than 128 kbit for that; with any voice communication program I suggest at least 256 kbit). Always set cl_maxpackets equal to com_maxfps if your connection is fast enough, or a divisor of it if not! Quake sends a packet for each, every second, third, etc. frame. You can find a test here:

http://mitglied.lycos.de/derraziel/temp/maxpacketstest.txt (the text isn't important, check the relation between maxpackets, UDP send/sec, kb send/sec and when it changes).

Looking at that table you will find out this, for example: Playing with 125 fps and cl_maxpackets 100 is the same as 60. It's a similar situation: Lower than your fps means only every second frame a packet is being sent (60 is lower than 125/2, but Quake rounds up as you can see). If you don't have 125 fps set com_maxfps to your highest stable frame rate (details at the bottom). The principle is the same for all frame rates: Set mp equal to com_maxfps or a divisor of it!

Why is this important? Your frame rate could fall below 125 due to heavy action in the game, frame drops are also possible, or other programs are working in the background. There are many reasons why this could happen. If your maxpackets value is lower than your fps and your fps fall below, it does influence your connection by changing the relation from 1/2 to 1/1 back and forth. An unstable connection would be the result. The best setting to avoid this problem is now to use a divisor of com_maxfps. This gives you the least risk for such a behaviour.

What is the reason for so many packets when the servers are running usually with low fps compared to the clients, anyway? Let's assume the server runs with 30 fps (like most do) and the client with 125. That would mean with mp 125 the client sends approximately 4 packets for each world update. It's about how old the data is the server is dealing with: 125 packets per second means a new one every 8 ms, 60 every 16 ms, and 30 every 32 ms. The average information in each packet with 125 fps is 4 ms old, 8 ms with 60 fps, and 16 ms with 30 fps. This built-in lag added to the time each packet needs to get through the network (internet or lan) is your real ping. Your advantage with mp 125 over mp 30 is 12 ms and still 4 ms over mp 60.

There is another thing to think about : Packet loss. Let's say 1 packet gets lost with mp 30, then the server has no new information for about 64 ms. This is a long time. When receiving the new position and if the player is moving fast he starts warping. Needless to say that you wouldn't hit much in this scenario. This is a problem when mp is set too low, while you could lose 1 packet with mp 60 or 3 in a row with mp 125, before a visible effect occurs.

You give a plain advantage away for absolutely no reason, if you set cl_maxpackets too low or too close to com_maxfps, if equal is not possible.

One thing is left to do: The table mentioned above is lacking of the 125/125 scenario. After checking some websites about the functions of all the variables, I did some research myself to verify what I found:

http://home.arcor.de/frank.arand/Quake/125fps-mp125.jpg 125 fps / maxpackets 125

http://home.arcor.de/frank.arand/Quake/125fps-mp100.jpg 125 fps / maxpackets 100

http://home.arcor.de/frank.arand/Quake/125fps-mp60.jpg 125 fps / maxpackets 60

(If you want to test that yourself with Windows (I used XP Prof., not sure about other versions though) run perfmon.exe, delete all variables at the bottom, add a variable by rightclicking and add, select object UDP and data sent and hit add. Right click again, hit properties, go to graphic sheet, set the maximum to 150 and on data sheet the factor to 1.0. Run Quake, go to any server, and alt-enter out. Now look at your performance monitor. You can vary com_maxfps and cl_maxpackets to see what it's all about, how Quake rounds up and down and when it changes. (This could be a bit different since I’m on another language version, but I’m sure you will sort it out.))

snaps:

Client setting of sv_fps. Determines how many world updates the client receives. Because most servers are running with 20, 25 or 30 fps, a setting of 30 or higher is ideal; anything above sv_fps makes no difference anymore. For some reason the standard setting is 40 - on a few servers you're even getting kicked by punkbuster, if snaps is set to anything else, so just leave it to 40.

The only reason to lower snaps would be, if you have a very poor connection (slower than single ISDN) and/or very few fps (clear below sv_fps), but then better don't play at all. :ugly:

rate:

This controls the downstream from the server to your computer in bytes per second. 25,000 is the maximum (unless the rules for league games saying anything else). If your connection is fast enough, go for it (make sure you leave some room for teamspeak if needed).

cl_timenudge:

Many players think otherwise, but this setting does not affect the connection in any way nor how other players see you or you them. It's client sided only. All what it does is to inter- or extrapolate the movement of all other players. With negative values you adjust client side prediction.
The information you have to deal with is not up to date, nothing can change this. As long as a player is moving straight in one direction, the prediction of his position is no problem. What if he changes? Try to imagine: The model on the screen is already pushed too far in the calculated direction, when the information arrives, that he did something completely different. The prediction was wrong, the position you see and the real one is more off than without a negative timenudge. These errors need to be corrected and that makes the models unsmooth - or the whole screen, when spectating someone from his point of view.

cg_smoothClients does not help here, because it just makes no sense to extrapolate and then do the contrary by adding 4 ms local lag (for 125 fps: 8 ms (frame) / 2 = 4 ms). Set this always to 0, if you're playing with a negative cl_timenudge.

It's up to you, if you find shaking models worth the little difference.

cl_packetdup:

Packet duplication determines how often each packet is being sent. Unless you have an unstable connection and problems with packet loss, keep this to 0. 0 means each packet is being sent 1 time, 1 for 1 backup packet up to 5/5.

If your connection can afford mp 125, you shouldn’t have problems with packet loss. If so, there is most likely another problem around. If you have to play with mp 60 or lower due to your limited bandwidth, it’s still better to play with the highest possible maxpackets setting than with a lower one and packetdub 1. Now you know why, because the result of mp 30 / pd 1 and mp 60 / pd 0 is the same upstream, but in the last case the information is newer as we saw above and the way to go. Keep cl_packetdub to 0.

These settings are meant to be the maximum. You set what is the best for you, so does the server administrator. This way it is guaranteed that your connection doesn't get flooded by the server and vice versa.

Additional Information:

Why your framerate affects jumping (try the values at the very bottom for com_maxfps, if you don't have 125):
http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html

P.S.: Quake 3 Arena is still closed source. Nobody knows exactly how all these things work. Everything depends on what we’re told and assumptions on what we see. This might also be the reason for all the rumours about the different settings, because there is so much room for speculation. Things maybe slightly different, but I think it’s save to say that all these explanations are very likely correct. [/b]