That post inspired me to look into it more, since it had details on what was actually happening for the crash. It seems like it has to do with the compressed fragment size info sent with large split packets. It's either overflowing or just too large for the server to handle quickly.

8.4.0 released with networking improvements, performance optimizations and bug fixes.

Changelog
Support me

This release took 35 hours to produce. If you like the work I do, consider supporting me!

Updated recommended base launch options to: -novid -nojoy -nosteamcontroller -nohltv -particles 1 -NoQueuedPacketThread +cl_clean_textures_on_death 1

You can also try +cl_threaded_bone_setup 1 which enables threaded bone setup for animations, improving performance. It is not enabled by default as it can cause crashes.

I am not sure if mat_setvideomode helps. I'd recommend just using the video settings.

Set:

cl_cmdrate 66
rate 131072
cl_interp .0151
net_compresspackets_minsize 180
net_maxroutable 1200
net_maxfragments 1200

Remove:

net_splitpacket_maxrate 196608
net_maxcleartime 0.020346

What config settings do you have?

8.3.10 released with bug fixes and spy networking improvements.

Changelog
Support me

This release took 5 hours to produce. If you like the work I do, consider supporting me!

Do you experience stuttering with snd_async_minsize 0;snd_async_fullyasync 1

Basically, it sets the size of sound file past which it will not bother playing from cache, which partially loads the sound file, and instead starts immediately loading it asynchronously. Thanks for the report on this, but I need more information to know how this fix will affect other machines. What's your CPU and do you have TF2 on an SSD or HDD? Finally, does snd_async_minsize 262144 fix the problem as well?

VAC is a signature based anti-cheat. If you aren't cheating, you won't get banned. That's Valve's principle. (but disclaimer: I am not Valve, so they could consider this to be cheating and you may be banned)

8.3.9 released with networking/hitreg updates.

Changelog
Support me

This release took 40 hours to produce. If you like the work I do, consider supporting me!

https://www.epicgames.com/fortnite/en-US/news/highlighting-creative-games-from-january

Here are a list of custom maps, you can use some of these to train specific areas

Solved on Discord. Needed to move configs to user folder, and rename them back to normal.

The console is no longer force enabled. You can enable it in advanced settings under keyboard. This is due to the extra overhead from the console.

Thinking about and analyzing it further, an interval of 1/66 in interpolation essentially corresponds to a 0.015 interval on the server. So that's fine.

At 66 update rate, when you receive a new snapshot at for example, 0.04545454545 seconds, and rewind 0.0303030303 seconds back in time for interpolation, you are at 0.01515151515 seconds, which is when you received the packet for server frame 1, so you are rendering server frame 1. So when the server rewinds back to server frame 1, it matches your render position.

But now, it seems like I am missing something else, or there can be a big error on interpolation between packets, because if you shoot someone at 0.05303030302 seconds, your render time will be at 0.02272727272, it will submit a command at 0.0606060606, with tick count of 3. Then, it will rewind two frames back because of lerp ticks of 2 from 0.03030303 lerp, and then use frame 1 on the server, which was 0.01515151515 on client time. So, you see something at 0.02272727272, but the server lag compensates it as if it was on 0.01515151515. Essentially making it compensate for the base tick delay from interpolation, but not the distance interpolation introduces from the base tick values.

Alright, so I did investigate further. CServerGameClients::ClientSettingsChanged is not the source of this issue. TIME_TO_TICKS is. TIME_TO_TICKS converts time in seconds into number of ticks. Number of ticks cannot be fractional, according to the TIME_TO_TICKS formula (equivalent to round(dt / 0.015) in TF2 (full formula is (int)(0.5f + (float)(dt) / host_state.interval_per_tick)).

The two relevant places I could find this being used in relation to interp/lerp is in lag compensation (CLagCompensationManager::StartLagCompensation) and demos. In lag compensation, it uses lerp time (as discussed above, set in CServerGameClients::ClientSettingsChanged), and converts it to number of ticks, and rewinds that many ticks back.

What is confusing to me though is that this seems to use the default tick rate (intervals of 0.015), rather than any networking rates (intervals of 1/66). So I must be missing something, or else most of the default settings or using cl_interp_ratio would cause at least an error as well.