Hey Dots ive heard some players saying that they have odd lag problems and was wondering if the rate of the server was too high. Im sure theres others out there with more knowledge about this topic than me.. just trying to help out little community stay happy I found this online maybe it will be of some help...
Next you will need to set your rate, as in an example only
.. Rate plus FPS
seta sv maxRate 2300
seta sv fps 20

sv maxRATE determines the amount of bandwidth your server uses for each client. It is a calculation based upon your bandwidth ...size of your UPLOAD pipe, not DOWNLOAD... and the numbers of players you plan on hosting. Here is the calculation
No. of clients x sv maxrate x 8 for 8bits equals upload speed
or
Upload speed No. of clients x 8 equals sv maxrate

To determine your DOWNLOAD and UPLOAD speeds, use www.dslreports.com. You can do 4 free tests in a day, and I advise testing over several days, especially if you are a cable subscriber. For example, my DOWNLOAD speed ..on a cable modem.. averages around 2200KBps to 2900KBps ..thats 2.2MBps to 2.9MBps.., but my UPLOAD speed averages between 242KBps and 253KBps. Quite a difference. Therefore, the calculation I used is:

243000 divided by .. 13 x 8 .. equals 2336

My total number of players is 13... 10 with 3 private slots , my UPLOAD speed is 243000Bps .. 243KBps , and I rounded 2336 to 2300.

Use RudeDogs Excel calculator for determining maxrate ..NOTE you need to have Excel installed locally

www.fpsadmin.com

sv_maxrate and rate issues
This - as mentioned in the /rate section - limits to a certain value of bytes per second the upload of a server to any client (server->client). However, since there is delta compression in current q3 gaming, the max value of 25000 (24.41KB/sec) is never reached in a common server setup. Uploading of snapshots is usually done at 4 to 8kilobytes/sec to each client even on the max setting. This however may not include certain overheads since the lowest allowable value of /rate of 8000 (which is 7.81KB/s) is often a source of throttling, and often on values of 10000 or 12000 too.

Because of throttling side effects, values of 10000-12000 or less on very populated servers may have to be avoided. Take a look at the relevant test case below for a detailed account of this.

In case ioUrT includes in the future VoIP features from ioquake3, this var will also limit the bandwidth used by that feature.

A very important indicator for the correct usage of rate limits is the state of the lower line on the lag meters of players. If it is yellow instead of green it means that rate was suppressed (that this limiting discussed here had come into effect, unless they limited themselves with /rate). This is not necessarily bad, in fact it is good if your upload bandwidth was indeed in need of limiting. But, you may want to decrease latency and potentially avoid yellow on the top created by this state, in which case yellow on the lower lines of your players' lag meters may mean the need of a higher maxrate if possible.

Yellow on the lower line is often the reason for yellow on the top since suppressing information to save bandwidth, the client may be forced to extrapolate (guess the current state from past information) which is a source for inconsistencies in gameplay, hence an extra reason to avoid excessive bandwidth limiting if possible.

Keep in mind that a low rate to the clients is much preferable than a high one that would congest connections. This is because a low one will simply mean a bit choppy and inconsistent, a too high one that congests connections, major lag (accompanied by red lines on the meter).

If clients get red on their lag meters (dropped snaps of info from the server), a possible underlying reason may be a connection between clients<->server where the bandwidth has been congested. A lower sv_maxrate (or /rate s) may improve the situation. However, it may be any other congestion/instability source between the involved computers.

A related variable is sv_minrate which forces a minimum rate on clients though in rare cases, a client may need a lower one (e.g. on very limited bandwidth).

sv_minrate and sv_maxrate don't change /rate of a client shown in /rcon status, it gets the /rate of a client, it checks it in server code and forces the rate it uses for later throttling based on sv_maxrate and sv_minrate (and other built-in limits).

If you have sv_maxrate on 0, the default, it's equivalent to 25000. If no red appears on clients and no bandwidth saving is needed, it's most probably better to leave it at that max value.

I don't know Wedge, this lagproblem existed before and after
the sv_maxrate was changed.

I learned to deal with it using timenudge which works like a charm
9 out of 10 times.

The most annoying thing for me is that there is usually one (random or the same) person I can't hit.
I can hit everyone right on target and with this one person I suddenly have to aim behind/in front
(which I can't do even if my life depended on it)
Must be their (rate and maxpackets) settings or something, I don't know what else.

Well I found another tidbit of information about client side settings maybe this will help someone I dunno .....
In Quake2 your FPS governed how many gameworld updates you sent to the server, a high FPS gave an unfair advantage over those with lower FPS. In Quake3 a high FPS has no advantage. The cl_maxpackets setting restricts the number of packets being sent to the server by your client and can be used to help connection bandwidth related problems for those with low upload bandwidth. The default setting for cl_maxpackets is 30, usable range is 15 to 100 on the Internet, maximum 125 under point release 1.32 or above. id software force a higher value when playing over a LAN *.

NET_SendPacket: WASEINTR problems can be caused by cl_maxpackets or com_maxfps. As your FPS increases so does the data size of each packet sent to the server. In extreme cases with a very high FPS you could saturate your upstream connection.

In all cases try to set cl_maxpackets to equal your average framerate or your com_maxfps setting or a divisor of it without saturating your upstream bandwidth. Use the FPS figure displayed using cg_drawFPS "1" as a guideline for actual FPS. For Example if you are currently at com_maxfps "76" then try a value of 38 or 76 for cl_maxpackets. If you have set your FPS above 100 then use a divisor of your FPS, for example if you are currently capped at 125 FPS then try 31/32 or 62/63 as a cl_maxpackets setting. See the note about packetloss in the cl_packetdup entry.

When playing on a Punkbuster enabled server you may need to reduce cl_maxpackets and/or adjust pb_sleep to reduce lag spikes.

* NOTE: If you are playing a an ISP that allocates you a 62.x.x.x IP address and you play on a server with a 62.x.x.x IP address you may have problems with bandwidth flooding. Quake3 assumes you are on a LAN and forces your cl_maxpackets to a higher setting. The only workaround at this time is to lower your com_maxfps to 100 or below (cl_maxpackets will never go above com_maxfps setting).