How I fixed my Engineer update lag.

[fivealarm]

Gentlemen,

This latest update caused my game to become an obnoxious slideshow wherever there was action. I used some good old net_graph 3 to track down the problem.

First of all, my choke was 80+ on all the new maps. Le gasp!

Also, near the center of the new maps entity traffic was through the roof. Whenever that spiked, the game wouldn't update smoothly. Thunder Mountain was especially guilty and lots of engineer buildings everywhere seemed to compound the problem. I could round a corner and watch as individual objects popped into view.

All this meant that I didn't have enough bandwidth to go around. Whenever my client received a sudden, large update from the server everything else on my screen had to pause and catch up. The solution was to fatten my "pipe".

I discovered that my rate cvar had returned to its rather low default at some point. I set it back to MKWEA's max allowed of 30000 and my problems magically dissolved. I think that my rate got reset a long time ago when I moved my steam directory but, I didn't notice anything until this most recent update created the perfect situation to expose bottleneck.

I know some if not most of you didn't have the same problem or already had a properly set rate. I just thought I should share the information in case it could help someone else.

[kaixx3]

x___x First off: Hello Fivealarm, I remember healing you and getting killed by you last night. Enjoyable times, Sir.

Secondly: I remember setting cvars and whatnot a long, long time ago, but have since changed computers and I believe this forgotten remedy to lag may be the cause of my current troubles.

I just googled it and I'll post the info here on how to do it, but if you guys haven't, put this in your command box. It helped me a lot back then and I'm about to do it now to see what it does on this new computer:

"rate 25000"
"cl_updaterate 66"
"cl_cmdrate 66"

Verify your settings/choke by typing "net_graph 3" into the console. Turn the graph off with "net_graph 0".

I think Fivealarm changed the 25000 rate to 30000.

I dunno if all this information is even useful to any of you, you might all recognize that I have no idea what I'm talking about here, I'm just posting stuff I googled, but if it helps, I'm glad.

;3 -KaiXx3

[brianblack]

Follow up first off: Howdy and welcome kaixx3, hope to see you on the server again. Secondly, I suppose that this is something I should do at some point, since I don't think I've ever changed those variables.

[Jeziah]

While we are semi on-topic, why do some retarded owners advertise their servers as "100 tick" when Source 2007 is physically limited to 66 to discourage timing errors? Can they actually get around the limit, or are they just stupid?
btw I believe "rate" is capped too, at about 30000. I've never seen more in use at once.

[kaixx3]

I once owned a TF2 server and I think they offered 100 tick servers. It could have been a scam though just to get people to pay more money and think they're getting something special.

[fivealarm]

Ohai der, kaixx3.

My rate was reset to something much much lower. It was in the 10,000 range. Waaaay too low for 24 player source engine games. I remember playing 12 player NS games with rate 9999 and TFC with rate 2500 on 56k though.

I use:
rate 30000
cl_cmdrate 66
cl_updaterate 66
cl_interp 0.03 (or 1/updaterate * 2)

100 tick servers aren't snake oil. They use more CPU and more bandwidth. Less professional hosting services tend to misconfigure them or put too many on "one box" so load averages appear normal but when usage spikes server performance can't keep up with the tick rate.

In the past Windows based servers needed to run a program in the background that would "trick" the OS into setting some multimedia timer that would allow the server to actually update at 100hz. Without the "trick" windows hosts wouldn't update faster than 66hz. This was a limit imposed by the OS, not the source engine. Some hosts neglected this because they didn't know. Linux based servers never had that problem.

Some hosts would specify a higher tickrate, without allowing higher rate, updaterate or cmdrate values for clients.

All of these errors could create a user experience that didn't match the advertised tickrate for a given server.

[Jeziah]

Wow, that's pretty interesting, but I was referring to this: "It is not possible to change tickrate on CSS, TF2, L4D and L4D2 because changing tickrate causes server timing issues. The tickrate is set to 66 in CSS and TF2, and 30 in L4D and L4D2." From "Source Multiplayer Networking" on the Source wiki.

Ooh don't forget to set "cl_interp_ratio 0"! I get absolutely no packet loss issues without interp ratio, so there isn't really a downside to it.

[fivealarm]

You're mostly correct. It's not possible "out of the box" for CSS, TF2 or L4D1/2 because Valve placed limits on the tickrate values they would accept from command lines. You can re-enable the -tickrate 100 switch for current source servers with an addon. It has some pretty negative effects for hitreg as I understand it though.

DOD:S isn't limited by Valve and runs fine with -tickrate 100, though.

Oh... messing with cl_interp_ratio is silly because, cl_interp = cl_interp_ratio / cl_updaterate with the following exceptions:

1. The server can limit your minimum cl_interp_ratio (MKWEA limits to 1).
2. The server can limit your minimum cl_interp (MKWEA limits to 0.015).
3. Even where cl_interp_ratio is allowed to be 0, the minimum possible cl_interp is 1/updaterate. (Meaning, your actual interp value will be 0 but, the source engine interpolates over 1/updaterate anyway.)

So, with your settings on MKWEA, you're still interpolating over the previous 1-2 frames whether you like it or not. Basically the only real use for cl_interp_ratio is to raise the lower limit of your interp.

[Jeziah]

Didn't know servers could limit that, that explains some things . Well, I say at least set cl_interp_ratio to 1, because I have never been limited above that on any server I've checked (net_graph) and because cl_interp_ratio defaults to 2, doubling interpolation lag