New
#11
Yeah I checked my BIOS and no memory remapping for me, so I'm stuck! Anyway, thank you all for the help, I'm guessing this is solved then!
Yeah I checked my BIOS and no memory remapping for me, so I'm stuck! Anyway, thank you all for the help, I'm guessing this is solved then!
Never mind, I found this in your board's manual:
Due to the chipset resource deployment, the system density will only be
detected up to 7+GB (not full 8GB) when each DIMM is installed with a 2GB
memory module.
First because it isn't necessary unless one does something to use up all 8gb, in which case the pc would crash.
Second because creation, growth and maintenance of the pagefile by windows means repeated unnecessary disk access.
Many of the windows processes are partially loaded in the pagefile.
By not having a pagefile, they are loaded in RAM.
Since the HDD is already the bottleneck of any system, anything you do to prevent unnescesarry disk reads/writes increases Os performance noticeably.
I have disabled pagefile on every system I installed with more than 4gb,
for more than two yrs without any downside, and with the systems being much snappier.
Note:
On my music production machine, turning off the pagefile solved audio crackling when there are many virtual instruments playing at the same time, which is a clear indication of performance gain.
When a process is not used for a few minutes, windows starts offloading it from RAM to pagefile.
With a Ram speed critical process like virtual instruments, it results in crackling sound when you play 30 or more audio/midi tracks.
Greetings.
The detailed response tells me you're digging in for some good ol' fashioned arguing, and that pleases me
It is actually necessary for some peripheral scenarios - dump creation and perfmon being the usual examples.
Creation is only done at the sysadmin's behest. "Growth and maintenance" are done as necessary, so that's a circular argument. If it wasn't necessary, they wouldn't be growing.
Processes generally have no idea what portions of their VM are resident or paged out. That's a function of memory pressure and the Memory Manager's algorithms.
No argument there. Unnecessary disk access is a bad thing.
OK, but what was the upside - why did you do it?
You're indirectly accusing the Memory Manager or the app (see below) of having a bug which caused excessive working set trimming in the ebsence of memory pressure.
That's not entirely true. The WS trimming mechanism is mostly driven by pressure, and to a lesser extent a desire to be prepared for upcoming dearth. A page can stay resident almost indefinitely in situations where plenty of RAM is available. Even if it's trimmed, it ends up on the standby and modified lists where it can be quickly soft-faulted back into the process WS without incurring the penalty of HDD access.
Oh, sure, but now you're accusing the process/app playing those virtual instruments of having a bug and potentially not calling VirtualLock() to ensure critical pages are resident at the times where disk access is to be avoided.
Greetz to you too. This is just-for-fun :)
It's 4:53 am here and I am a bit tired to say the least, but I never pass on a good discussion.
Actually I don't care about dumpfiles and monitoring on my production systems. They simply never crash.First because it isn't necessary unless one does something to use up all 8gb, in which case the pc would crash.
It is actually necessary for some peripheral scenarios - dump creation and perfmon being the usual examples.
I set my systems up through a very strict order, that I thoroughly tested in a test (second boot) environment.
I keep logs of everything I do.
Only after thorough testing I put it into my production machine.
On the test environment I have pagefile enabled for the reasons you mentioned.
Have to contradict you here.Second because creation, growth and maintenance of the pagefile by windows means repeated unnecessary disk access.
Creation is only done at the sysadmin's behest. "Growth and maintenance" are done as necessary, so that's a circular argument. If it wasn't necessary, they wouldn't be growing.
Although this is true in theory, in the real windows world it's not.
It grows regardless of how much free memory you have left.
I'll prove my case by turning it around. If it's growth was necessary, disabling it would crash my pc.
Already answered: it noticeably speeds up the OS cause unnecessary reads/writes no longer occur.OK, but what was the upside - why did you do it?
(And read my next reply.)
Regardless of which of the two is causing it, fact is that it does happen. Disabling pagefile solves it.You're indirectly accusing the Memory Manager or the app (see below) of having a bug which caused excessive working set trimming in the ebsence of memory pressure.
Why wouldn't I disable it when Music Production and cristal clear sound is my goal?
Frankly, I think it is the mem manager cause Cubase SX is not the only audio app that crackles with many audio tracks playing.
Every audio app I used has it, Adobe Audition, Reaper, Ableton and Sonar.
And not only on this machine. My previous setup had exactly the same.
Note that I am not just putting a few tracks together.
They are complete orchestrations with usually 30 up to 60 tracks of audio and midi, stacks of virtual instruments and effects.
Again, that's theory.A page can stay resident almost indefinitely in situations where plenty of RAM is available. Even if it's trimmed, it ends up on the standby and modified lists where it can be quickly soft-faulted back into the process WS without incurring the penalty of HDD access.
The OS shouldn't offload to disk when you have plenty of RAM available, but in practice with the pagefile enabled, it does.
When I just fully loaded my project and all virtual instruments are loaded in RAM, I play the recorded tracks and all runs fine.
From that moment on, in task manager I can see the virtual memory grow, same as the free physical memory, very slowly.
After a few hrs of working, the crackling starts to occur, and I can see the virtual memory grew quite a lot, and I have more free phys. mem than when I started.
When I save, close and reopen the app, all is fine again.
I can only conclude the OS is in fact offloading to disk, even though it's not supposed to.
Yes.With a Ram speed critical process like virtual instruments, it results in crackling sound when you play 30 or more audio/midi tracks.
Oh, sure, but now you're accusing the process/app playing those virtual instruments of having a bug and potentially not calling VirtualLock() to ensure critical pages are resident at the times where disk access is to be avoided.
Greetz to you again. :)
PS. I'm off to bed, but I will read your reply first thing tomorrow.
Sorry, was kinda busy. Now let's get back to technical arguing in a respectful manner :)
Consider the implications of your "real world versus theory" position. Each of us on a Win7 machine runs the exact same Memory Manager (Mm) code. In a few days, thousands or millions of others will start joining us in relying on those same Mm algorithms. Your accusation is that the Mm erroneously and heavy-handedly trimmed the working set (WS) of a process and paged out data that was being frequently touched - without memory pressure forcing it to do so. Not only that, but over the course of time you watched the situation degenerate as the WS of your active process steadily decreased to the point where you were experiencing performance issues - again, without underlying memory pressure.
That would constitute a huge bug in the Mm, a problem arguably bigger than anything commonly discussed here. If that's your "real world" experience, and you've used perfmon or other tools to verify the details, I'd really suggest you file a bug with MS. (You'd also want to file a bug with the app developer to tell them to consider using VirtualLock() for critical pages, but that's another story.)
The practice of doing away with pagefiles at a certain arbitrary amount of RAM is IMHO misguided. We don't know whether the OP is perhaps in the habit of processing a few hundred raw dSLR images in CS4, while looking at the detailed stuctural plans for a couple of skyscrapers in 64-bit AutoCAD over on another monitor. Granted, it's probable that they won't miss the pagefile, since the commit charge rarely gets that high for most home users, but then they won't gain anything much either - except to expose themselves to a slightly elevated risk of a crash due to VM depletion.
Safety first, especially on an open forum.
If I was in some way not respectful, I apologize. I wasn't aware of it.
I am not making any suggestions, merely reporting what happens.Consider the implications of your "real world versus theory" position. Each of us on a Win7 machine runs the exact same Memory Manager (Mm) code. In a few days, thousands or millions of others will start joining us in relying on those same Mm algorithms. Your accusation is that the Mm erroneously and heavy-handedly trimmed the working set (WS) of a process and paged out data that was being frequently touched - without memory pressure forcing it to do so. Not only that, but over the course of time you watched the situation degenerate as the WS of your active process steadily decreased to the point where you were experiencing performance issues - again, without underlying memory pressure.
That would constitute a huge bug in the Mm, a problem arguably bigger than anything commonly discussed here. If that's your "real world" experience, and you've used perfmon or other tools to verify the details, I'd really suggest you file a bug with MS. (You'd also want to file a bug with the app developer to tell them to consider using VirtualLock() for critical pages, but that's another story.)
I'm not an expert in the underlying technology, so I am not going to pretend I know the answer.
Yes, in the scenario you sketch it could crash the system, but like you say it is not a very likely or realistic scenario.The practice of doing away with pagefiles at a certain arbitrary amount of RAM is IMHO misguided. We don't know whether the OP is perhaps in the habit of processing a few hundred raw dSLR images in CS4, while looking at the detailed stuctural plans for a couple of skyscrapers in 64-bit AutoCAD over on another monitor. Granted, it's probable that they won't miss the pagefile, since the commit charge rarely gets that high for most home users, but then they won't gain anything much either - except to expose themselves to a slightly elevated risk of a crash due to VM depletion.
Safety first, especially on an open forum.
There are more tips and tweaks out here that when not applied wisely could endanger stability.
I think disabling the pagefile when you have 8gb of RAM is one of the least dangerous.
From your theory it seems the pagefile just sits there just in case you run out of RAM, and shouldn't have any adverse effect on the systems performance.
I can see, feel and measure that disabling it does make a difference.
How I would have to translate my findings to a technical explanation goes beyond my understanding of the matter.
You could try disabling it and see if and how it affects your system's performance.
And then maybe you could use your knowledge to find an explanation.
Greetings.
I absolutely love this part of the forum. Especially when it involves some of my favorite members.
Greetings.
How do my ears get a taste? Do Squonks email sound bites?