You have no way of measuring the real tickrate, yet you claim to know exactly how much net_graph is off by.

So if 67.5/s in net_graph corresponds to an actual value of 66.67/s and it shows 67.5/s on a listen server doesn't that mean it's running at 66.67/s=15ms tickrate?

You are right.
cl_interp_ratio "x" translates EXACTLY to the previous cl_interp "x/updaterate"

The problem is that one programmer forgot to remove cl_interp and some configs force cl_interp_ratio to stupid values (e.g. the etf2l config forces cl_interp_ratio 1, I don't know why) whereas cl_interp can't be limited to certain values.

#60
Correct. 1 for projectiles, 2 for hitscan. You should consider 2 for sniper since it's the class where hitreg matters the most.

#53
Let's break down your conclusion in simple steps.

1. net_graph doesn't show the correct cmdrate on listen servers
2. Therefore both updaterate, cmdrate and tickrate of dedicated servers have to be 66 and not 66.67.

That doesn't make any sense to me.

Like you said the extrapolation state gets ignored. Here's an even crappier ms paint picture to show you what I mean.
Black = position in snapshot
Green = position in rendered frame
Red = position where it would be rendered if snapshot 3 wasn't 7-10ms late

http://i.imgur.com/pcqD9Kz.png

Now pick frames in an intervall of 16.67ms (60Hz) or 8.33ms (120Hz). That's what you are actually going to see.
I picked 3 60Hz examples:

http://i.imgur.com/pOVFk2t.png

http://i.imgur.com/ybJHaUq.png

http://i.imgur.com/IJIpg9u.png

The effect on number 1 isn't that bad, number 2 is affected the worst and number 3 isn't affected at all by the extrapolation but is actually worse than number 1 and it could've shown these frames without extrapolation!

So instead of the wiki being right and net_graph having ok-ish accuracy, both are wrong?

Scratch that smoothing stuff, I was mentally still in the other thread.

No. Interpolation doesn't smooth extrapolation errors. Interpolation was implemented so you don't have to use extrapolation at all. Unless the tickrate and your refresh rate are perfectly in sync, and they aren't because TF2's tickrate is fixed to 1/66.67=15ms and 99.99% of all monitors are going to run at either 60, 75 or 120Hz, there will always be frames that get rendered significantly after the last snapshot but before the next snapshot arrives. How do you get the object positions at that time? You can't so you'd have to extrapolate. The Source Engine however delays the client time instead so there are [cl_interp_ratio] snapshots of the future (seen from the client) available that you can use to get the current position by interpolating between the last snapshot and the next.

Yeah but if 3ms jitter is so extraordinarily low that it's almost never going to happen then your settings can't deal with it either. In that case I'd just use ratio 2.

I can't figure out what you are trying to tell me with the next sentence. What I said was projectiles->ratio 1, hitscan->ratio 2, but ratio 1 might work for hitscan too if your connection is near perfect.

I'm trusting the VDW on the tickrate.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

The rest after that: No, just no. First of all the scout will get rendered in the correct position in the next frame (assuming smoothing is off) unless the next packet hasn't arrived until then too. Second the interpolation doesn't add 15ms delay just because one packet was late, unless your spiked by 15ms but that's a whole different story. I should probably draw a picture again.

Limb animation and hitbox states simply do not match, depending on the state the hitbox is off even when standing still. Apparently Valve didn't bother syncing them.

Now I know what you meant, the packets are indeed sort of skipped in the display frames but they are still used for the rendered frames in between. Nonetheless every single frame has to sue extrapolation to get the animation state which is horribly inaccurate and jittery.

Choke means that the server has to hold packets back because the bandwidth cap was met. That means either your or the server's "rate" setting is too low.

Set rate 600000 and try again, if it's still showing it's the server.

Can't see anything apart from a bit of choke.
Have you tried a different server?

Could you take a screenshot? One with ratio 1, one with ratio 2.

http://forums.steampowered.com/forums/showthread.php?t=2765833

cl_updaterate 100
cl_cmdrate 100
rate 60000 // tweak using net_graph to the point at which you get <10 choke. Higher rate value than needed just raises your ping.
cl_interp_ratio 1 // how often per tick interpolation is updated. We want that to be every tick, which would be "1"
cl_interp .015
cl_smooth // 1 (default enabled) or 0 
cl_smoothtime // match to interp (.015) or set to 0 if cl_smooth is disabled

cl_updaterate 100 and cl_cmdrate 100 are useless. TF2 limits it to 66.67 anyway and servers can't send more snapshots than their tickrate and the tickrate is fixed to 66.67.
The explanation of cl_interp_ratio 1 is just plain wrong. Interpolation isn't "updated". It's not "once per tick" it means "interpolation length is 1*(1/cl_updaterate)" which is
a) not about ticks, it's about clientside snapshot recieval rate
b) not a "x per" measurement it's a "x times" measurement which is the complete opposite for any value apart from 1.

cl_smooth we had that already
cl_smoothtime this is like the magical rule "you need to use the same interp as your ping". There's no logic behind it.

http://www.reddit.com/r/tf2/comments/1rj6b3/stabby_stabbys_everything_packall_the_tf2_tweaks/
Let's look at the forst launch option.
-16bbp

Now let's look at the Valve Dev Wiki.

-16bpp - Forces 16-bit color mode (bit depth).
Note:Not allowed.

Do I have to continue?

EDIT for #40:
White means everything's normal.
Orange is normal for ratio 1. It means your interp is less than 2 ticks (aka ratio 2) and is sort of a warning that stuff will happen if you loose one packet.
Yellow means that the server framerate drops below your interp time. Most of the time these are really small drops so you shouldn't be too worried.
If you are getting warps or just want to be sure just use ratio 2.
You could also check for extrapolation when you are using ratio 1 (net_graph 4, watch for red vertical lines rising above the white line on top of the blue stripe at the very bottom) if there aren't any vertical red lines at the bottom (see the picture on page 1) you're good.

About smoothing:
If there was a prediction error, the object (aka player) whose movement and therefore position was mispredicted is now at a different position on the client side than on the server side.

With smoothing off the playermodel will be shown at the correct position on the next frame that is rendered after the new snapshot arrived resulting in a "warp" instead of a smooth movement.

With smothing on the playermodel's movement will be smoothed over a few frames/snapshots so that the model is at the correct position (the one on the server/snapshot) after the time set cl_smoothtime. This means that the model won't warp but it won't be at the correct position and the hitreg will be a bit off until the smooth is complete.

Black is the position on the server, red is smoothed, green is not smoothed

http://i.imgur.com/qeR5FiW.png

The client predicted the player to still be going in a straight line, which turned out to be wrong. Now if you have smooth enabled and hit him, you don't actually hit him, because he's at a different position on the server. Without smoothing he'll warp when the prediction error gets corrected but after that a hit is a hit again.

About fps_max:
In theory you get the best hitreg when frames and snapshots are in sync. If you want to avoid screen tearing to the theoretically best fps cap for 66 rates and 60Hz or 120Hz is 600 (exactly 9 frames per snapshot, 10 or 5 per monitor refresh) and. Since it is almost impossible to get a high and stable framerate in TF2 I'd rather cap for the monitor (120, 240 or something like that) than for the hitreg because screen tearing is far worse imho, but that's just me.

Nah, you spread some pretty bad bs in the SPUF, especially those configs.

-64bit doesn't exist in the source engine.
Apart from that there is no 64bit version of TF2 and there never was.
The source engine launches in 64bit if possible, there's only -32bit to prevent that, no way to force it.

@wareya
First:
3ms ping jitter not normal as in too low or too high? Your settings can't deal with more than 3ms jitter either so you should be using at least ratio 2 anyway.
About that "extremely local": That's Europe. If I had to play a match on a Dallas server I'd get 200 ping. 20ms ping is indeed a good case, but my worst case for a match server is 40. And if someone from the east coast has to play a match on a server in Dallas then that's by no means a near perfect connection.

Second:
Yellow lerp means that the server frametime dropped below your interp. If there's no sample to interpolate from wouldn't that mean that one packet was dropped? I've just tested it and slight ping spikes do result in a single extrapolation with no packets dropped. I'm not sure what happens if the previous snapshot was dropped, doesn't TF2 interpolate between next available older snapshot and the current one?

Third:
TF2 runs at 66.67 tickrate, not 66, which equals 15ms or 1/66.67ths of a second between messages. IF you use 66 rates a server will send you all snapshots, which is one every 15ms, not one every 15.2ms. That means that any ping jitter <0.2ms won't cause extrapolation.
It's a minor sideeffect.

Fourth:
1/5th of an inch if you are standing right in front of that scout. Spread doesn't really have an effect on that range, if it's a meatshot, it's meatshot, those 12% of the scouts width that his hitbox might be off is not magically making the shot do 0 damage.
About jumping scouts and hitboxes: The hitbox of a scout's limbs while jumping is completely mismatched. Even on a local server it won't be in the same place as the model. The chest is the only place where you can guarantee damage.

I'm on 120Hz LB.

@EDIT: Could you post a link? How did you test it? I'd like to see if I can reproduce it, because I haven't testet it myself yet.

#32
Why would low/almost no/no interp force TF2 to skip some packets? If this is something totally obvious please tell, I can't figure it out.

You seem to be fairly intelligent too and apparently you also know what you're talking about, unlike other people that just spread bullshit. Yes, I'm looking at stabbystabby and his cl_updaterate 100, his precious 10ms interp and his glorious -64bit launch option.

Might be aliens though.

Slightly delayed counter picture!

http://i.imgur.com/ZFFKJv6.png

Do you see any extrapolation?

Minimal ping jitter won't have any effect at all because TF2 uses ~66.67 tick/s = 15ms/tick, not 15.2ms.

What happens compared to your precious cl_interp_ratio 1.2 setting? 66 rates and 1.2 ratio = 18.2ms vs 15.2ms interp at ratio 1. So above 3ms ping jitter both will behave the same.

Let's look at the worst case: 3ms ping jitter, which is nowhere near perfect so why would you use settings for a "perfect" connection anyway? Let's say you are standing in front of a scout. He is moving to the left at full speed. Extrapolation failed really hard and moved him to the right at full speed. The next frame started rendering just before the packet arrived so you're getting the full 3ms of extrapolation. That scout is now 2*400hu/s*0.003s=2.4 Hammer units away from the position he is at serverside. On your average 1080p 24" monitor that's about 5mm=1/5in. OH MY GOD.