Got Stuttering On Pc With Gsync Or Vsync Monitor? - Microsoft Have Released A Patch

I can't say I've ever seen that happening!

 

I never saw that either. Seems quite bizarre. Do you use any rain mod? Maybe that´s related to the windshield rain textures.

Cheers

 

Nope, no mods at all.

Will try r.AmbientOcclusionLevels=1 today. I also have headlight flickering, so maybe it's connected! Will report.

 

While testing g-sync I found something interesting that maybe helps you too. With g-sync smoothness is greatly improved but I still had some intense lag when facing heavy tiles, such as Hagen in RRO route. I monitored RAM and noticed that Hagen added like 2Gb of memory to my graphics card upon loading, but I discovered that memory was bouncing up and down during the tile loading process (increased a bit, then suddenly reduced it by 1Gb and then increased by the 2Gb at the end of the loading process), and that resulted in severe fps drops. Why was that happening? It shouldn´t as we are just adding content to memory, not deleting it. Then I prepared a short test to reduce frame latency to the min and load as much as possible into memory upon start to reduce the bouncing effect and found a couple of interesting things:

1) The memory bouncing effect created severe lag indeed and the reason was that objects registration and unregistration was unbalanced, and as those processes are also active during the tile loading process they were creating problems. Using the following settings resulted in a equally balanced creation/destruction rate with the lowest disturbance per frame, which helped a lot to load such a heavy tile:

s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=100
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=1 --> this could be even 0 (priority load won´t add any extra time per frame)
s.LevelStreamingComponentsRegistrationGranularity=100
r.Streaming.NumStaticComponentsProcessedPerFrame=100​

The "100" variable values were just set for the testing in order to get the bigger amount of objects processed per frame, but you may want to reduce them to 50 or 30 depending on you system if you face too much lag on tile loading. I noticed that the better results are achieved when they are all the same or close to same value. Initially we discussed that using s.LevelStreamingComponentsUnregistrationGranularity=1 value was better as it disturbed less each frame and therefore it produced less stuttering, but it´s not the case on heavy tiles, as just before the heavy tile loading there´s still a lot of objects from the old tiles in memory, as they are destroyed at a slower rate than the rate used for creating new ones. So the more balanced the creation/destruction rate the better for heavy tiles. You can also adjust the updated times and use something like 5 instead of 1, but again try to use similar values on them. I just used 1 to have the less time dedicated to the process per frame. For instance, something like the following can also work fine, but as we increased the update times and reduced the granularity you may notice that the overall tile loading takes longer than with the previous settings:

s.UnregisterComponentsTimeLimit=5
s.LevelStreamingComponentsUnregistrationGranularity=50
s.LevelStreamingActorsUpdateTimeLimit=5
s.PriorityLevelStreamingActorsUpdateExtraTime=5
s.LevelStreamingComponentsRegistrationGranularity=50
r.Streaming.NumStaticComponentsProcessedPerFrame=50​

In my opinion the lower the update times and the higher the granularity the better, specially with g-sync, as you keep the fps steady most of the time. Even setting a bit higher granularity for unregistration than for registration can help to reduce tile loading effect, as you clean more old objects before creating new ones, so the memory load on the graphics card should be lower when facing the new tiles. Remember not to increase the granularity too much or you may be generating hitching. Granularity values much higher than 100 start to produce hitching in my case.

2) The loading process is improved when using r.CreateShadersOnLoad=1, as the shaders are not processed during the tile loading, but all at the start. I discarded that setting in the past as it didn´t produce any result on regular tiles, but indeed it helps with heavy ones. In particular this variable added to the other ones related to disable streaming produced the best results:

r.TextureStreaming=0
r.CreateShadersOnLoad=1
​

Garbage collector was still disabled and the scheduled cleaning left at a mid value as now we destroy more objects (10-15 minutes cleaning would be enough). Heavy tiles are greatly affected by viewdistance so you should not use too high settings.

My complete settings after those tests are set as follows for regular gameplay under DX11 and g-sync:

[SystemSettings]
r.MotionBlurQuality=0
r.TextureStreaming=0
r.CreateShadersOnLoad=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=600
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=600
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=100
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=1
s.LevelStreamingComponentsRegistrationGranularity=100
r.Streaming.NumStaticComponentsProcessedPerFrame=100
r.ViewDistanceScale=2
r.StaticMeshLODDistanceScale=0.25
r.LandscapeLOD0DistributionScale=4
foliage.LODDistanceScale=5
r.Shadow.DistanceScale=2
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
ts2.passenger.DensityScale=2​

I hope this helps a bit more to achieve the best possible results on most systems.

Cheers

 

Awesome, thanks again for the detailed in-deph explainations!
I try it with "80" and see if it's better than already

 

Nice. I would even suggest to disable completely the garbage collector. The scheduled cleaning still adds minor lag, even if set to high values, so use:

gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingLevels=0​

together with the old variables we disabled:

s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0​

It works much better during tile loading. But then remember to set something in the unregistration variables so that objects are being deleted and memory does not increase without control. The min values for unregistration to work are the following (1ms per frame and 1 object per frame):

s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=1​

If you set any of those variables to 0 then no memory cleaning at all will happen, which is not a good idea... Keeping granularity balanced for registration and unregistration is the best I think. The time limits just help on the frames latency. The lower the value the less disturbance to fps.

Anyway remember that whenever a tile is loaded all pending tasks which were not processed in time will be completed automatically, no matter how long it takes to do it, and that will create hitching, so don´t play around too much with the granularity as all needed new objects will be created and old objects will be destroyed, even if you set granularity variables to their lowest values of 1. Removing completely that hitching I think is virtually impossible, unless you have a NASA system or the route details are low. But those settings just help to arrive to the tile loading event with the best possible situation for your system and can be used to tune a bit the workload and remove the unwanted lags and hittching.

The absolute min values for the variables related to creation/destruction are:

s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=1
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0 --> this can be 0 as it´s added to the ActorsUpdateTimeLimit as extra time
s.LevelStreamingComponentsRegistrationGranularity=1
r.Streaming.NumStaticComponentsProcessedPerFrame=1
​

Those min values produce the less latency on the fps but may not be enough to load even regular tiles without hitching, that´s why you most likely need to increase either granularity, update times or both to values higher than 1 if you experience small freezes or hitching during regular tiles loading. Take into account that with them you will be creating/deleting 1 object per frame, so at 60fps you will handle 60 objects in a second for instance. Setting those variables to 0 results in no objects creation (incomplete tiles creation) or destruction (memory increasing without control), so don´t do that

Cheers

 

Juicy and interesting new findings...

Some new variables to tune frame latency:

s.AsyncLoadingTimeLimit (defaults to 5)
s.PriorityAsyncLoadingExtraTime (defaults to 15)
​

Similar to the case of object creation/destruction they book some time in miliseconds per frame to perform async loading. The second one is added as extra in case of priority loading, exactly as it happened with actors registration times.

What I found after discovering those new variables is that the higher the fps the faster the workload is being handled, as the more frequently per second the tasks can be done. So after adding now those new variables if we reduce the timers booked per frame to perform tasks we can remove many of the bottlenecks and the major hitching we have when facing heavy tiles.

Therefore I decided to set config to get the lowest possible latency (delay the less possible every frame), reduced the objects creation/destruction per frame (as anyway all things are spawned when tile is loaded if thread did not have time to do it per frame), get rid of garbage collector and the results were really good with the combination of those variables.

I used the following config for those particular tests:

[SystemSettings]
r.MotionBlurQuality=0
r.TextureStreaming=0
r.CreateShadersOnLoad=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingLevels=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=1
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0
s.LevelStreamingComponentsRegistrationGranularity=1
r.Streaming.NumStaticComponentsProcessedPerFrame=1
s.AsyncLoadingTimeLimit=1
s.PriorityAsyncLoadingExtraTime=0​

The following is just the portion for graphical details I used (you could skip this portion or use your fav settings for this):

r.ViewDistanceScale=3
r.StaticMeshLODDistanceScale=0.25
r.LandscapeLOD0DistributionScale=4
foliage.LODDistanceScale=4
r.Shadow.DistanceScale=2
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
ts2.passenger.DensityScale=2
​

I have being testing this in several routes and the results are consistent. Hagen and Munich are still a challenge, but the rest behave quite good. If you could also test it and comment your results that would help us a lot to know if this is a valid working solution for more people. Fine tunning of those variables may be required (for instance increasing timers or granularity to allow some more work to be done per frame) but I really didn´t need it. Initially I just set them to get the fastest possible work handling in terms of performance per frame and those lowest values turned to be a good combination indeed for most routes and they helped me to get rid of the tile loading bottlenecks, which were the main reason for many of the other performance problems I had in the past.

Cheers

 

geloxo you are awesome!
I spent the entire Sunday driving the BR 101 up and down HRR. There were two locations where I got framedrops and a one second hang because of tile loading. Then I discovered your follow up post regadring "disable GC entirely but let stuff become destroyed granulary anyway" just FIXED any hangs. It happened the first time I was "surprised" by meeting a train (because there was no micro hang during spawn) it's incredible.

I settled with this config (had 70 / 80 but upped +5 yesterday after ending my session - will test 75 / 85 this afternoon):

Spoiler: engine.ini

r.CreateShadersOnLoad=1
r.TextureStreaming=0
r.Streaming.FullyLoadUsedTextures=1
r.Streaming.HLODStrategy=2
r.Streaming.UseFixedPoolSize=1
r.Streaming.PoolSize=0
r.Streaming.NumStaticComponentsProcessedPerFrame=75
s.LevelStreamingComponentsRegistrationGranularity=75
s.LevelStreamingComponentsUnregistrationGranularity=85
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0

Edit: You posted new findings while I wrote this so I'm testing the new vars you shared

 

Thanks mate. Nice to see it worked fine as well on your system.

It´s clear to me than the key for tile loading is the work allocated per frame, so the faster the fps you get the more work is executed per second due to the nature of UE4 and the bottlenecks they create have an impact on the rest of running tasks. Garbage collector is a problem in general and I think it´s not really required and in general the existance of too many tasks allocated per frame, as they add some delays to the main thread, not because they take too much time to complete themselves but because some of them add artificial delays (timers) to the thread execution which are not always really required and forces the thread to pause. Garbage collector is the perfect example: even if not triggered it still adds a timer to the thread (10min, 5s, or whatever is used), so every frame is lagged by maybe just some miliseconds, but enough to lag the entire thing. The more lagging components we have the worse.

There´s another GC variable related to low memory that can be also disabled if you want (I will edit previous posts to include it too):

gc.LowMemory.TimeBetweenPurgingPendingLevels=0
​

Indeed the low memory variables have no sense to be active as the low memory threshold is defined as 0 kb in default settings. You will never use those variables therefore as your system would be in an out of memory situation before being even able to use them, but they are still active in the thread so they lag it a bit, and here every penny counts.

One of the keys for optimizations is to balance and even remove those timers. I hope DTG can take a look here as definitely game can be optimized just by using the right variables.

Cheers

 

Is this useful for DX12 too?

 

I know what I will be trying tomorrow, helpful as always geloxo

 

Yes it is. The involved variables are not dependant on the DX mode you use Cotax.

Cheers

 

A new patch for Windows 10 that has a more permanent fix for the sync problems introduced with earlier updates has started to roll out in Windows Update today.

Paul

 

I really appreciate your work and invested time in all this, I wanted to give you some feedback about the latest settings.
I do experience just a little more hitching than the previous settings, but I guess that has to do with my system. Also some micro stutters allong the way (spawning trains and stations, I tested it on HRR for now.
I run a RTX 2070 Super and an i7 8700K with 4.9 gHz OC.
Cheers

 

This is really interesting. Just putting my PC back together after some upgrades, so assuming everything works and the reinstall of TSW goes smoothly, I’ll be giving this a try.

Keep up the good work geloxo

 

Now I have consistent results everytime I repeat the same test savegames I had. At least after having repetead the same one this afternoon like 10 times I always got the same results on all the repetitions.

So I left my settings after that as follows:

[SystemSettings]
r.MotionBlurQuality=0
r.TextureStreaming=0
r.CreateShadersOnLoad=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingLevels=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=10
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0
s.LevelStreamingComponentsRegistrationGranularity=10
r.Streaming.NumStaticComponentsProcessedPerFrame=10
s.AsyncLoadingTimeLimit=1
s.PriorityAsyncLoadingExtraTime=0​

And for the details the same as before:

r.ViewDistanceScale=3
r.StaticMeshLODDistanceScale=0.25
r.LandscapeLOD0DistributionScale=4
foliage.LODDistanceScale=4
r.Shadow.DistanceScale=2
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
ts2.passenger.DensityScale=2​

So I still use low timers to get the best possible latency but this time just added 10 on the granularity instead of using the original 1 (which was too low indeed). As I normally get an average of 50 fps during regular driving this means I´m requesting to create/destroy 50x10 = 500 objects every second to the thread, which I think is reasonable for regular tiles handling on my system without generating further hitching (I could increase it to 1000 objects maybe but I think this is ok so far). Game uses a default granularity of 10 as well for the actors but 50 for the static objects and that would mean something like 50x50 = 2500 objects per second for the same 50fps, which is too much for my system at least as I see hitching on the tiles loading. And also it uses a 5ms timer but those 5ms add a extra small lag on every frame so I prefer to get rid of them and use 1ms instead. Garbage collector is still disabled. I will extend the testing to the other routes and try to perform as much repetitions as possible to confirm that the fixes work well and work always.

On your systems you may need to tune granularity as well. Too high values can produce hitching. The results also depend on the fps you get. With higher average fps (like 50-60fps) the lower the latency you get is the better (so the lower the timers the better) as you allow system to perform more tasks per frame and therefore per second, but if you get like 30-40fps average then you will not be able to handle as much operations per frame and you may need to tune timers or granularity. But some of the key elements to get rid of those lags in the tile loading are related to the above variables. That´s clear to me now after having run the tests and after the confirmation from other users as hyperlord as well who also sees the same benefits as I noticed.

In my case I was having typical tile loading lags lasting around 1s every 1km driven on the route and most of the time they came with fps drops like 10-15fps even with average tiles sometimes (noticeable when using g-sync therefore). After tunning the variables I just have microlags lasting around 0.1s which is almost nothing at all during regular and medium tiles loading or when driving high speed trains. The hugely populated tiles are not handable at all no matter what settings you use, so we have to live with them. But to me this has been a huge improvement without any doubts during most of the driving time.

Cheers

 

The patch is actually a rollback via the "Known Issue Rollback"-Function (KIR) in Windows 10. Basicly Microsoft marked the offending update as "harmful" and it will not be deployed anymore - those who have it installed get the "uninstall-command" via Windows Update.
The problems could reoccur in future updates but fingers crossed ...

https://www.ghacks.net/2021/04/24/microsoft-fixed-the-game-performance-issue-on-windows-10-devices/

 

Hi,

I found extra documentation and I think s.MaxLevelRequestsAtOnceWhileInMatch is not really applicable for this game. It´s used while player is in a match mode game (like shooters or so). As this game is single player only it has no sense and indeed it does not produce real benefits after deeper testing. Just remove it as I don´t want to propose changes that really don´t work or we can see a clear effect when enabling/disabling them. Just keep the async timers as they are the ones from the latest addition that indeed help. I updated the other posts to avoid confussion.

Cheers

 

Can’t test tonight, but intend too tomorrow.
Just awed by your dedication.

 

Thanks a lot davidh0501. I have something new to share which really shocked me

This was the result of a non-planned stress test, just to take system to the limits out of curiosity. Once I was happy with the low latency achieved by setting timers to 1ms I thought it would be a good idea to check the impact of the granularity variables in game. So, trying to find the upper limit which started to cause hitching I set them to something insane like 10000. The result was that I could load Hagen without almost no lag at all, just a couple of short lags lasting less than 0.5s each. Mmmmm... Amazing!

See the following pic (train is at max speed there, so the worse situation for rendering). I always used that savegame to test RRO route where I started 10km away from station to check the whole max speed track section. Therefore around PK 138 the laggy nightmare started as usual, as it´s more or less where Hagen tile is loaded for the viewdistance I have used (x3 value). Before, with regular granularity like 10, 20 or even 100 I had like 10 hitches one next to the other lasting 1s each more or less and a terrible fps drop from 60 fps to 25 fps. Horrible, as the tile loading needed several seconds to complete and was a total killer... Now it loaded in just a couple of iterations with minor hitching of less than 0.5s each and the fps where above 45 fps during the loading. I never saw something like that during the years I have been playing this game...



This shouldn´t happen as according to documentation the very high values can turn into hittching. I have no other explanation for this than using an insane value just acts as an "unlimited" value, allowing the max possible amount of objects to be handled per frame. This, combined with the lowest timers results in such an amazing discovery. I repeated test multiple times, restarted game and repeated it even to be sure memory was totally clear and so on but I always had the same good results. There was no negative impact on other routes which were working fine with the previous regular tweaks. And yes, Hagen tile was there, fully generated and with all its beauty, including the town, tracks and even an AI train in the station, as you can see in the following pics.





Please guys check this as well if you don´t mind (or even try to use values like 1 million instead of 10 thousand) and comment results and this is bizarre but they are really, really good news for sure, as Hagen was one of the nightmares apparently impossible to be handled by tile loading efficiently no matter which settings you used. Munich also loads faster but there a x3 viewdistance is not possible as the fps drop below 30 so the overall generation process is affected. I guess for that case I would need to stay with a x2 viewdistance as top value which is still really good for driving.

The values I used for that testing were the following. Just the 10000 values for granularities were changed from previous post but maybe much higher values are still possible on those variables. Rest of the variables are the same as before:

s.LevelStreamingComponentsUnregistrationGranularity=10000
s.LevelStreamingComponentsRegistrationGranularity=10000
r.Streaming.NumStaticComponentsProcessedPerFrame=10000​

The complete proposed config for regular gameplay is:

[SystemSettings]
r.MotionBlurQuality=0
r.TextureStreaming=0
r.CreateShadersOnLoad=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingLevels=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=10 <-- regular values like 10 or 100 to be used (10000 just for stress)
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0
s.LevelStreamingComponentsRegistrationGranularity=10
r.Streaming.NumStaticComponentsProcessedPerFrame=10
s.AsyncLoadingTimeLimit=1
s.PriorityAsyncLoadingExtraTime=0
r.DynamicRes.FrameTimeBudget=0
r.ViewDistanceScale=3 <<-- don´t go too extreme with this as it´s one of the main performance killers (x2 or x3 should be fine)
r.StaticMeshLODDistanceScale=0.25
r.LandscapeLOD0DistributionScale=4
foliage.LODDistanceScale=4
r.Shadow.DistanceScale=2
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
ts2.passenger.DensityScale=2​

You can adjust graphical details variables (viewdistance, LODs, shadows, etc) using your own preferences.

I need a whisky now to celebrate this finding!

Cheers

 

Woah finished my run and wanted to report my findings and came here to find this :-D
I'll try the "unlimited" mode tomorrow hahaha nice

What I wanted to share since I'm more in the regular 30-45 FPS area:
s.AsyncLoadingTimeLimit=1 with 10-25 resulted in a kind of vanilla experience but setting s.AsyncLoadingTimeLimit=2 changed that significantly for me.

Why thought? Is it your CPU (much better) or GPU (better)?

Will report back how can I sleep now with such curiosity!?

 

I hope TrainSim-Matt is watching this thread and the impressive performance contributions from geloxo and the small army of willing testers . Once these settings are proven more widely on more hardware it would be cool to get them into the game so others can enjoy them too.

 

I hope so as well. I think there could be some light to improve game. The settings are not the gold key to solve it as they can be very system dependant as we have seen, but the features behind them are what DTG can explore.

In my case my system benefits from the low latency per frame (low timers) as it helps me to keep high fps, which turns into more iterations being able to be addressed to the main game thread per second as well (because I get more frames per second values). For instance if I used 50ms timers the whole process turns laggy and it´s harder for my system to load tiles. On the other hand the high fps have a problem as the fps drops when facing heavy tiles are more extreme and you can find a drop from 70 to 30 in just 1s. This is too much even for g-sync as it can´t keep it smooth with such a severe drop. So the best would be able to maintain as much stable as possible fps values during the whole route, even if they are lower values like 40 fps. This allows g-sync to produce also better results without facing extreme fps drops but on the other hand less iterations will be addressed to main thread per second. This is a bit tricky situation, not so easy to handle unless you just reduce graphical quality to reduce overall workload.

I also noticed that with a x3 viewdistance the tile loading is smoother than with a x2 or even x1 one, which shouldn´t be the case as we are adding much more details to overall scene with such a high viewdistance. A reason behind it could be that despite the increased details more objects are either stored in memory in advance or processed in advance when they are just visible with lower detail LODs, reducing the workload peaks that may happen if they were processed later in time (or closer in distance to player) but with higher detail LODs.

Cheers

 

The only downside I've found so far (and perhaps it was there before and I did not notice) is leaves coming and going on trees in autumn when you use the scroll wheel on a mouse to zoom in and out while looking at distant hills. Apart from that its amazingly smooth so far.

 

Ok
I just did a complete copy paste of your engine.ini.
Only had time for a SEHS and it was buttery smooth.
Including outside views.

Running an i7 with 16gb and a 2060rtx at a locked 60fps due to monitor.
I prefer smoothness to high fps as no one is shooting at me.
Will try some German high speed later.

 

Good news. I think we are on the good way. Thanks for taking the time to confirm results.

Today I saw another timer that shouldn´t be there. It´s related to dynamic resolution (adjust screen resolution dynamically to maintain a fps target). This feature is not used in this game and indeed it´s disabled in game config, but we still have a frame timer adding 33ms to each frame that we can remove to be sure no extra lag is charged to each frame as we don´t use that feature. Every penny counts... You can try adding:

r.DynamicRes.FrameTimeBudget=0​

This will set that timer to 0ms, so it completely disables it (we don´t need that timer at all as the main feature is also disabled). I just started to test it and allowed me to reduce the granularity below those insane 10000 values (even if they worked fine) to the lower original values of 1 or 10 again and still load Hagen tile fluently. So it has a positive result. I will test it anyway more deeply today but apparently it could have been a bottleneck for tile loading (it booked like 10 times more frame time than the other timers). Previous post updated to include it in proposed config.

Cheers

 

Hi,
I tested the setting in the Munich area and the last setting (r.DynamicRes.FrameTimeBudget=0) is definitely a big improvement, the hitching is also a lot less.
Thank you so much for your time.

 

You are welcome robski. Yes, the original value should not be used as it lags 33ms each frame for a feature (dynamic resolution) which is not even used at all by game. The other timers are typically around 5ms each in default config (much lower) but this one is really relevant as it´s one of the highest artificial delays set to frames together with the low memory ones set by garbage collector, which we also disabled as it´s not used by game either (the low memory limit is set to 0kb in default config so the event will never happen).

Maybe there are more of those bugs included in the configs. Who knows... At least we cleaned a bunch of them and proved that performance can be much better. I hope devs can read this because this is also useful for them.

Cheers

 

I just finished the latest settings with timer on SEHS driving the 1F34 13:25 service Javelin from St Pancras to Ebbsfleet
DX11 60fps (I've set it to this as a limit), occasional pauses when loading along route and when passing another train at 225km/h, dash in the loco seemed slightly blurry
DX12 50fps in open air, 60fps when there isn't much to draw (eg in tunnels) buildings and vertical things seem "edgy", dash not blurry but the edges of things are annoying in the tunnel, similar loading pauses and when passing another train - 1 to 2 second pauses in the open air on the raised track between the tunnels
Neither had any hitching - very nice drive by with free cam - smooth
I run FXAA and screen at 100% in windowed full screen

Even though its midnight, I went back to the previous settings with your new timer
[SystemSettings]
r.MotionBlurQuality=0
r.TextureStreaming=0
r.CreateShadersOnLoad=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingLevels=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=10
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0
s.LevelStreamingComponentsRegistrationGranularity=10
r.Streaming.NumStaticComponentsProcessedPerFrame=10
s.AsyncLoadingTimeLimit=1
s.PriorityAsyncLoadingExtraTime=0
r.ViewDistanceScale=3
r.StaticMeshLODDistanceScale=0.25
r.LandscapeLOD0DistributionScale=4
foliage.LODDistanceScale=4
r.Shadow.DistanceScale=2
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
ts2.passenger.DensityScale=4
r.DynamicRes.FrameTimeBudget=0
I ran again the same service with DX11 - I'm not going to do DX12 as well... I need to be at work in eight hours
Sat on 60fps the entire time. Very light pauses at the loading places but not massive and didn't impact frame rate. Buildings not edgy. Dash clean.

Paul

 

So s.MaxLevelRequestsAtOnceWhileInMatch=2 is gone now, right?

 

Sadly, after doing some digging I learned that my motherboard's chipset won't support overclocking, even if I got a CPU that does.

 

So far yes. I think it´s not applicable as this game has no "match mode". At least I didn´t see a clear relationship so that´s why I removed it. It shouldn´t harm to leave it anyway if you want.

Cheers

 

Some quick notes from my playing this evening.

All runs done on SEHS on the Extended Service scenario using the latest proposal above. Everything on Ultra.

1) DX12, No frame rate cap. Run from Rochester to Gillingham, frame rate around 120 - 140. Lots of short pauses some screen corruption in tunnels. Stuttering was worse than a plain install of the game so gave up.
2) DX11, No frame rate cap. Run from Rochester to Gillingham, frame rate around 100 - 120. Only a couple of micro stutters.
3) DX11, Capped Frame rate to 60. Set Screen Percentage to 200%. Frame rate was solid, was so nice I played through the whole scenario. Still a few Micro Stutters, but if you are playing around with cameras and checking instruments etc hardly noticeable.

At this point I got optimistic and jumped over to Münich Augsberg same settings as 3) above. Wasn't too hopeful, but it was pretty good. Solid 30fps out of Münich, as soon as I was clear of the busy area the frame rate jumped back up to 60fps with the same smooth run as above. Münich area still had pauses and stutters though. Will be interesting to try it with DX12 as that was what I was running with before some PC upgrades and I remember it being better.

So promising results on SEHS. The 3rd run was really good. I'll read through the thread properly and play around with some settings at the weekend.

 

Good to know that it also improved gameplay on your case. We are going in the good direction. I think the remaining stutters will be hard to fix unless someone else points us to explore another approach, or maybe it´s just that we reached the optimal limits.

It´s not the garbage collector nor the timers as we already identified them. There must be something else hidden in the tasks which are repeated every frame which is lagging the thread during tile loading but it´s not easy to find clues in the current variable list contained in the documentation. Sound or lights/shadows are the other possible candidates to explore I could imagine, in case they are also managed in a frame based interval.

Cheers

 

They do! When FPS drop, sounds (not all but some) cut out. I also observe shadows spaning seconds later after the objects have loaded.

The last modifications took 10ms average away on my system which is great!
Got to point out that it's important to have the UnregistrationGranularity higher than RegistrationGranularity otherwise the experience worsens. I had by mistake set "all 3 vars" to 10 and ;-)

s.AsyncLoadingTimeLimit=1 with HMA is not really working well for me, but s.AsyncLoadingTimeLimit=2 seems to improve that. I think I need to fine-tune the Granularity and NumStaticComponentsProcessedPerFrame a bit more and test more routes but so far the game is really not hitching much anymore.

For me it's not clear on what hardware this performance boost belongs to. My 2060 Super has 8 GB VRAM, the system 24 GB so maybe I could try higher values. Need to find a way to monitor the GFX parameters during gameplay better ...

 

It had to be the shadows... Found one working candidate which used alone (without the garbage collector, timers, and rest of tweaks) is able to load Hagen faster by itself:

r.Shadow.WholeSceneShadowCacheMb=2048​

It defaults to 150Mb which it´s clearly too low to help caching the whole scene shadows. I started setting it to 2Gb but maybe even 4Gb (4096 value) is also healthy.

And now some comments about the previous settings, cause I reviewed docs carefully again. As I´m not really an expert on Unreal Engine this has been a learning process to me while testing:

1) The granularity and all those variables starting with "s." are indeed sound related variables, or at least most of them are classified into the sound category in the variable list. I think they are used to manage the object sounds inside the created tiles. So granularities themselves may not require so much tweaking provided that we leave them in lower values as we don´t really have so many objects producing sounds compared to standard objects like houses, trees, etc. Indeed they default to values like 1, 5 and 10. What I think is really relevant from all those "s." variables group are the timers, because they are the ones booking time per frame to complete tasks, so they have an impact on the amount of operations the main thread executes per second. If we don´t delay thread with high timer values the whole thing runs faster. This is one of the basis of UE to spread tasks into several frames to reduce workload on the main thread, allowing it to handle several tasks simultaneously, but it´s still the same single thread. That´s why we see side effects like rendering micro-frezzes or sound cutting until the tiles are fully loaded (this happens even with default settings). At least what I have seen is that reducing timers to values near 1ms removes a lot of overall lag, not only in the tile loading process. On the other hand increasing them appears to be intended to allow weaker HW to handle the required operations, as timers basically pause thread to allow system to complete operations that would normally require more than the time of a frame to be completed. They are like a while condition: while time < timer thread will do some specific work inside the current frame and after that it will jump to the next pending tasks (rendering, sound, etc). What granularities do is to define how many items will be handled in the current frame while those timers are not elapsed, so they group things to optimize the usage of the available booked time.

2) The variable r.Streaming.NumStaticComponentsProcessedPerFrame appears to be the one really handling 3D objects (it´s an "r." type one so it´s in the render family). This helps to create new levels (tiles) gradually before they become visible by processing a certain amount of components per frame. It defaults to 50 but I have seen than setting it alone to 10000 like in the stress test helps to load Hagen much faster. Indeed I repeated some tests by changing this variable alone and (after having used 1ms timers) it had no effect until I decided to use the insane 10000 value. But it has an impact on tile loading when you use higher timers like 20ms, 30ms or 50ms. In that case setting it to values in the range of 10-20-30 improves tile loading compared to values like 100-200-300. I think it just helps because it prevents that too many things are done during too much time, which may result in hitching. Anyway the tiles will be generated at the end no matter which variables you set, as all pending tasks will be called once tile is made visible, no matter how long it takes to complete the process. The typical result of this situation is a hitching like in heavy tiles loading, so that means there was no time to "pre-process" the tile using the tasks repeated at the frames just before the tile became visible. That´s why at high fps you can load heavy tiles much easier than when you have lower fps, as basically more operations are executed per frame, and therefore per second.

3) Disabling texture streaming is also helping a lot, not only because it improves the texture visuals but because it loads textures into memory for the whole scene. What I did to test it was to use an external SW to clear my system memory. I run one of the test scenarios without cleaning memory and then repeated it afterwards cleaning memory few km before the tile loading event was happening (in the arrival to Reading station in that scenario). After cleaning memory the tile loading containing Reading station lagged like hell, while it was smoothly loaded if no cleaning was performed with the external SW.

4) Disabling garbage collector helps a lot mainly because it´s triggered just during the tile loading. This has been discussed also many times in the unreal forums as being a reason for hitching. Some guys even suggest to completely disable it with a command line option. Unless you run the same route for 8h non stop I see no reason to have it as memory is purged anytime you exit game to route selection menu, so memory does not increase so fast after disabling it. Anyway it´s called garbage collector for some reason, so definitely it will clean things, so I think it´s still required by game.

5) And last but not least are the graphical settings. From that group the relevant variable is r.viewdistancescale. It´s a performance killer itself so you can´t go to high values without losing up to 20fps overall but it also has a benefit as I explained some posts before. Using a higher value (3 instead 2) helps to load heavy tiles. I think the reason is that it helps to process more distant objects in advance without a big impact as they become visible but just with their lowest details. If not they would become visble in one go (pop-in) but with higher details, which is worse to handle for the system, specially if what is loaded is a big station with many details, trains and things like that.

I will take some time to refine the variables settings and run some new tests after using the new shadows cache variable, as maybe we can clean a bit the overall list and get rid of some of the current variables we use if they are not helping that much.

Cheers

 

That's a bit of a bummer. Time for a new MOBO . Trouble is when you change MOBO you usually end up having to change everything else too.

Paul

 

greetings to all...

sorry for my english, but i need to use google translate.

First of all, thank you for the forum, as I am solving most of my micro stuttering issues.
especially geloxo, for all his work, knowledge and time invested in trying to make TSW2 work and sharing all of that with us.
today I'm going to test the latest .ini values you posted ...
I currently have it like this ...

[SystemSettings]
r.MotionBlurQuality=0
r.Streaming.HLODStrategy=2
r.Streaming.UseFixedPoolSize=1
r.Streaming.PoolSize=0
r.Streaming.NumStaticComponentsProcessedPerFrame=50
r.CreateShadersOnLoad=1
r.ViewDistanceScale=3
r.LandscapeLODBias=-2
r.LandscapeLODDistributionScale=3
r.LandscapeLOD0DistributionScale=4
r.StaticMeshLODDistanceScale=0.4
r.SkeletalMeshLODBias=-2
r.Shadow.MaxResolution=4096
foliage.LODDistanceScale=5
foliage.DitheredLOD=8
grass.densityScale=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=50
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=1
s.LevelStreamingComponentsRegistrationGranularity=50
gc.TimeBetweenPurgingPendingKillObjects=300
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=300

my pc is this

Ryzen 3600X a 4.200
RTX 2080 super
16 Gb Ram 3.200
I don't know if the values of my .ini will be correct for my pc, but I assure you that the game now works much better than before, less freezing and stuttering, I can maintain 60 or 50 fps most of the trip. game at 1440p all ultra with 130% screen,
locked in game and nvidia control, my monitor is freesync, but also unofficial g-sync compatible, but in tsw2 it does not work well, only with vsync, activated in game and nvidia control works very smooth,
any subjection on my .ini is welcome
I will continue testing the new values that you have published.

Thank you so much

a greeting

 

I'm happy to read that this also worked well on your system. If you guys get a better gaming experience using those settings this is what really matters at the end

Cheers

 

xoxema#2430 Thank you for sharing your ini! Your specs are not too far away and I applied your settings for my "critical variables" (50-50-50 instead of 10-10-100) and report back after testing

 

now I'm going to try the last .ini that geloxo published with the new variant. r.DynamicRes.FrameTimeBudget=0

r.MotionBlurQuality=0
r.CreateShadersOnLoad=1
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=0
gc.LowMemory.TimeBetweenPurgingPendingLevels=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=10
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=0
s.LevelStreamingComponentsRegistrationGranularity=10
r.Streaming.NumStaticComponentsProcessedPerFrame=10
s.AsyncLoadingTimeLimit=2
s.PriorityAsyncLoadingExtraTime=0
r.ViewDistanceScale=3
r.StaticMeshLODDistanceScale=0.25
r.LandscapeLOD0DistributionScale=4
foliage.LODDistanceScale=4
r.Shadow.DistanceScale=2
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
ts2.passenger.DensityScale=2
r.DynamicRes.FrameTimeBudget=0
r.Shadow.WholeSceneShadowCacheMb=1024

I will make some trips with this .ini and I will tell you to see ...

regards

 

Hi,
I tested the s.AsyncLoadingTimeLimit=2 setting instead of s.AsyncLoadingTimeLimit=1 and the performance is noticeably better.
I tested in the Munich area, the Hagen area and HRR. The HRR route especially got a major improvement with this setting for my system.

Cheers.

 

I can confirm that using 3 is a smoother experience than 2 (on my system) which I would have never thought! It seems like it handles AI train spawning better, too since I didn't have any microstutters at all when you meet other trains along the journey.

 

Tried the settings and game is much more smoother.

GTX 1070 8GB
16 GB DDR3
i7 4770K @ 4.1GHZ
Game on SSD 870 EVO
AOC 144hz G-SYNC monitor

Everything to ultra (expect foliage to medium), screensize 130%, FPS limit to 120.

Mostly i am around 60-90fps, 40-50 in busy areas. But it's much more smooth. There is still some stutering though, but frankly - it doesn't bother me so much anymore. Overall it's much more stable situation and no drop in visual quality (i compared the screenshots). geloxo thank you - I officially call you UE Engine Master

 

Hahaha. Thanks Cotax. I´m not a master at all. I just read the official documentation. Indeed I may be wrong in many of the assumptions I made or interpretation of the variables.

About the x3 viewdistance I´m still unsure about using it because, even if it helps to load things faster (as confirmed by hyperlord too), my system suffers a lot on tiles like Munich and so on. Also on LGV the tile loading is worse. But it improves loading distant things. I´m tunning the other variables and most likely I will stay with a x2 distance (the setting I have used for many months).

About the last proposed setting (r.Shadow.WholeSceneShadowCacheMb) I´m also unsure. Indeed I disabled shadows in game but still had the same residual lag on loading tiles, so that setting appears not to help me too much. Maybe if you use shadows in 4096 resolution it could help but in my case with 2048 resolution shadows I didn´t see a clear impact after deeper testing.

Cheers

 

GTX 1080TI SLI
32 GB DDR3
i7 6900K @ 4.1GHZ
screensize 150%
NVIDIA SETTING SLI 16X

[SystemSettings]
r.ViewDistanceScale=1
r.StaticMeshLODDistanceScale=0
foliage.LODDistanceScale=7
foliage.DitheredLOD=8
foliage.DensityScale=2.0
r.SkeletalMeshLODBias=-5
r.MipMapLODBias=-1
r.LandscapeLODBias=-2
r.MaterialQualityLevel=1
r.SSR.Quality=2
r.BloomQuality=3
r.Color.Max=1.0
r.Color.Mid=0.5
r.Color.Min=0
r.TonemapperGamma=3
r.EyeAdaptationQuality=1
r.DefaultFeature.AutoExposure=1
r.DefaultFeature.AutoExposure.ExtendDefaultLuminanceRange=1
r.HighQualityLightMaps=1
r.PostProcessAAQuality=6
r.MaxAnisotropy=16
r.LandscapeLOD0DistributionScale=4
r.MotionBlurQuality=0
r.SceneColorFringe.Max=0
r.SceneColorFringeQuality=0
r.DefaultFeature.MotionBlur=0
r.DepthOfFieldQuality=0
r.TemporalAACatmullRom=1
r.TemporalAASharpness=1.0
r.TemporalAASamples=64
r.TemporalAAFilterSize=1.0
r.TemporalAAPauseCorrect=1
r.ToneMapper.Sharpen=1
r.Tonemapper.Quality=0
r.Shadow.DistanceScale=2
r.ShadowQuality=5
r.Shadow.TransitionScale=2
r.Shadow.CSM.TransitionScale=2
grass.densityScale=1.5
r.Streaming.FullyLoadUsedTextures=1
r.Streaming.HLODStrategy=2
r.Streaming.UseFixedPoolSize=1
r.Streaming.PoolSize=0
s.ForceGCAfterLevelStreamedOut=0
s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
gc.TimeBetweenPurgingPendingKillObjects=300
gc.LowMemory.TimeBetweenPurgingPendingKillObjects=300
gc.LowMemory.TimeBetweenPurgingPendingLevels=0
s.UnregisterComponentsTimeLimit=1
s.LevelStreamingComponentsUnregistrationGranularity=50
s.LevelStreamingActorsUpdateTimeLimit=1
s.PriorityLevelStreamingActorsUpdateExtraTime=1
s.LevelStreamingComponentsRegistrationGranularity=50
r.Streaming.NumStaticComponentsProcessedPerFrame=50
s.AsyncLoadingTimeLimit=1
s.PriorityAsyncLoadingExtraTime=0
r.DynamicRes.FrameTimeBudget=0
r.Shadow.MaxResolution=4096
r.CreateShadersOnLoad=1

 

fanta1682002 Why do you use r.ViewDistanceScale=1? With your hardware, you could use higher values (2 or 3) for more trees on bald hills ;-)

 

play Hauptstrecke München - Augsburg Route ViewDistanceScale=3 fraps is 23

play Hauptstrecke München - Augsburg Route ViewDistanceScale=3 fraps is 24 München
Hauptstrecke München - Augsburg Route ViewDistanceScale=1 fraps is 36 München
have good settings?

 

Having recently added these most recently additions to TSW (copied pretty much what you've posted) I've found that after so long the PIS boards and collectable items such as route maps stop showing. I'm unsure which of these settings is resulting in that happening though?

 

Wow. The settings have nothing to do with collectables or PIS... I didn't see such effects and I'm using the tweaks for weeks now. Could you paste your config to see if something else could be creating problems? I would bet to any of the variables related to objects LOD being the guilty one.

Cheers