Running out of RAM

[Frick]

If I was shot with a gun, I would go to a doctor and get them to patch me up.

You'd stick a sex toy in the bullet hole, then complain it's caused the wound to get infected and now your family members have to care for you.

Fix the actual problem in a sane way - like, IDK, switching out the problematic BT hardware - instead of coming up with an objectively insane "solution" that not only does not fix it, but causes more problems for other people like us. "If it's stupid but it works, it's not stupid" is not always true.

You didn't have to read the thread man. OP said on the first page what the problem was. Personally I like the solution. It's the perfect blend between mad and logical.

 

[Dr. Dro]

This is a mindset I've found myself gravitating towards over the years.

Back when I was still learning and wanting to fiddle with things, I was more apt to want to "find things to fix". Disabling Windows services to lower memory and resource consumption, or finding some secret "optimization setting" to change, and that sort of thing. Maybe it's a result of our brains thinking "I changed thing, ergo it's an improvement" but I notice some people can't help but think a change is an improvement and will refuse to believe that maybe it's not, even if they can't substantiate why it's the improvement they think it is. It seems to boil down to "nothing bad happened in my experience after the change" so they refuse to budge from their position.

I hope I don't get into a bit of a rant here but it's somewhat on topic of "running out of memory". One thing in particular people still seem especially adamant about is changing page file settings. It seems better than it used to be; people seem to be learning that disabling it is bad but they're still stuck on setting a fixed, tiny size as though it's an optimization thing. I used to be one of those people myself, and until relatively recently even... until I did learn otherwise by having something bad happen. I replaced some parts in 2011 and one of them was an upgrade to 16 GB, so hey, I don't need a page file, right? So I disabled it. It "worked" for a whole six years... and then it didn't.

"What's going on?" I asked.

I posted that in 2017 thinking it was a Minecraft thing, and I was confused why I was out of RAM with almost half of my RAM still unused. It's actually easy to see what happened here in hindsight; I had reached my commit limit and it had no ability to grow because I had no page file. By setting my page file settings like that, it was effectively acting as a "please prevent me from being able to use all my memory if my commit charge ever outpaces my in use memory", and the commit charge almost always does outpace in use memory. Your commit limit is your RAM capacity plus current page file size. Minecraft is also something that can allocate much so more memory than it uses under certain circumstances, so I hit my commit limit of 16 GB well before using that much. There's a lot of other realistic and practical workflows that have much higher commit to in use balances too.

I had already been playing with PCs for a decade and a half at that point, but I never think it's too late to admit you didn't know better on something, and to reverse course. To the contrary, I'm always trying to humble myself that I have much to learn. I've set my page file back to system managed and started trying to learn more about memory management (even though I, relatively speaking, still know absolutely nothing here, but I'm at least one step closer than I was before). I wish other people would be more open to considering that maybe they don't know enough to have a formal opinion on something, but that seems to be getting rarer by the day. So seeing you say this was a bit refreshing, haha.

I guess it's because many enthusiasts and gamers tend to have far more RAM than they probably need or use, and most games alone probably don't allocate much more than they use, so these people disable or set a very small fixed page file and skirt issues. It's like buying an RTX 4090, putting it on a borderline PSU, not pushing said RTX 4090, and then concluding "this is fine". Yes, it's fine... when you don't even push it. It also means you're not in a position to be able to speak of what's enough to begin with. But these same people then recommend to others that they "should" change their page file settings, and without having a clue as to what the users' workflow and memory needs typically are! This isn't some one size fits all value setting relative to RAM capacity; it's relatively to the workload itself. People with a lot of RAM relative to their needs get away with limiting their commit limit, but that certainly doesn't make it the smarter thing to do for others.

Sorry for the mini rant.

And this is why I have always said 16 GB RAM PCs are obsolete. And now, I'm drawing on the conclusion that 32 GB is fast following. I can't run a lot of things without a PF on 32 GB anymore.

 

[DR4G00N]

I can't run a lot of things without a PF on 32 GB anymore.

Then just leave the PF on, there's no reason to ever disable it. If it doesn't need it then it won't use it, simple as that.

 

[Princess Garnet]

And this is why I have always said 16 GB RAM PCs are obsolete. And now, I'm drawing on the conclusion that 32 GB is fast following. I can't run a lot of things without a PF on 32 GB anymore.

Your statement that more RAM than this is necessary suddenly made more sense once you stated you run without a page file.

If you run with a limited commit limit (which is defined here as anything that limits it more than Windows' "system manmged" sets it as, which at its maximum is four times your installed RAM amount), you increase the situations where you may lose access to all of your RAM. And if you run with a disabled page file (which puts the commit limit at your RAM capacity), then you basically all but guarantee that you can't access all of your RAM. Why? Because memory allocation (or "commit") often outpaces in use memory. Sometimes by a lot. And it is the commit charge, not the "in use" memory, that defines your memory foot print needs. In other words, you may have to compensate for disabling the page file (or setting it to a low fixed size) by having more physical RAM. Only to still end up lacking the ability to "use" it all. So at that point you're just spending twice the necessory amount on RAM to afford you the ability to set a memory quota in Windows for no benefit. I don't seer the purpose of this, personally.

Take this as an example.

The first memory value reflects (approximately) what Windows' Task Manager shows as "in use" memory. The second value reflects the commit charge, or the first value of the two that Windows' Task Manager shows as "committed".

Now remember back that your commit charge can not exceed your commit limit. And then remember back that your commit limit equals your RAM capacity with a disabled page file. So I would be sort of close to "running out of memory" here if we pretend a scenario where I have 32 GB RAM with a disabled page file (or 24 GB RAM with a fixed page file of 8 GB, or any other combination that equals a commit limit of 32 GB). Which is silly when you realize I'm only using between ~12 GB and ~14 GB in these two examples, which is a bit less than half of this hypothetical limit.

And all because I would have manually set a setting to tell Windows "this is your memory quota, even if physical memory remains".

If you want your own examples instead of mine, take a look in Task Manager and look at your "in use" and then "committed" values. Do this every here and there, like once after freshly starting the PC, and later with a heavier workload going, and so on. Note the in use and committed values, as well as their discrepancy. You'll likely note that there will almost always be a discrepancy here where you're committing more than you're using. With a disabled page file, once that committed value reaches your RAM amount, you're are now "out of memory"... even though you have physical memory unused and available. I'd rather just keep access to all of my memory if need be, instead of limiting the PC's ability to utilize its resources at times for some reason.

 

[Shrek]

And this is why I have always said 16 GB RAM PCs are obsolete. And now, I'm drawing on the conclusion that 32 GB is fast following. I can't run a lot of things without a PF on 32 GB anymore.

Windows 11 fits comfortably in 4GB, so I find 8GB a good amount for the average user.

I have 16GB and it is sitting at 34% usage at the moment.

 

[R-T-B]

If I was shot with a gun, I would go to a doctor and get them to patch me up.

You'd stick a sex toy in the bullet hole, then complain it's caused the wound to get infected and now your family members have to care for you.

Fix the actual problem in a sane way - like, IDK, switching out the problematic BT hardware - instead of coming up with an objectively insane "solution" that not only does not fix it, but causes more problems for other people like us. "If it's stupid but it works, it's not stupid" is not always true.

This is actually a common issue to do with audio sleep. My soundbar will cut off audio if left to idle, so I use a similar utility to constantly play a silent audio track.

 

[Dr. Dro]

Your statement that more RAM than this is necessary suddenly made more sense once you stated you run without a page file.

If you run with a limited commit limit (which is defined here as anything that limits it more than Windows' "system manmged" sets it as, which at its maximum is four times your installed RAM amount), you increase the situations where you may lose access to all of your RAM. And if you run with a disabled page file (which puts the commit limit at your RAM capacity), then you basically all but guarantee that you can't access all of your RAM. Why? Because memory allocation (or "commit") often outpaces in use memory. Sometimes by a lot. And it is the commit charge, not the "in use" memory, that defines your memory foot print needs. In other words, you may have to compensate for disabling the page file (or setting it to a low fixed size) by having more physical RAM. Only to still end up lacking the ability to "use" it all. So at that point you're just spending twice the necessory amount on RAM to afford you the ability to set a memory quota in Windows for no benefit. I don't seer the purpose of this, personally.

Take this as an example.

The first memory value reflects (approximately) what Windows' Task Manager shows as "in use" memory. The second value reflects the commit charge, or the first value of the two that Windows' Task Manager shows as "committed".

Now remember back that your commit charge can not exceed your commit limit. And then remember back that your commit limit equals your RAM capacity with a disabled page file. So I would be sort of close to "running out of memory" here if we pretend a scenario where I have 32 GB RAM with a disabled page file (or 24 GB RAM with a fixed page file of 8 GB, or any other combination that equals a commit limit of 32 GB). Which is silly when you realize I'm only using between ~12 GB and ~14 GB in these two examples, which is a bit less than half of this hypothetical limit.

And all because I would have manually set a setting to tell Windows "this is your memory quota, even if physical memory remains".

If you want your own examples instead of mine, take a look in Task Manager and look at your "in use" and then "committed" values. Do this every here and there, like once after freshly starting the PC, and later with a heavier workload going, and so on. Note the in use and committed values, as well as their discrepancy. You'll likely note that there will almost always be a discrepancy here where you're committing more than you're using. With a disabled page file, once that committed value reaches your RAM amount, you're are now "out of memory"... even though you have physical memory unused and available. I'd rather just keep access to all of my memory if need be, instead of limiting the PC's ability to utilize its resources at times for some reason.

Indeed, I agree and you are correct, but the "performance hack" here was to precisely prevent a scenario in which Windows swaps memory onto non-volatile storage, which makes keeping commit limit within RAM necessary. I run a page file nowadays (sys managed, mostly out of necessity), but I 100% left it with only a minimal, compatibility-focused amount enabled (like 200 MB) it when I had my 64 GB DDR4 kit on the old 5950X build.

Windows 11 fits comfortably in 4GB, so I find 8GB a good amount for the average user.

I have 16GB and it is sitting at 34% usage at the moment.

For older computers maybe, but on a newer one, 8 GB is really tight, it really gets more responsive with more memory. Windows will compress data and pressure will generally stay very high on PCs with 16 GB of less memory, especially if you're the kind who alt tabs to browsers, media players and other apps while gaming (couldn't be me). You'll get away for a decent basic experience with 8 GB though.

Here I've got only Genshin Impact, EGS, Firefox with one tab on TPU open, Discord and foobar2000 running. My OS is super optimized as well, so it's not like it's being wasteful here, an average PC with default Windows settings would definitely feel a worse hit.

 

[Bill_Bright]

I have not seen in the last 20+ years a case where disabling the page file "improved" performance. Not one.

There are several, persistent misconceptions out there that some just refuse to accept. And that is too bad. Maybe 25 - 30 years ago, there was some basis to those misconceptions, but not today. They need to be let go.

One of those misconceptions (not mentioned above already) is based totally on bad logic. And that is the "excuse" some use to justify disabling the page file. It goes something like this. "I disabled the page file and it didn't break Windows (or I didn't see any difference) so I left it disabled." That is totally illogical.

What is logical is, "I didn't see any difference so I enabled it again." Now that makes sense.

It should also be noted that Windows does not stuff "high priority" data into the page file and keep low priority in RAM. Window is smarter than that. So even if you have 128GB of RAM, Windows may still swap "low" priority data to the page file. And guess what? That does not adversely impact performance.

 

[Dr. Dro]

I have not seen in the last 20+ years a case where disabling the page file "improved" performance. Not one.

There are several, persistent misconceptions out there that some just refuse to accept. And that is too bad. Maybe 25 - 30 years ago, there was some basis to those misconceptions, but not today. They need to be let go.

One of those misconceptions (not mentioned above already) is based totally on bad logic. And that is the "excuse" some use to justify disabling the page file. It goes something like this. "I disabled the page file and it didn't break Windows (or I didn't see any difference) so I left it disabled." That is totally illogical.

What is logical is, "I didn't see any difference so I enabled it again." Now that makes sense.

It should also be noted that Windows does not stuff "high priority" data into the page file and keep low priority in RAM. Window is smarter than that. So even if you have 128GB of RAM, Windows may still swap "low" priority data to the page file. And guess what? That does not adversely impact performance.

This was mostly at a time where storage was at a serious premium and I was caring for every last bit of performance, you know, with gaming on less than adequate hardware, seeking every last drop of fps made sense, especially at a time games wouldn't even use more than 4 GB RAM being 32-bit executables and the PC having 16 GB, this was comfy. The last rig was an exception, I truly had the memory to spare so I did not see any negatives in just keeping a small one for compatibility and ensuring that Windows used physical memory whenever possible.

I'm well aware of the drawbacks and issues with disabling the swap file, and the compatibility issues of having it disabled. Windows, by default, is designed to have one enabled, and in most cases, it should stay both on and on system managed.

 

[Bill_Bright]

and ensuring that Windows used physical memory whenever possible.

But that's one of those misconception. Ensuring Windows uses RAM whenever possible does not ensure maximum performance all the time. What that does is force Windows to close open files and save them back to disk where they will then have to re-open the files (and create a temp file) to fetch that data again. When it can simply swap that data ("data" not file) to the page file, then when needed again it can simply fetch the data without going through the extra steps of finding the file (and all its segments), opening the file and fetching the applicable data.

@DR4G00N is right,

there's no reason to ever disable it. If it doesn't need it then it won't use it, simple as that.

 

[Dr. Dro]

But that's one of those misconception. Ensuring Windows uses RAM whenever possible does not ensure maximum performance all the time. What that does is force Windows to close open files and save them back to disk where they will then have to re-open the files (and create a temp file) to fetch that data again. When it can simply swap that data ("data" not file) to the page file, then when needed again it can simply fetch the data without going through the extra steps of finding the file (and all its segments), opening the file and fetching the applicable data.

@DR4G00N is right,

Bill, I'm curious, are you a gamer? Asking this since I know you're an older guy

Windows is not exactly very optimized for a strictly-gaming scenario, you'll find that a lot of people actually use standby list cleaners to improve hitching on games. Having things entirely resident in memory has been known to help with the gaming experience once in a while. Either way, i'm not saying you or Dragoon are wrong, you're both right, and in the majority of cases, it's how it should be done. But there is some street wisdom - as far as gaming goes - to take alternate routes to memory management, and this is precisely because game developers are... unpredictable at best.

By the way, these two are pretty good, I recommend:

 

[Princess Garnet]

Indeed, I agree and you are correct, but the "performance hack" here was to precisely prevent a scenario in which Windows swaps memory onto non-volatile storage, which makes keeping commit limit within RAM necessary.

Fair point, and this might be the one beneficial thing I'd find about running without a page file.

This benefit comes while running without a page file only though, and many people seem to have shifted from "disable the page file" to "okay, run with a page file but set it to a user defined, fixed size" and you lose that benefit with the second one. The second one has no benefits like that but still adds risk so it's like... the worst of both worlds in my eyes.

But having to double down on RAM capacity (since capacity usually goes up in powers of two, although recent 24 GB DIMMs have changed this) is quite a tall ask for the benefit no page file can bring. But I'm a "live and let live" type of person so people can decide for themselves what to do. If they already have the RAM and it works, it's whatever. I just get slightly irked when people give out as blind advice to make X changes to page file.

 

[Bill_Bright]

I know you're an older guy

You calling me an Old Fart?

I no longer do serious gaming. I don't have the eyes or reflexes. But as a custom PC computer for many years, I am not new to gaming rigs.

Windows is not exactly very optimized for a strictly-gaming scenario

This is a very misleading, and extremely narrow-focused comment - and sadly, one I have run into, in various forms, countless times, here in the forums, in my shop and throughout my career in IS/IT support.

The truth is: "Windows is not exactly very optimized for a strictly [fill-in-the-blank] scenario."

If you want to optimize Windows (and your computer) for specific tasks, you need a dedicated computer, with specific components for that specific task, and it needs to be configured for that task. One computer for each task you perform. That even includes each game since this one may be CPU intensive, that one may be GPU intensive, etc.

OF COURSE Windows is a compromising OS. It has to be. Except, maybe, for PoS (point of sale, AKA: cash registers), or airport ticket sales or arrival/departure monitoring systems and similar applications, all Windows computers (and their users) perform a variety of tasks all the time.

Even gamers tend to play different games that tax systems in different ways. But those same users also generate Word documents and Excel spreadsheets, stream music and videos, edit graphics, update social media and more. And the OS must strike a decent balance regardless the task being performed.

What I am saying is, modern Windows do an excellent job at creating that balance.

What I am also saying is,

The vast majority of users are NOT experts at memory management,​

The optimal PF setting is NOT a set-and-forget setting (this is a BIG one),​

IF the user is not a true expert and does not take the time to learn and understand commit rates AND how they vary, then LEAVE THE DEFAULTS ALONE!!!!​

Now clearly, you have taken the time to understand memory management - and that's great! I applaud you for that. But you are the exception and exceptions don't make the rule. But, sadly, and what I have also seen many times is there are many folks who have taken the time to learn something new (or even had formal training, or simply catch on quick) and find that something is easy, but then, sadly, they just assume everyone can perform that task just as simply. That is NOT true. Not here and not in life in general.

I see it often with hardware. For example, there are some (even in these forums) who advise others to open up the PSU and replace the caps or jam meter probes in there - with no regard (or warnings) to the fact there may be deadly voltages inside. Now of course, advising others to disable the PF is nothing like exposing unknowledgeable users to potentially hazardous voltages, but the point is the same. Unless one really understands memory management, it is best to leave those settings to those who do.

 

[Shrek]

I see it often with hardware. For example, there are some (even in these forums) who advise others to open up the PSU and replace the caps or jam meter probes in there - with no regard (or warnings) to the fact there may be deadly voltages inside.

A most valid point; one really shouldn't work inside a power supply unless one knows what one is doing.

Notes on the Troubleshooting and Repair of Small Switchmode Power Supplies (repairfaq.org)
"Careless troubleshooting of a line powered switchmode power supply can result in severe electrical shock or electrocution. This is potentially more lethal than the high voltage section of a TV or monitor due to the high current availability. Even the charged on the main filter capacitors with the unit unplugged can kill."

 

[SL2]

Problem solved.

After using Thread.Sleep() for a long time now, I know that it doesn't make a difference after three days, the paged pool party comes anyway.

Reassigning the audiofile once a day makes the program work like I want it to. My conclusion is that this quote from another site is the explanation.

Task.Run() did most likely use more RAM, but it was never the culprit for me.

Thanks again for all the help.

Have you tried using PlayLooping() instead and just never stopping it. Might sidestep your problem as well.

I saw a really good explanation for using PlaySync instead, but I don't remember it now lol. I guess it would also have caused problems after a few days for the same reason. I might try it later tho.

The only other thing I see is that t doesn't really need to be a variable. A constant or just using a literal should be fine.

Yeah, that's a remnant from when I wanted to input sleep time as a command line option, but the Regedit entry wouldn't read it anyway. It worked when starting it from CMD. Doesn't matter anymore as I don't need it.

Another forgotten part was Task.Run(), at first I had some idea of how to use it, but in the end I just messed up and put it inside the while loop (when it should have been the other way around).

As to no rising memory usage if PlaySync is removed: are you compiling on debug or release? On release I wouldn't be surprised if the compiler just optimizes the entire loop away since it only sleeps at that point.

I've tried both, but since the large GB chewing starts after three days so I've mostly been testing it by running it as intended in Windows.

You didn't have to read the thread man. OP said on the first page what the problem was. Personally I like the solution. It's the perfect blend between mad and logical.

Tack

 

[A Computer Guy]

Thank you. As my code doesn't have any asynchronous tasks running anymore I have no use for Task.Run.

The reason for why I didn't see Task.Run as a problem was that memory usage kept climbing even with Thread.Sleep.

I see you don't post memory usage images from VS, you use Task manager instead. Is there any reason for that?

Here I'm running with Thread.Sleep, although sped up to 10 ms delays. Process memory is climbing, heap is not.
View attachment 324083
The thing is that if I remore sp.PlaySync() and only loop Thread.Sleep then memory stays flat.

This makes me believe that SoundPlayer is indeed not fit for this kind of work, and that old post might still hold true.

I would consider using a wait function (not infinite) instead with a timeout. I believe wait functions are more efficient than Sleep and take up less kernel time. I've come to find if you are using sleep inside a loop you might be doing something wrong. The trick is either the timeout from the wait function will exit your loop or you signal the wait for the exit or signal the wait for the playtime. After the loop is exited your thread should be finished and I would expect any GC related to the thread to occur. You could use a timer in your main thread to control signals and a secondary thread to manage and handle the playback. Some objects with handles in windows are thread sensitive and you should create them in the same thread that you are using them. Not sure if that exactly what might be causing your problem but it would be my first guess when you were trying to play in the task but your main thread was creating the player object.

 

[Shrek]

Question: does Windows 'page' Video RAM to RAM? if so that might explain why some people need so much RAM.

 

[A Computer Guy]

Question: does Windows 'page' Video RAM to RAM? if so that might explain why some people need so much RAM.

Shhhh. Don't give Nvidia ideas to avoid adding more VRAM.

 

[Bill_Bright]

Question: does Windows 'page' Video RAM to RAM? if so that might explain why some people need so much RAM.

I am not a programmer but I seem to remember a meeting between us (the hardware guys) and a bunch of developers at my old job where that question was asked. The answer was basically, "no" - with a big exception.

Windows just sends graphics data to the graphics processor and if needed, the GPU will swap data out to the dedicated graphics RAM.

The exception being, where is that dedicated graphics RAM? "IF" there is a graphics card installed, cards come with dedicated RAM for graphics mounted on the graphics card. And some of that may be used for caching data.

But if integrated graphics, some system RAM may be stolen... errr... shared with the graphics solution.

 

[Mussels]

Your statement that more RAM than this is necessary suddenly made more sense once you stated you run without a page file.

Oh god yes, you CANT run without a page file these days. Windows does NOT allow this, it automatically creates one if you don't have one.
All thats doing is saying "Delete the page file when it's done" resulting in constant creation and deletion instead - where a page file creates the file once and KEEPS it for future reads.

Question: does Windows 'page' Video RAM to RAM? if so that might explain why some people need so much RAM.

DX9 had to duplicate from RAM to VRAM, keeping both copies. Any changes were done in RAM, and the low VRAM cards of the era would load the parts they needed in and out on the fly (storage was too slow)

DX10 and DX11 allowed it to remove the RAM copy, making things more efficient where possible. Some things only had to load once like a UI, and would never be unloaded - so they didnt need the RAM copy.

DX12 optionally allows the GPU to access NVME storage directly, removing both the RAM and CPU overheads.


You can think of it like DX9 would load a piece of the RAM copy, process, load the next, repeat.
DX10 tried to keep things 'always needed' on the GPU out of system RAM and be less wasteful (didnt work so well)
DX11 was more about the new rendering methods, ending fullscreen exclusive as the only way to do things.
DX12 then expanded that with DXGI flip, and all these new tricks they're adding to max out the Xbox 'series' performance that barely help PC users.

 

[Bill_Bright]

Windows does NOT allow this, it automatically creates one if you don't have one.

Unless the user changes the default setting to not use one. Then it won't create a new one - which is too bad, in my opinion, because there is no good technical reason to disable the PF. No matter how much RAM is installed, performance is not improved by disabling it and instead may be degraded and may result in unstable operation.

Yes, Windows will run without a page file but there is no benefit for doing so. The best answer I have seen for this "Should I Disable the Page File if My Computer Has a Lot of RAM?" question is here (scroll down to "The Answer").

If you have one and don’t need it, there is no cost. Having a PF will not encourage more paging.

If you do need one and don’t have it, applications will fail to allocate the virtual memory they need and may result in instability, unexpected process failures and loss of data.

Are there exceptions? Of course! There are always exceptions. But again, (1) you need to really be a memory management expert to determine what the optimal setting should be and (2) it is NEVER a "set and forget" setting unless that computer system is only ever used for the exact same single task. And how many users use their computers to only ever perform one single task?

 

[ShrimpBrime]

You can easily view your Page File usage in Performance monitor. Under monitoring tools, select performance monitor again. in the box, right click and add counters. Select page file.

Now you can see your PageFile usage. Here's what it looks like, I unchecked processor time as you'll see here.

NOTE: I am not saying to turn off or turn on or extend page file. This is informational only.

 

[Bill_Bright]

But that only tells you what is happening during that computing session for those tasks you recently performed. This afternoon or tomorrow, or next week it all may change. This is the primary reason it is NOT a "set and forget" setting and a primary reason the default setting is dynamic.

 

[ShrimpBrime]

But that only tells you what is happening during that computing session for those tasks you recently performed. This afternoon or tomorrow, or next week it all may change. This is the primary reason it is NOT a "set and forget" setting and a primary reason the default setting is dynamic.

I'm not advocating anything. Just a way for those to view the page file usage. It could be really useful for those that use a lot of applications that are memory intensive to get an idea of how much physical memory can or will be pushed to the page file.

But I'm pretty sure that's a live view. You may know better than myself if that changes over time or not. This operating system is but a couple few weeks old. It gets re-installed at least every 6 months even though W11 is awesome for backwards compatibility, I keep it fresh. Because the main purpose of my PC is solely competitive benchmarking. (but that's me, not everyone else)

 

[Bill_Bright]

It is live but shows peaks too - at least for that session.