Closed velsignetsjel closed 1 year ago
One person in TF2's Steam Discussions pointed out warnings that the game gives in the console while loading to the server:
[SteamNetworkingSockets] WARNING: SteamNetworkingSockets lock held for 50.5ms. (Performance warning.) ServiceThread,PostConnectionStateUpdateForDiagnosticsUI,ThinkPingProbes,ThinkSelectServer(x2),EnsureDataCenterRoutesValid This is usually a symptom of a general performance problem such as thread starvation. [SteamNetworkingSockets] WARNING: Waited 48.0ms for SteamNetworkingSockets lock [SendMessageToFakeIP] [SteamNetworkingSockets] WARNING: SteamNetworkingSockets lock held for 30.3ms. (Performance warning.) ServiceThread,PostConnectionStateUpdateForDiagnosticsUI This is usually a symptom of a general performance problem such as thread starvation. 'soldier.cfg' not present; not executing. [SteamNetworkingSockets] WARNING: SteamNetworkingSockets lock held for 22.1ms. (Performance warning.) ServiceThread,PostConnectionStateUpdateForDiagnosticsUI This is usually a symptom of a general performance problem such as thread starvation.
I don't know what these warnings are related to, to be honest (I don't think they're related to the long loading times problem at all).
I've also been noticing this since update, both casual and mvm servers seem affected. The first time loading into a server used to be slow for me before but now it remains slow even if I have played several games in one session without quitting the game.
Are you on an AMD or Nvidia gpu, cause i've heard that the new AMD driver got a complete rewrite so that might be the cause why our loading times are so long.
Are you on an AMD or Nvidia gpu, cause i've heard that the new AMD driver got a complete rewrite so that might be the cause why our loading times are so long.
But I'm running an old version....
i tried downgrading to 23.4.1 and the issue persists, valve might've broken something for AMD users, i think we might just have to wait for them to acknowledge this issue and fix it, i think you should label this as an AMD gpu/software/driver bug
Don't think it's exclusive to AMD, I'm on NVIDIA; a pretty old card (GTX 980 Ti) with the latest compatible drivers (536.67) and I have the same issue.
This seems to happen for everyone. My friend experiences the same issue, just like I do. For now all you can do to alleviate it is reduce all of your settings to a minimum and use the file operations script from this repo: https://github.com/high-brow/Vusaline/tree/master/bats, it removes a bunch of unnecessary files that TF2 loads and allegedly improves the loading speed.
Is this issue also occurring in a fresh installation of TF2 that doesn't use any configs, launch options or custom mods?
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5094#issuecomment-1660116548
I tried booting up without my custom folder and my loading time seemed to be 30 seconds (close to pre-summer update loading time) so im guessing, no
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5094#issuecomment-1660119931
What mods were you using when the longer loading time occurred? And are you using any special autoexec.cfg config?
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5094#issuecomment-1660123946
Im using a bunch of mods such as animations, retextures remodels etc.
And i am also using mastercomfig and an autoexec, mainly for fps
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5094#issuecomment-1660135824
Ah ok. It could be that the mods are having a bit of impact on the loading time, but not sure regarding the mastercomfig and autoexec. Maybe Valve made some changes to the commands on how they behave now or other background changes in the games code.
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5094#issuecomment-1660138138
well as the original author said, the loading times were way quicker before the 2023 summer update (15-30 seconds), with almost the exact same mods and i didnt install any mods that have a heavy impact on performance or loading times
well as the original author said, the loading times were way quicker before the 2023 summer update (15-30 seconds), with almost the exact same mods and i didnt install any mods that have a heavy impact on performance or loading times
Thats why I said that something must have been change in the code of the game by Valve.
Something that might be useful would be, to enter developer 4
into the console and then post the console output here that is being displayed when joining a server.
are there different levels of developer? last time i checked it was only developer 1, as in a bool
are there different levels of developer? last time i checked it was only developer 1, as in a bool
Yes.
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5094#issuecomment-1660200494
good to know, thanks
good to know, thanks
Your welcome. Would be great if you could enter developer 4
into the console, join a server and then post the console output here to help identifying the cause of the issue.
good to know, thanks
Your welcome. Would be great if you could enter
developer 4
into the console, join a server and then post the console output here to help identifying the cause of the issue.
yes, will do
Hm, there's not much interesting info you can get from the console output alone. It's better to see it in real time, because then you can see where it slows down. I've attached IDA's debugger into the TF2 process and noticed that these messages take the longest to appear.
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_eyes
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_whiskers
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_skin1
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_skin2
Debugged application message: MDLCache: Failed load of .VVD data for props_selbyen/seal.mdl
Debugged application message: A custom HDR cubemap "materials/models/player/shared/eye-reflection-cubemap-.hdr.vtf": cannot be found on disk.
This really should have a HDR version, trying a fall back to a non-HDR version.
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for vgui/maps/menu_photos_jump_academy2_rc9a
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_eyes
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_whiskers
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_skin1
Debugged application message: CMaterial::PrecacheVars: error loading vmt file for models/props_selbyen/seal_skin2
Debugged application message: A custom HDR cubemap "materials/models/player/shared/eye-reflection-cubemap-.hdr.vtf": cannot be found on disk.
This really should have a HDR version, trying a fall back to a non-HDR version.
Debugged application message: A custom HDR cubemap "materials/models/player/shared/eye-reflection-cubemap-.hdr.vtf": cannot be found on disk.
This really should have a HDR version, trying a fall back to a non-HDR version.
shiny seals too stronk for sorse. Also don't just go around attaching debuggers to the game, it'll most likely get you banned. I've done my homework and protected myself from such a possibility. There's definitely a better way to see the console output in real time, but this is the most convenient option for me at the moment.
I would appreciate it if you could post the COMPLETE console log when using developer 4
here's my console log with developer 4 enabled, from lobby to the match and back to the main menu condump005.txt Takes 3+ minutes to load into the match and around 10 seconds to disconnect
Thank you for the log!
I will highlight some things that seem a bit confusing for me that might cause this issue, but not 100% sure.
Any updates on this issue?
Any updates on this issue?
seems to be better purely based on my feeling
edit: nvm it's the same
Apparently it will be fixed in the next update (it is not known when it will be, but probably this week)
I was often failing to load into games before I capped my framerate to 144 FPS. Now I load in but it's still very slow.
There's a Linux + AMD GPU bug where the memory clock of the GPU will sit at the minimum value (96 mhz) while the game is loading. It seems that the game is trying to load data into VRAM and that's why it takes so damn long. If I open another slightly intensive game (I use Runescape) my system will bump the GPU's memory clock and then TF2 loads very fast. Yes TF2 actually loads faster by adding more load to the system.
Perhaps this is affecting Windows users too?
Linux users should note that AMD GPU memory clock management is pretty broken right now. Some users report the memory clock being stuck at the minimum even in games. Other users report that it gets stuck at varying values depending on the refresh rate of their monitor... You should be running the latest kernel for the best odds of it working properly. Here's the relevant thread.
There's a Linux + AMD GPU bug where the memory clock of the GPU will sit at the minimum value (96 mhz) while the game is loading. It seems that the game is trying to load data into VRAM and that's why it takes so damn long. If I open another slightly intensive game (I use Runescape) my system will bump the GPU's memory clock and then TF2 loads very fast. Yes TF2 actually loads faster by adding more load to the system.
Perhaps this is affecting Windows users too?
Linux users should note that AMD GPU memory clock management is pretty broken right now. Some users report the memory clock being stuck at the minimum even in games. Other users report that it gets stuck at varying values depending on the refresh rate of their monitor... You should be running the latest kernel for the best odds of it working properly. Here's the relevant thread.
this seems plausible. i'm on an amd gpu myself, an rx560. i tried this theory out on windows and noticed the same behaviour, except i loaded my gpu with furmark limited to 30 fps as to not load it too much, just enough to bump up the clock and memory speed. it seems to be just a bit faster too under load!
I've tested this now with my RX6600's memory clock manually set to the maximum value. My game loads around 60 seconds faster (80s -> 20s). Here's the ChatGPT thread where I figured out how to do it in Linux. There's a summary at the bottom.
Has this gotten any better? with the recent update?
Still not fixed with the recent update.
Can confirm, this problem has not been fixed. Just now I tried to join the server and measure how long it takes: the first load (with preloading) took 2 minutes 46 seconds, the second load - 2 minutes 15 seconds.
Chances this will be fixed on scream fortress?
Chances this will be fixed on scream fortress?
0
According to patch 210366
Changes to help improve load times
Longer loading times should now be fixed. This requires retesting.
Yes, i tested just now and it's fixed (at least for me)
Chances this will be fixed on scream fortress?
i was wrong as it was fixed on scream fortress lol... works good for me
Yep, it works pretty good.
Since the problem has been fixed, I am closing this issue. @kisak-valve, please remove the "Need retest" tag.
After the update, I have a problem: Loading to the servers takes a very long time (about 2-3 minutes. It used to be about 30 seconds or something like that) Okay if it was at the first connection, but no. It takes a very long time every time.