How do rates work... Really?

[EzRemake]

The most common consensus is for rates to be as high as possible. Usually people will set sv_maxrate to 100,000 and sv_maxupdaterate/cmdrate 66+ but is this really all that necessary?

If you refer to this FAQ posted by steam themselves:
https://support.steampowered.com/kb_article.php?ref=5386-HMJI-5162

You'll notice that they chart upload bandwidth vs max player count ASSUMING you're running their rates;

sv_maxrate 7500
sv_maxupdaterate 13
sv_maxcmdrate 13

They seem a bit low, don't they? Maybe steam doesn't know what they're doing, which is what I thought at first too, since I too was a fan of maxing out rates. But I decided I would test them anyway.

I used maxrate 8000, and maxupdaterate 14 and what did I experience? Not only was my server using substancially far less bandwidth, but the hit registry was actually improved, and pings were normal values too!

How could this be? I thought high rates were the key to great hit registration?

[Zombienator]

As far as I know, sv_maxrate is locked at a maximum value of 30,000. You can set it to any value you want, but if you type "rate" in your client console, then the engine will say something like "the real value is 100,000, but server has temporarily locked down to 30,000".
And if this is happening for all games, I think is pretty stupid, because we're in 2012, 30,000KB/s of download limit would have been right for internet speeds of ten years ago, but now why lock it? Just let the choice to server administrators and clients!

By the way, a CSS/TF2 server with 32 players on, will hardly consume more than 20KB/s of incoming data. (and that's why maybe Valve has decided to lock it down), but try with many other entities if you can, then 30KB/s won't be sufficient anymore to satisfy the size of the updates!

sv_maxrate isn't more than a limiter of max bandwidth the server can send to every connected client. If your server sends like 5KB/s, then the server won't send more than how many effectively it needs. Have you got bandwidth limitations on your server? Then limit it to a value that will be safe, like 10,000 if you usually send 5KB/s. You haven't got any limitation? Just leave it to 30,000, server won't consume more if he doesn't need.

sv_maxupdaterate is how many snapshots the server can send every second. (a snapshot is how like the map is in that specific moment: position of the entities, who's firing, who's dying, etc.)
Higher value will increase precision of everything, but if your server or client can't handle it (bandwidth + cpu cost), then the situation instead of being better, will be worst, and ping will increase.

sv_maxcmdrate is how many times per second the clients can send their command packets to server (like mouse, keys being pressed). Like before, higher values will increase the precision if you can deal with it.

Just keep in mind that the server can't send more snapshots or process client commands faster than his tickrate, that is 66 for CSS and TF2, and 30 for L4D/2.
So for example, maximum values of sv_maxupdaterate and sv_maxcmdrate for TF2 will be 66! SO setting them to an higher value will be useless, because server will always set them down to his maximum values, and this is the same for RATE, of course.

BTW you must test to find your ideal values. Turn on net_graph 3 and just watch it while the server is running and players are on.
Watch the lines of packets being received, if you notice a gap between them, then a packet would've been lost, and if is sporadic, it's ok. If you notice many gaps, then the server can't send so fast all those packets, or YOU can't receive them.

I will say though, that those values posted by Valve on that page, are optimized for connections of 10 years ago, when many players were using analog modems or ISDN.
For modern connections I don't know why restrict them even if your server has a great upload bandwidth and cpu power.
But if you say that your ping has increased like you've said before, then leave them like that! But I suggest you to do more deeply tests, and like I said, if you're not worried by server's limitations, leave them at default values which are usually great:

sv_maxrate 30000
sv_maxupdaterate 40
sv_maxcmdrate 40
(you can also specify a min value, usually if a client has his CVAR rate setted to something ancient like 5000, then on server set sv_minrate 10000 or what you want, client will automatically use 10,000 instead of 5,000, same for other two CVARs)

Hope this helps!

[EzRemake]

I guess my question should have been "Why is registry just as good with low rates as it is with high rates".

I understand what each rate does, I just don't understand how "rates from 10 years ago" still hold strong today.

From my recent testing, I can't seem to feel the difference between an updaterate of 33 and 66, other than double the bandwidth usage.

i.e Why use an updaterate of 66 when 33 gives the same result in terms of hit registration etc.

And for the record, yes, I have limited upload bandwidth, so cannot use the max rates even if I wanted to because then I'd only be hosting for 7 or 8 people.

[Mike]

That's weird. When I play at low rate servers, my hitreg DRAMATICALLY drops.

[EzRemake]

After some testing I've figured it out. If the server is running at 66FPS (which all source servers are now), increased hit registry is only possible through the higher rates.

However, in CS 1.6, low rates can still be used IF the server is running at higher than 66FPS (still possible), such as 1000FPS.

I tried running a CS 1.6 server with low rates, 1000FPS and the hit registry was amazing! However, trying the same thing with CSS didn't yield the same results.

It seems CS 1.6 gives you the option to get your registry from bandwidth, Server FPS, or both. Whereas CSS only allows you to get registry from bandwidth now that -tickrate has been removed and server FPS is locked at 66.

[click4dylan]

i just modified the tick rate of my CSS server to 100 and it neither helped nor reduced hit registration, but it made recoil a lot smoother (since recoil still isn't interpolated). doing it on day of defeat source servers causes physics objects to move faster and grenades to bounce erratically

you can modify the tick rate in server.dll with ollydbg. default is 0.015 for 15ms (or 66 ticks), 0.01 is 100 ticks, 0.33 for 33 ticks

i tested 33 ticks and the server runs fine on orange box, but the recoil is very jerky due to no interpolation, and walking seems to be slower

i also tested 500 ticks and it caused physics objects to fly around the map like crazy and shooting players feet caused headshots, but other than that it was smooth as hell. to get more than 100 updates a sec you have to modify a check in the engine for cl_updaterate