13 minutes ago, Cpt_Piett said:

I think there’s performance improvements for all Ryzen CPUs in 24H2. Is 24H2 the official build now? I’m in Insider dev channel and I’ll probably be stuck on that until Windows 12…

https://www.forbes.com/sites/antonyleather/2024/08/27/windows-11-24h2-surprise-11-game-performance-boost-on-ryzen-cpus/

Yes, I believe that is the current official build.  However, they are still in the process of rolling it out to all users through Windows Update.  I had to go grab the iso to get it installed.

Yeah, 24H2 has been released. They are phasing it in gradually over the whole world.  It's not a beta, it's the official release version.

It can be obtained by going and getting it if it has not been offered in Windows Settings.. That's how I got it onto my system. You just run an official Microsoft .exe file. It took about 30 minutes or something.

https://www.microsoft.com/en-us/software-download/windows11

 

 

@Sethos Just an update on my memory timings.  After adding an additional fan to keep the memory cooler (as I thought was the issue) I ended up with the following.  I couldn't tighten tRCDWR/tRCDRD any lower as my PC wouldn't POST.  I have yet to try and get tRP any tighter.  I also have not tried to disable PDM since not POSTing when I tried it before.  My BIOS would not let me go any tighter on the tFAW setting.  20 was the lowest setting in BIOS.  Almost 5 hours on absolut without any errors so I am pretty pleased with that.  I also adjusted voltages a bit and think that helped get these tighter timings.  Do you see anything else I might try to tighten in my timings?

Watching live of the twotonemurphy stream (2024 tech alpha) he is clocking in 31.2 gigs ram usage with ultra settings. Multlithreading is utilizing it?

Edited October 12, 20241 yr by JBDB-MD80

4 hours ago, jaxgator said:

@Sethos Just an update on my memory timings.  After adding an additional fan to keep the memory cooler (as I thought was the issue) I ended up with the following.  I couldn't tighten tRCDWR/tRCDRD any lower as my PC wouldn't POST.  I have yet to try and get tRP any tighter.  I also have not tried to disable PDM since not POSTing when I tried it before.  My BIOS would not let me go any tighter on the tFAW setting.  20 was the lowest setting in BIOS.  Almost 5 hours on absolut without any errors so I am pretty pleased with that.  I also adjusted voltages a bit and think that helped get these tighter timings.  Do you see anything else I might try to tighten in my timings?

I honestly wouldn't worry too much about getting those down any lower, it won't really have any significant impact. Also, tFAW only goes to 20 on our setup, anything under that isn't valid and it just reverts to 20 internally to my knowledge.

If you actually want to improve your performance, the biggest thing you could tweak is tRFC and tREFI. While 500 / 50000 is also already a massive improvement over EXPO settings, it can be pushed a bit further. I say this because you got the fan, it's generally advised once you move beyond 50000 that you get a fan on there because tREFI is very heat sensitive. So it's generally advised to keep below 50c. It'll go up to 65535 and tRFC you can maybe nudge down to 350-400.

That will have a bigger impact than small tweaks of secondary and tertiary timings at this point. But make absolutely sure you test it, because beyond 50k it becomes a lot more error prone and heat sensitive, so 50k might be a good spot.

And aside from the RAM, noticed your CPU VDDIO at 1.4. I'm running mine at 1.2 and it's stable, so in case you want to play around with that a bit.

On 10/11/2024 at 1:55 PM, Noel said:

What kind of evidence do we have that paging is substantially reduced when you have more  RAM installed?  I have 32Gb, rarely see more than 15Gb in use running MSFS plus 4 or 5 other apps, though have seen as high as 21Gb briefly.  

   @Noel, I tend to agree with this statement, not because I have tested with 64GB but because I also see similar 'In Use' RAM as you do and that's with FSLTL running at full steam. Maybe at heavy use airfields or high LOD airports it's more like 17GB or 18GB but in essence, MSFS2020 runs fine with 32GB RAM and 64GB wont make a blind bit of difference. The caveat of course is what else you want to do with the your remaining memory.  If you want to load all sorts of other applications while running MSFS, then at some stage you may indeed run out of memory. If you don't want to terminate some apps, then of course 64GB is going get you out of a world of hurt. But as regards stutters, I am going to say that memory is not the issue. We have to understand what actually causes stutters in 32GB of physical memory and I think we will accept that extra memory is not going to help that particular issue unless the stuttering is being caused by 'thrashing' ie when the  Memory Manager is being overwhelmed with calls with no or limited free memory to address the situation. So it just pages like crazy and that will of course introduce stutters. But that is not the normal situation and anyone in that situation won't be pondering this issue in this thread. They'll just go and buy 64 GB and move on.    

 

On 10/11/2024 at 5:03 PM, Bob Scott said:

 

It doesn't make sense to me that *any* actual paging would occur when you are maintaining over half of your 32GB of physical memory available.

Add to that the fact that the page file usage remains constant, and I would guess that the page file is just being populated with tabular housekeeping data like page allocations and block addresses to be used in case paging were to be triggered, and not actually performing paging of program data to/from the file system.

 

 

 

@Bob Scott. I also mostly agree with this statement. The rider on this one is that page faults can be soft or hard. An analogy (while trying  to avoid being too techy here) would be a game Rugby for example. The Memory Manager is like the coach. MM decides who's on the field doing their best at any given time. If MM sees a 'player' is not having effect, MM will bench the player into the Paged Pool. But when the game changes and MM decides the player is required back on the field of play, it will pull the player out of the Paged Pool. This is a soft page fault and it happens a lot but as @Cpt_Piett and others have noted, this type of paging can be very small, less than 1% in many cases. And, you are right.  Soft page faults are not paging data to/from the storage system.  Because it is happening at memory speed and is part of memory 'In Use', with plenty of available memory, this paging will not be causing any stutters. 

As a side note, Noel and Cpt Piett have both noted that Performance Manager appears useless at helping to understand what paging is actually going on. I am not entirely sure myself but I would guess we are simply seeing the soft paging since any paging to storage would be significant larger at any point where it happens. Additionally, the numbers shown in Noels Performance graph snapshot, appear to be for the processor, even though the processor box is not checked. (go figure?) Certainly, the very low percentage but essentially straight lines showing paging would reasonable explain very small amounts of data from the Paged Pool probably constantly being moved in and out as soft page faults. 

In contrast, a hard page fault is the one that is likely to cause a stutter since it is a movement between the slower speed disk drive and the memory and that takes time.  But whether it causes a stutter or not will depend so much on individual systems. Imagine a system with  Crucial T705 which is considered the fastest solid-state drive (SSD) available, with read and write speeds of up to 14,500 MB/s and 12,500 MB/s, respectively, coupled with DDR5 RAM at 6400 million transfers per second! I doubt you would see any stutter associated with this in normal use. But for most of us with DDR4 M/T of 2666 and an average NVME drive, we will experience some stutter when hard page faults occurs. And so it is hard page faults that we should be tracking, not soft page faults.  The Resource Manager graphs these hard page faults quite well. Hard page faults occur when new scenery comes into play and that's why approaching scenery rich airports or cities will solicit stutters. So too will just sitting at an airfield watching a static view until suddenly an FSLTL aircraft will spawn and if that model doesn't already exist in play, then a hard fault will occur as the MM drags into the game. Hard faults are the Memory Manager manipulating the paging system to ensure the system is using memory resources efficiently and is no cause for concern in MSFS using between 15 and 20GB of memory out of 32Gb. However, excessive paging may be either running out of memory or a page file limit set too low. It is best to allow the OS memory manager to determine what it needs. 

And so this is the first important point. The speed at which your storage and your memory will allow these transfers to occur will determine if you get stutters and if so to what degree. 64 GB of memory will have no effect on this. You will always have hard faults to one degree or another as a function of the processes going on in the game and extra memory will not change that.  

CPU and GPU. We know these are choke points. In my case I have a CPU whose Main Thread is entirely 100 % green!! Not a bit of black space anywhere! So naturally the FPS in Development mode shows 'Main Thread Limited' while my GPU is using only 6GB out of 12GB available. Yep, I got everything turned up so I deserve the stutters I get. If I turn things down a notch or three I can make it 'GPU Limited' but again, it's a pretty poor GPU and so any big LOD tasks are going to create stutters. (MSFS 2024 is hopefully going to fix this).

The second important point is that 64GB of memory will not help these stutters either since it is the CPU and/or the GPU are the limitation not the quantity or speed of the memory. 

The only place where I see 64GB of memory helping to reduce stutters is where it is the memory speed that is slowing the system down in which case some minor improvement might be made by bringing memory speed up to match the capabilities of the CPU and GPU. But then, frankly 32GB of faster memory would do that too.  

For those of you still interested in this mish mash of memory here is an explanation of Committed Memory. The Memory Manager (in the OS) receives requests from applications for a reserve of memory to be used by that application. If memory manager has enough resources for all the applications it will commit the required memory resources to them. The total amount committed is called the 'Commit Charge'.  Look at your figures in Task Manager under 'Committed' that in my case say 28.1/36.7 GB.  The first figure is the Commit Charge. However, even though that has been allocated, it doesn't mean the applications will use all of it and in my case 'In Use'  memory is only 14.5 GB.  Commit charge will always be higher than In use memory. 

The second figure (36.7 GB) is the Commit Limit.  A simple calculation (36.7 -32GB) derives my current (system dynamic)  page file size.  And so, the Commit Limit is a measure of physical RAM (32 GB) plus page file size (4.7GB) and is known as VRAM or Virtual RAM. How do these two relate? Well, the memory manager seems to work very hard at ...well managing memory, so when it allocates memory resources to applications it needs to know what percentage of the Commit Limit has been allocated to Commit Charge. As it approaches 100 percent, memory manager will increase the page file size(and therefore VRAM) to ensure there is enough. Commit Charge can be seen in Resource Manager quite clearly. The high Commit Charge percentage is no cause for concern since if more applications are added, the memory manager will simply increase the page file size to cope. (That is if you have allowed the system to set the page file dynamically).

I haven't tested this and I don't profess to understand how the memory manager works in practice but I suspect that 64GB of RAM will allow a smaller page file to be maintained. But it wont stop hard page faults which are a result of the games dynamic processes and that cause the stutters although it might reduce the number of hard page faults that occur because more old data stays in RAM perhaps?  I'm into speculation now so I'll stop there. 

 

Cheers

Terry

 

 

 

 

 

So in a nutshell, Terry, your conclusion speculative that you state it is, is that the described 'improvements' in terms of less stutter etc is largely placebo.  64Gb arrived late last evening so will try it out later today.  Here are two captures as described, these done w/ 32Gb installed:

KSFO, PMDG738, dawn, FSLTL, SLC, GSX, live weather w/ local clouds.  A grand total of 47.2% of physical ram loaded.   We can see from the VM committed we have exceeded the physical RAM capacity, and FWIW 0.8% 'page file usage' which equates to 13,312mb page file x 0.8% = 107mb worth, if indeed 'usage' refers to how many mb are being used in the page file.

The other capture at 32Gb which I will duplicate later today with 64gb is LFPG rwy 8R, PMDG 738, FSLTL SLC GSX at 12pm local time:

The elephant in those screenshots is the fact a grand total of 47% or so of those 32Gb are 'in use' and the other 53% are doing what now?   It would be nice to have full knowledge of how Windows 11 memory management truly works.  We don't even know if paging to an NVMe drive creates ANY kind of stutter at all, ever.  So in the end anecdote rules the day in this issue.

 

Edited October 12, 20241 yr by Noel

@Lord Farringdon It's been a long while since I delved into this topic, and it was on a previous version of a MS flight sim, but I think the same dynamics likely apply here--namely, that the sims all do a pretty good job of lookahead caching, where approaching scenery is pre-loaded from nonvolatile storage (SSD/HDD) into memory, so any hard faults between RAM and the page file are occurring in the background well in advance of the scenery data actually being used, and thus aren't impacting the render threads.  I think we concluded, back in the day, that the big stutter experienced when coming into range of a complex airport was mostly attributable to the massive slug of 3D object data being transferred from RAM to the GPU when the in-range "switch" gets thrown to start rendering the airport and all of the myriad 3D objects associated with it.

FWIW, I haven't seen those big "approaching the field check" stutters in MSFS for quite some time now. 

anybody have this topic going 27 pages on their bingo card?

5 hours ago, Noel said:

So in a nutshell, Terry, your conclusion speculative that you state it is, is that the described 'improvements' in terms of less stutter etc is largely placebo.  64Gb arrived late last evening so will try it out later today.  Here are two captures as described, these done w/ 32Gb installed:

KSFO, PMDG738, dawn, FSLTL, SLC, GSX, live weather w/ local clouds.  A grand total of 47.2% of physical ram loaded. 

64GB installed, 22GB going to MSFS right now and coincidentally I am using 46% of 64GB...

22 is going to MSFS, 5 is going to FSHUD, other 2 is going to ancillary apps.  I similarly never saw more than 11-14 with 32GB.  I am however on W10 with an i7 12700K so totally different architecture.  You have a far superior CPU with capabilities I don't even understand 😄

https://photos.app.goo.gl/iRbBkZEtQfP5d4yM7  

 

Edited October 12, 20241 yr by psolk

Ok 64gb EXPO DDR installed, and here is pre and post same exact scenario, ready for TO engines running:  PMDG 738 LFPG Rwy 8r broken cloud preset 12pm local time, SLC, GSX and FSLTL loaded, system managed page file size of 13,320mb, strangely enough the same w/ both 32 and 64gb:

32gb:

64Gb:  as you can see FWIW there is no page file usage and there is 2.5Gb more physical memory used on average. 

As for anecdote, by the time I disconnected from GSX pushback and started taxi at KSLC in the 738 a moment ago I had no stutters thru TO to now just at FL012.  But that's also pretty normal for a low end scenario right?  Sure.  So a bit short on experience so far but certainly hopeful. 

 

Any of you 64GB guys have the new 2024 alpha?  Do you think the 64GB is helping?  I have 32 and have some planning stutters here and there.  But it could be server stuff too since it's alpha hehe.

Finally got back to try KSLC -> KDEN in the 738.  Now nearly at cruise, this is late dusk to night flight, I have to say there was as much occasional micro stutter as w/ 32Gb.  After 38 minutes into this flight still no page file in use FWIW.  Changing views is instantaneous and perfect.  An acid test for me will be in the WT 787X which is hard on panning/view change compared to 738.  Is the consensus that 2024 will be more memory intensive?

Dumb question, I've seen a number of comments about how 64GB would especially benefit multiple screen setups.

I thought the multiple screens (I run three in 4k) would only affect GPU memory (I have a 3090).  But does it also affect RAM?

In Windows Task Manager, had anyone noticed the descriptions that crop up when you hover your mouse pointer over different segments of the informative bar chart? 

They imply that there is a use, albeit only as "standby", for larger amounts of RAM: in my case, with the amount of RAM showing as "Free" being c22Gb. On a 64Gb system, that obviously indicates that more RAM is being used than would be possible on a 32Gb system, albeit that this says nothing about whether "being used" is also "being used productively".

 

Screenshots here if interested:

https://share.icloud.com/photos/037eEARTSV6rD-xGxZDQhUreg