Location of system and cache partitions
Joe S
My mobo does not support SATA.
I have several hard drives. All my HDD's are PATA and 133 MBps
My operating system partition is on the primary master HDD.
I have placed various cache files in a separate partition on a
seperate HDD.
------
QUESTION ONE
For performance, is it better to configure the HDD containing this
Cache Partition on the mobo's *secondary* IDE socket (as either
master or slave). Or could I configure the Cache Partition as
primary slave without loss of performance?
QUESTION TWO
For performance, does it matter if I move a HDD from being master to
being slave on the same IDE cable? For example, is it ok to change
my system HDD from primary master to primary slave?
------
In all cases I would always make sure there is one of my HDDs
configured as Master on an IDE cable in order to prevent possible
problems due to an unterminated cable.
Arno Wagner
> I run XP Pro.
> My mobo does not support SATA.
> I have several hard drives. All my HDD's are PATA and 133 MBps
> My operating system partition is on the primary master HDD.
> I have placed various cache files in a separate partition on a
> seperate HDD.
> ------
> QUESTION ONE
> For performance, is it better to configure the HDD containing this
> Cache Partition on the mobo's *secondary* IDE socket (as either
> master or slave). Or could I configure the Cache Partition as
> primary slave without loss of performance?
Asuming you mean ''swap'' partitions, then they will slow down
a whole IDE channel, so keep them on the secondary channel with
no other HDD on that channel. Unless the swap usage is low, then
there will be no real effect.
> QUESTION TWO
> For performance, does it matter if I move a HDD from being master to
> being slave on the same IDE cable? For example, is it ok to change
> my system HDD from primary master to primary slave?
No impact at all. Master/Slave only impacte the numbering and which
drive issues and de-asserts the channel reset after power-up.
> ------
> In all cases I would always make sure there is one of my HDDs
> configured as Master on an IDE cable in order to prevent possible
> problems due to an unterminated cable.
Master/slave has no impact on termination.
Arno
Trimble Bracegirdle
faster than same as O/S & if that 2nd HD was on a separate IDE cable faster
still .
But I suspect there would be very little if any difference..
What WOULD (maybe) improve things a bit is how full the HD with swapfile is
.
The less full that disc the less time for Windows to find & use.
& it really helps if you go into Windows System properties & set a fixed
size for that
Swap File (about same size as your total RAM) rather than the "let Windows
manage"
default setting.
(\__/)
(='.'=)
(")_(")
Rod Speed
> You would think that putting the Swap file
Its arguable if thats what he meant by cache partitions.
> on an separate Hard Disc would be faster than same as O/S & if that 2nd HD was on a separate IDE
> cable faster still .
It makes a lot more sense to have enough physical ram so it isnt used much instead.
> But I suspect there would be very little if any difference..
> What WOULD (maybe) improve things a bit is how full the HD with swapfile is .
You wouldnt be able to pick it in a double blind trial.
> The less full that disc the less time for Windows to find & use.
That is just plain wrong.
> & it really helps if you go into Windows System properties & set a
> fixed size for that Swap File (about same size as your total RAM) rather than the "let Windows
> manage" default setting.
Nope, not if you have enough physical ram so it isnt used much.
And its silly to be having the swap file as big as the physical ram when
you have enough physical ram to see the swap file rarely used too.
Rod Speed
> I run XP Pro.
> My mobo does not support SATA.
> I have several hard drives. All my HDD's are PATA and 133 MBps
> My operating system partition is on the primary master HDD.
> I have placed various cache files in a separate partition on a
> seperate HDD.
> ------
> QUESTION ONE
> For performance, is it better to configure the HDD containing this
> Cache Partition on the mobo's *secondary* IDE socket (as either
> master or slave). Or could I configure the Cache Partition as
> primary slave without loss of performance?
Yes, you wouldnt be able to pick it in a double blind trial.
> QUESTION TWO
> For performance, does it matter if I move a HDD from being master to
> being slave on the same IDE cable? For example, is it ok to change
> my system HDD from primary master to primary slave?
Yes.
> ------
> In all cases I would always make sure there is one of my HDDs
> configured as Master on an IDE cable in order to prevent possible
> problems due to an unterminated cable.
It isnt the master/slave that matters, its that a drive is on the end drive connector.
Joe S
Rod, I guess that is what I was trying to say!
I have 80-way cables. And I set my HDD jumpers to Cable Select.
ISTR that 80-way cables are wired such if the HDDs are Cable Select
then the end drive is the master. Am sure I will be corrected if I
am wrong.
Joe S
>> For performance, is it better to configure the HDD containing this
>> Cache Partition on the mobo's *secondary* IDE socket (as either
>> master or slave). Or could I configure the Cache Partition as
>> primary slave without loss of performance?
On 10 Mar 2007, Arno Wagner <m...@privacy.net> wrote:
>
> Asuming you mean ''swap'' partitions, then they will slow down
> a whole IDE channel, so keep them on the secondary channel with
> no other HDD on that channel. Unless the swap usage is low, then
> there will be no real effect.
>
Arno, in my "Cache Partition" I have got the swap file for WinXP.
Also in there are the index files for Desktop Search and for some
similar indexing applications. There is also some thumbnails files
for my photo viewer and a few more things like that.
The partition is about 10 GB.
I keep these files in this partition partly for better performance
but also because when the indexes get rebuilt (as they do from time
to time) then the index files are not intertwined with all the other
WinXP system files and various application files. With a separate
partition I figure that the files can be more contiguous with one
another and so can the clusters for a given file.
Old Guy
How much memory do you have?
What applications do you run?
How many applications do you have active at one time?
Vic Smith
You can spend endless hours horsing around with this kind of thing
and never perceive a difference in performance.
Except as a means to learn about how swapping works, which it appears
you've done, it's probably more profitable to expend your energies
elsewhere.
--Vic
Rod Speed
Correct.
> Am sure I will be corrected if I am wrong.
No, you are correct.
Arno Wagner
>>> For performance, is it better to configure the HDD containing this
>>> Cache Partition on the mobo's *secondary* IDE socket (as either
>>> master or slave). Or could I configure the Cache Partition as
>>> primary slave without loss of performance?
> On 10 Mar 2007, Arno Wagner <m...@privacy.net> wrote:
>>
>> Asuming you mean ''swap'' partitions, then they will slow down
>> a whole IDE channel, so keep them on the secondary channel with
>> no other HDD on that channel. Unless the swap usage is low, then
>> there will be no real effect.
>>
> Arno, in my "Cache Partition" I have got the swap file for WinXP.
> Also in there are the index files for Desktop Search and for some
> similar indexing applications. There is also some thumbnails files
> for my photo viewer and a few more things like that.
> The partition is about 10 GB.
Ah, I see. Yes, calling that a "cache partition" makes sense.
> I keep these files in this partition partly for better performance
> but also because when the indexes get rebuilt (as they do from time
> to time) then the index files are not intertwined with all the other
> WinXP system files and various application files. With a separate
> partition I figure that the files can be more contiguous with one
> another and so can the clusters for a given file.
You should put the "cache disk" on an IDE channel of its own.
A CDROM/DVD-ROM on the same channel should be ok, but another
disk will result in slowdown.
Arno
zappo
Wrong if the drive the OS is on isnt being used much
as is the case with most personal desktop systems.
John Weiss
>
> QUESTION ONE
> For performance, is it better to configure the HDD containing this
> Cache Partition on the mobo's *secondary* IDE socket (as either
> master or slave). Or could I configure the Cache Partition as
> primary slave without loss of performance?
It probably doesn't matter much at all. More important is that the pagefile
is on either the boot partition or a separate HD that is of equal or better
performance than the boot HD. Putting the pagefile on a slower HD won't
help at all.
Assuming the other IDE devices aren't used full-time, I'd opt to put the HD
with the pagefile on the secondary Master.
> QUESTION TWO
> For performance, does it matter if I move a HDD from being master to
> being slave on the same IDE cable? For example, is it ok to change
> my system HDD from primary master to primary slave?
As long as the BIOS supports booting from the slave, there should be no
performance difference. However, why would you do that? What will go on
primary Master?
Rod Speed
> Joe S <j...@foldback.net> wrote...
>> QUESTION ONE
>> For performance, is it better to configure the HDD containing this
>> Cache Partition on the mobo's *secondary* IDE socket (as either
>> master or slave). Or could I configure the Cache Partition as
>> primary slave without loss of performance?
> It probably doesn't matter much at all. More important is that the
> pagefile is on either the boot partition or a separate HD that is of
> equal or better performance than the boot HD. Putting the pagefile
> on a slower HD won't help at all.
> Assuming the other IDE devices aren't used full-time, I'd opt to put the HD with the pagefile on
> the secondary Master.
Makes a lot more sense to have enough physical ram so the swap
file isnt actually used due to the lack of enough physical ram.
Old Guy
> John Weiss <jrweiss98155nospamatnospamcomcastdotnospamnet> wrote
>> Joe S <j...@foldback.net> wrote...
>
>>> QUESTION ONE
>>> For performance, is it better to configure the HDD containing this
>>> Cache Partition on the mobo's *secondary* IDE socket (as either
>>> master or slave). Or could I configure the Cache Partition as
>>> primary slave without loss of performance?
>
>> It probably doesn't matter much at all. More important is that the
>> pagefile is on either the boot partition or a separate HD that is of
>> equal or better performance than the boot HD. Putting the pagefile
>> on a slower HD won't help at all.
>
>> Assuming the other IDE devices aren't used full-time, I'd opt to put the HD with the pagefile on
>> the secondary Master.
>
> Makes a lot more sense to have enough physical ram so the swap
> file isnt actually used due to the lack of enough physical ram.
My understanding is that unless the pagefile is set to zero, there's
probably going to be some pagefile use even with a large amount of RAM.
I didn't see any reference to the operating system in use. If its
Linux, IIRC a swapfile is required. I think the recommendation is about
twice the amount of memory. And the Linux system monitor indicates that
it does get used even if there's plenty of real memory.
John Doe
> I didn't see any reference to the operating system in use. If its
> Linux, IIRC a swapfile is required. I think the recommendation is
> about twice the amount of memory. And the Linux system monitor
> indicates that it does get used even if there's plenty of real
> memory.
The more RAM, the bigger the swap file?
Apparently making an assumption about the reason you have more RAM.
Old Guy
Don't know. I've been using Linux on and off for a long time, maybe ten
years, and I think its always been that way.
Doesn't windoze default to a max size 2X of memory?
John Doe
> John Doe wrote:
>> The more RAM, the bigger the swap file?
>> Apparently making an assumption about the reason you have more
>> RAM.
>
> Don't know. I've been using Linux on and off for a long time,
> maybe ten years, and I think its always been that way.
>
> Doesn't windoze default to a max size 2X of memory?
>
My Windows XP defaults to 1536 MB with 1 GB of RAM. I don't know what
it depends on.
Rod Speed
> Rod Speed wrote
>> John Weiss <jrweiss98155nospamatnospamcomcastdotnospamnet> wrote
>>> Joe S <j...@foldback.net> wrote...
>>>> QUESTION ONE
>>>> For performance, is it better to configure the HDD containing this
>>>> Cache Partition on the mobo's *secondary* IDE socket (as either
>>>> master or slave). Or could I configure the Cache Partition as
>>>> primary slave without loss of performance?
>>> It probably doesn't matter much at all. More important is that the
>>> pagefile is on either the boot partition or a separate HD that is of
>>> equal or better performance than the boot HD. Putting the pagefile
>>> on a slower HD won't help at all.
>>> Assuming the other IDE devices aren't used full-time, I'd opt to put the HD with the pagefile on
>>> the secondary Master.
>> Makes a lot more sense to have enough physical ram so the swap
>> file isnt actually used due to the lack of enough physical ram.
> My understanding is that unless the pagefile is set to zero, there's probably going to be some
> pagefile use even with a large amount of RAM.
Yes, that's why I included the bit after my 'due to' just above.
BUT that minimal page file use only happens in the background
when there is plenty of free resources, so the location of the
page file has no impact on the performance of the system.
> I didn't see any reference to the operating system in use.
If he doesnt say, its reasonable to assume he's talking about Win.
> If its Linux, IIRC a swapfile is required. I think the recommendation is about twice the amount
> of memory.
Nope, that is completely silly. If you double the amount
of physical ram, you dont need to double the swapfile.
> And the Linux system monitor indicates that it does get used even if there's plenty of real
> memory.
Same with Win, BUT that use has no impact on
performance and so the location of it doesnt matter.
Rod Speed
Nope.
> Doesn't windoze default to a max size 2X of memory?
Nope, it defaults of a variable sized swap file that gets used as required.
Old Guy
Yeah, that's the right default. I couldn't remember is it was 150% or
200% of memory size.
Old Guy
>
>>>> Assuming the other IDE devices aren't used full-time, I'd opt to put the HD with the pagefile on
>>>> the secondary Master.
>
>>> Makes a lot more sense to have enough physical ram so the swap
>>> file isnt actually used due to the lack of enough physical ram.
>
>> My understanding is that unless the pagefile is set to zero, there's probably going to be some
>> pagefile use even with a large amount of RAM.
>
> Yes, that's why I included the bit after my 'due to' just above.
>
> BUT that minimal page file use only happens in the background
> when there is plenty of free resources, so the location of the
> page file has no impact on the performance of the system.
>
>> I didn't see any reference to the operating system in use.
>
> If he doesnt say, its reasonable to assume he's talking about Win.
>
>> If its Linux, IIRC a swapfile is required. I think the recommendation is about twice the amount
>> of memory.
>
> Nope, that is completely silly. If you double the amount
> of physical ram, you dont need to double the swapfile.
Its the way the operating system works. Not an option. So whether you
think its silly is not material.
kony
It will create the certain sized pagefile by default, larger
the more memory you have is an inaccurate rough guess that
may or may not apply to all users/uses, but that doesn't
mean it's actually using that much. It will access the
swapfile even with more than enough memory to run
everything, but it will be mostly designating allocations,
not paging out the contents of physical memory (until you
run out of available memory and nothing can be flushed to
use more main memory instead of the pagefile).
kony
<rod.sp...@gmail.com> wrote:
>BUT that minimal page file use only happens in the background
>when there is plenty of free resources,
False
>so the location of the
>page file has no impact on the performance of the system.
False again, though of course the less it's used
simultaneous to other I/O, the less it'll matter where it
is.
>
>> I didn't see any reference to the operating system in use.
>
>If he doesnt say, its reasonable to assume he's talking about Win.
>
>> If its Linux, IIRC a swapfile is required. I think the recommendation is about twice the amount
>> of memory.
>
>Nope, that is completely silly. If you double the amount
>of physical ram, you dont need to double the swapfile.
Some would even say the pagefile can then be that much
smaller, it depends a bit on whether the user is just buying
a lot of memory because doing so is in vogue, or buying a
lot of memory to run a lot of memory intensive applications.
Some people with 1GB will use it *all*, and need a lot more
pagefile space than other people with 1GB physical memory
would.
kony
wrote:
>I run XP Pro.
>My mobo does not support SATA.
>I have several hard drives. All my HDD's are PATA and 133 MBps
You're about to ask about performance, but didn't tell us
about your particular drives so there is no answer that can
be complete. Obviously all drives don't have the same
performance. This includes different brand's firmware being
better optimized for certain access patterns/uses. It may
not matter much, or it could be an additive difference as
much or more than what channel they're plugged into.
>My operating system partition is on the primary master HDD.
>I have placed various cache files in a separate partition on a
>seperate HDD.
>
>------
>
>QUESTION ONE
>For performance, is it better to configure the HDD containing this
>Cache Partition on the mobo's *secondary* IDE socket (as either
>master or slave). Or could I configure the Cache Partition as
>primary slave without loss of performance?
It would be easy to say it's better to put it on a different
PATA channel, but whether it would be a significant enough
different to realize (even in a very isolated generic test
not considering any specifics of your use) is not so
clear-cut.
You might even have other things accessing this 2nd drive
such that the cache files slow down that I/O more than they
would the OS /app drive, particularly considering that once
you have the OS loaded, the app loaded, and of course
sufficient physical memory to hold it, what remains that is
of sinificant I/O are the files that app is working with.
They too should be elsewhere besides on same drive as OS and
the app, but you can only divide up I/O so many different
ways between different drives and channels.
It is far more significant to put the simultaneous I/O on a
different drive than on a different controller channel. If
you are still lacking performance enough that you hope for
more from channel positioning, it's probably time to just
buy faster drives first.
>
>
>QUESTION TWO
>For performance, does it matter if I move a HDD from being master to
>being slave on the same IDE cable?
no
> For example, is it ok to change
>my system HDD from primary master to primary slave?
So long as the system will boot from it (which any system in
the past half-decade or more should be able to do), though
Windows expects it to be on the primary master until you
change the boot.ini file.
Rod Speed
No it isnt.
> Not an option. So whether you think its silly is not material.
Neither is your silly claim that it actually uses twice the size of
the physical ram, regardless of how much physical ram there is.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> BUT that minimal page file use only happens in the
>> background when there is plenty of free resources,
> False
Easy to claim. Hell of a lot harder to actually substantiate that claim.
>> so the location of the page file has no
>> impact on the performance of the system.
> False again,
Easy to claim. Hell of a lot harder to actually substantiate that claim.
> though of course the less it's used simultaneous
> to other I/O, the less it'll matter where it is.
There is no impact on performance when you have enough physical
ram so that there is no need to swap out physical ram to the swap file.
The only reason Win does that is in case there is a need for more physical
ram than is installed, and that is done with free resources, because its
impossible to predict whether that will ever actually be needed.
>>> I didn't see any reference to the operating system in use.
>> If he doesnt say, its reasonable to assume he's talking about Win.
>>> If its Linux, IIRC a swapfile is required. I think the
>>> recommendation is about twice the amount of memory.
>> Nope, that is completely silly. If you double the amount
>> of physical ram, you dont need to double the swapfile.
> Some would even say the pagefile can then be that much smaller,
> it depends a bit on whether the user is just buying a lot of memory
> because doing so is in vogue, or buying a lot of memory to run a lot
> of memory intensive applications. Some people with 1GB will use it
> *all*, and need a lot more pagefile space than other people with
> 1GB physical memory would.
Irrelevant to what the OS can choose to do IN CASE
there is a need for more physical ram than is installed.
Rod Speed
> Joe S <j...@foldback.net> wrote
>> I run XP Pro.
>> My mobo does not support SATA.
>> I have several hard drives. All my HDD's are PATA and 133 MBps
> You're about to ask about performance, but didn't tell us about
> your particular drives so there is no answer that can be complete.
Wrong, as always. The answer can obviously
cover all the possibilitys and so be complete.
> Obviously all drives don't have the same performance.
> This includes different brand's firmware being better
> optimized for certain access patterns/uses. It may
> not matter much, or it could be an additive difference
> as much or more than what channel they're plugged into.
Hardly ever in practice.
>> ------
> no
Wrong, as always.
Joe S
I am the OP. Way back in the original post it says I run XP.
Old Guy
The default swapfile is configured during o/s installation. I didn't
say it was all used, just there. Its not for me to justify or you to
criticize, its just the way it is. Some of the swapfile will get used
even in systems with more real memory than the system could use. Who
cares?
If windoze is installed on a system with 4 gb of memory, why do they
create a default swapfilf of 2 gig? That's silly.
Joe S
>>
>>> I didn't see any reference to the operating system in use. If
>>> its Linux, IIRC a swapfile is required. I think the
>>> recommendation is about twice the amount of memory. And the
>>> Linux system monitor indicates that it does get used even if
>>> there's plenty of real memory.
> John Doe wrote:
>>
>> The more RAM, the bigger the swap file?
>> Apparently making an assumption about the reason you have more
>> RAM.
On 11 Mar 2007, Old Guy <olde...@oldestguy.com> wrote:
>
> Don't know. I've been using Linux on and off for a long time,
> maybe ten years, and I think its always been that way.
>
> Doesn't windoze default to a max size 2X of memory?
See "Virtual Memory in Windows XP" http://aumha.org/win5/a/xpvm.htm
A snippet (see the link for full context) says:
"For any given workload, the total need for virtual addresses will
not depend on the size of RAM alone. It will be met by the sum of RAM
and the page file. Therefore in a machine with small RAM, the extra
amount represented by page file will need to be larger, not smaller,
than that needed in a machine with big RAM." etc etc etc.
Joe S
AFAICT Rod is right.
John Weiss
>>
>>> Assuming the other IDE devices aren't used full-time, I'd opt to put the
>>> HD with the pagefile on the secondary Master.
>>
>> Makes a lot more sense to have enough physical ram so the swap
>> file isnt actually used due to the lack of enough physical ram.
>
> My understanding is that unless the pagefile is set to zero, there's
> probably going to be some pagefile use even with a large amount of RAM.
That is true. As long as there is a pagefile existent, Windoze will make
some use of it. Some apps will do the same.
For example, I have 2 GB total RAM with 1.2 GB available, but there is still
almost 600 MB of the 2 GB pagefile in use.
I reduced the pagefile to 1 GB, but there was no significant change in its
usage.
So, contrary to rodless' implication, pagefile use cannot be eliminated
simply by adding RAM.
> I didn't see any reference to the operating system in use.
OP stated WinXP at the beginning.
John Weiss
>>
>> Doesn't windoze default to a max size 2X of memory?
>
> My Windows XP defaults to 1536 MB with 1 GB of RAM. I don't know what
> it depends on.
Note, however, that the default is NOT a constant-size pagefile. You may
gain a bit in boot time and a bit in performance if you set the min and max
pagefile size to the same value so it is not dynamically resizing. If the
file starts out as a contiguous file, it will also prevent pagefile
fragmentation, which is another minor performance issue.
For minimum RAM configurations, the 150% value is appropriate. However, as
you increase RAM, you do not necessarily have to keep the pagefile in that
proportion. For example, when I increased my laptop RAM from 512 MB to 1.5
GB, I reduced the pagefile from 768 to 512 MB. Total available memory is
still more than original, but much more of it is physical RAM. The
increased "snap" of the system is apparent.
John Weiss
>
> Easy to claim. Hell of a lot harder to actually substantiate that claim.
You should know, since you're the king of unsubstantiated and
unsubstantiatable claims around here...
John Doe
> "John Doe" <jd...@usenetlove.invalid> wrote...
>>>
>>> Doesn't windoze default to a max size 2X of memory?
>>
>> My Windows XP defaults to 1536 MB with 1 GB of RAM. I don't know
>> what it depends on.
>
> Note, however, that the default is NOT a constant-size pagefile.
Mine is.
I thought that odd, but the default is fixed.
Rod Speed
>> No it isnt.
And that is to let Win manage the page file when the OS is Win.
> I didn't say it was all used, just there.
You made that stupid claim about twice the physical ram being 'recommended'
It isnt, particularly when there is enough physical ram so that
the page file isnt used because of a lack of physical ram.
> Its not for me to justify or you to criticize, its just the way it is.
Your silly claim about twice the physical ram is nothing like the way it is.
> Some of the swapfile will get used even in systems with more real memory than the system could
> use. Who cares?
Irrelevant to your silly claim about twice the physical ram.
> If windoze is installed on a system with 4 gb of memory, why do they create a default swapfilf of
> 2 gig?
They dont.
> That's silly.
And its clearly not twice the physical ram either.
Rod Speed
I never ever implied anything of the sort.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> Easy to claim. Hell of a lot harder to actually substantiate that claim.
> You should know, since you're the king of unsubstantiated and unsubstantiatable claims around
> here...
How odd that we aint seen even a single substantiation from you, ever.
Robert Heiling
>
> > The default swapfile is configured during o/s installation.
>
> And that is to let Win manage the page file when the OS is Win.
>
> > I didn't say it was all used, just there.
>
> You made that stupid claim about twice the physical ram being 'recommended'
>
> It isnt, particularly when there is enough physical ram so that
> the page file isnt used because of a lack of physical ram.
Are you certain that won't be paged, even though a copy remains in ram?
> > Its not for me to justify or you to criticize, its just the way it is.
>
> Your silly claim about twice the physical ram is nothing like the way it is.
What puzzles me most about this whole discussion is the lack of mention of the
demand that the running tasks place on memory requirements.
> > Some of the swapfile will get used even in systems with more real memory than the system could
> > use. Who cares?
>
> Irrelevant to your silly claim about twice the physical ram.
Yes. The size of physical ram is less important than the total memory required
by the running tasks for program code and data space. That figure plays the most
important role in the size of the pagefile and its role has not even been
mentioned. That is obviously going to vary depending upon what use is made of
the systems and which, and how many, applications are being run concurrently.
Bob
John Weiss
>
> How odd that we aint seen even a single substantiation from you, ever.
The only "odd" thing is your "we". Though you may be blind to reality, that
is not the case with most posters here.
Rod Speed
>>> The default swapfile is configured during o/s installation.
>> And that is to let Win manage the page file when the OS is Win.
>>> I didn't say it was all used, just there.
>> You made that stupid claim about twice the physical ram being 'recommended'
>> It isnt, particularly when there is enough physical ram so that
>> the page file isnt used because of a lack of physical ram.
> Are you certain that won't be paged, even though a copy remains in ram?
I in fact said that Win does in fact put stuff in the page file even when
there is plenty of free physical ram, AND leaves it in physical ram,
and it does that in the background, essentially because its never going
to be possible to predict what some app will want physical ram wise
or what the user will choose to run, so you might as well put the best
candidates for the page file in the page file ahead of time, in the
background, so you can just mark that stuff as no longer in physical
ram if there become a need for more physical ram than is installed.
That is done essentially instantly when its already in the page file.
>>> Its not for me to justify or you to criticize, its just the way it is.
>> Your silly claim about twice the physical ram is nothing like the way it is.
> What puzzles me most about this whole discussion is the lack of mention
> of the demand that the running tasks place on memory requirements.
What was being discussed was what Win does page file use wise WHEN
THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
Only the user can ever know that, the OS can never be sure what some
app will request, or what the user may choose to run for the first time etc.
So it makes sense to put some stuff in the page file in the background,
just in case more physical ram is needed than is actually installed.
>>> Some of the swapfile will get used even in systems with
>>> more real memory than the system could use. Who cares?
>> Irrelevant to your silly claim about twice the physical ram.
> Yes. The size of physical ram is less important than the total memory
> required by the running tasks for program code and data space. That
> figure plays the most important role in the size of the pagefile and
> its role has not even been mentioned.
Because what was being discussed was what Win does page file use wise
WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
> That is obviously going to vary depending upon what use is made of the
> systems and which, and how many, applications are being run concurrently.
Duh. Pity that was assumed when we were discussing the use of the page file
WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> How odd that we aint seen even a single substantiation from you, ever.
> The only "odd" thing is your "we".
We'll see...
> Though you may be blind to reality, that is not the case with most posters here.
Never ever could bullshit its way out of a wet paper bag.
Have fun listing a single example of you ever substantiating a damned thing, ever.
Robert Heiling
>
> Robert Heiling <rob...@comcast.net> wrote
> > Rod Speed wrote
> >> Old Guy <olde...@oldestguy.com> wrote
>
> >>> The default swapfile is configured during o/s installation.
>
> >> And that is to let Win manage the page file when the OS is Win.
>
> >>> I didn't say it was all used, just there.
>
> >> You made that stupid claim about twice the physical ram being 'recommended'
>
> >> It isnt, particularly when there is enough physical ram so that
> >> the page file isnt used because of a lack of physical ram.
>
> > Are you certain that won't be paged, even though a copy remains in ram?
>
> I in fact said that Win does in fact put stuff in the page file even when
> there is plenty of free physical ram, AND leaves it in physical ram,
> and it does that in the background, essentially because its never going
> to be possible to predict what some app will want physical ram wise
> or what the user will choose to run, so you might as well put the best
> candidates for the page file in the page file ahead of time, in the
> background, so you can just mark that stuff as no longer in physical
> ram if there become a need for more physical ram than is installed.
> That is done essentially instantly when its already in the page file.
Right. What you state there is my understanding also. Win pages everything that
is pageable. I thought I was in agreement with you all along.
> >>> Its not for me to justify or you to criticize, its just the way it is.
>
> >> Your silly claim about twice the physical ram is nothing like the way it is.
>
> > What puzzles me most about this whole discussion is the lack of mention
> > of the demand that the running tasks place on memory requirements.
>
> What was being discussed was what Win does page file use wise WHEN
> THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
If you say so. That's not readily apparent from the rhetoric.
> Only the user can ever know that, the OS can never be sure what some
> app will request, or what the user may choose to run for the first time etc.
>
> So it makes sense to put some stuff in the page file in the background,
> just in case more physical ram is needed than is actually installed.
>
> >>> Some of the swapfile will get used even in systems with
> >>> more real memory than the system could use. Who cares?
Ok, It got mentioned there. Is that what you meant by:
"What was being discussed was what Win does page file use wise WHEN
THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE."?
> >> Irrelevant to your silly claim about twice the physical ram.
>
> > Yes. The size of physical ram is less important than the total memory
> > required by the running tasks for program code and data space. That
> > figure plays the most important role in the size of the pagefile and
> > its role has not even been mentioned.
>
> Because what was being discussed was what Win does page file use wise
> WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
That was a couple of messages ago that was said. There was also discussion of
which HD to put it on and which IDE etc. I didn't realize the discussion had
narrowed like that.
> > That is obviously going to vary depending upon what use is made of the
> > systems and which, and how many, applications are being run concurrently.
>
> Duh. Pity that was assumed when we were discussing the use of the page file
> WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
Whatever! The point is that the size of ram is irrelevant. You need a pagefile
that is large enough to hold the maximum code & data that your applications
requires.
Bob
Rod Speed
> Rod Speed wrote
>> Robert Heiling <rob...@comcast.net> wrote
>>> Rod Speed wrote
>>>> Old Guy <olde...@oldestguy.com> wrote
>>>>> The default swapfile is configured during o/s installation.
>>>> And that is to let Win manage the page file when the OS is Win.
>>>>> I didn't say it was all used, just there.
>>>> You made that stupid claim about twice the physical ram being 'recommended'
>>>> It isnt, particularly when there is enough physical ram so that
>>>> the page file isnt used because of a lack of physical ram.
>>> Are you certain that won't be paged, even though a copy remains in ram?
>> I in fact said that Win does in fact put stuff in the page file even when
>> there is plenty of free physical ram, AND leaves it in physical ram,
>> and it does that in the background, essentially because its never going
>> to be possible to predict what some app will want physical ram wise
>> or what the user will choose to run, so you might as well put the
>> best candidates for the page file in the page file ahead of time, in
>> the background, so you can just mark that stuff as no longer in physical
>> ram if there become a need for more physical ram than is installed.
>> That is done essentially instantly when its already in the page file.
> Right. What you state there is my understanding also.
> Win pages everything that is pageable.
Thats overstating it, the page file doesnt get big enough
for everything thats in physical ram in that situation.
> I thought I was in agreement with you all along.
>>>>> Its not for me to justify or you to criticize, its just the way it is.
>>>> Your silly claim about twice the physical ram is nothing like the way it is.
>>> What puzzles me most about this whole discussion is the lack of mention
>>> of the demand that the running tasks place on memory requirements.
>> What was being discussed was what Win does page file use wise WHEN
>> THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
> If you say so. That's not readily apparent from the rhetoric.
Its more that it got rather lost in the selective quoting.
>> Only the user can ever know that, the OS can never be sure what some
>> app will request, or what the user may choose to run for the first time etc.
>> So it makes sense to put some stuff in the page file in the background,
>> just in case more physical ram is needed than is actually installed.
>>>>> Some of the swapfile will get used even in systems with
>>>>> more real memory than the system could use. Who cares?
> Ok, It got mentioned there. Is that what you meant by:
> "What was being discussed was what Win does page file use wise WHEN
> THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE."?
More my original,
>>>>>> Makes a lot more sense to have enough physical ram so the swap
>>>>>> file isnt actually used due to the lack of enough physical ram.
With 20/20 hindsight, thats said a bit cryptically with the bit after the 'due to'
I should have made it clearer that I meant that Win still uses the page file
in that situation, but I did say elsewhere that since it only uses it in the
background in that situation, the location of it makes no difference,
because that only happens in the background in that situation.
>>>> Irrelevant to your silly claim about twice the physical ram.
>>> Yes. The size of physical ram is less important than the total
>>> memory required by the running tasks for program code and
>>> data space. That figure plays the most important role in the
>>> size of the pagefile and its role has not even been mentioned.
>> Because what was being discussed was what Win does page file use wise
>> WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
> That was a couple of messages ago that was said.
Yes, and it got dropped from the selective quoting.
> There was also discussion of which HD to put it on and which IDE etc.
Yes, but that use by Win of the swap file in that situation where there
is still plenty of free physical ram is relevant to the location of the page
file, because in THAT situation the location of the page file doesnt matter.
> I didn't realize the discussion had narrowed like that.
It didnt.
>>> That is obviously going to vary depending upon what use is made of the
>>> systems and which, and how many, applications are being run concurrently.
>> Duh. Pity that was assumed when we were discussing the use of the page file
>> WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.
> Whatever! The point is that the size of ram is irrelevant.
No it isnt when the location of the page file is being discussed. If you dont
have enough physical ram, the page file will be used when other stuff is
going on, and THEN the location of the page file CAN make a difference.
> You need a pagefile that is large enough to hold the
> maximum code & data that your applications requires.
Thats always been obvious. What was being discussed was WHEN
THE LOCATION OF THE PAGE FILE CAN MAKE A DIFFERENCE.
Robert Heiling
>
> > You need a pagefile that is large enough to hold the
> > maximum code & data that your applications requires.
>
> Thats always been obvious. What was being discussed was WHEN
> THE LOCATION OF THE PAGE FILE CAN MAKE A DIFFERENCE.
And summarizing, the answer given appears to be that the location of the
pagefile can make a difference if the pagefile gets used. Duh! Why didn't I
think of that?
Bob
Rod Speed
>>> You need a pagefile that is large enough to hold the
>>> maximum code & data that your applications requires.
>> Thats always been obvious. What was being discussed was WHEN
>> THE LOCATION OF THE PAGE FILE CAN MAKE A DIFFERENCE.
> And summarizing, the answer given appears to be that the location
> of the pagefile can make a difference if the pagefile gets used.
No it doesnt. WHEN THE PAGE FILE IS ONLY USED BY WIN WHEN
THERE IS PLENTY OF FREE PHYSICAL RAM, AND THAT IS DONE
IN THE BACKGROUND, SO THAT STUFF DOESNT NEED TO BE
MOVED TO THE PAGE FILE WHEN THERE ISNT ENOUGH PHYSICAL
RAM, THE LOCATION OF THE PAGE FILE *THEN* DOESNT MATTER.
> Duh! Why didn't I think of that?
Even you cant actually be THAT thick.
John Doe
lol
"The road is long, with many a winding turn... la la la"
kony
wrote:
>>> Old Guy <olde...@oldestguy.com> wrote:
That is true if we consider the jobs the system is running
to be a fixed variable. We often don't - often if a system
isn't running huge jobs, there is no money (wasted?) put
into massive amounts of memory for it, so when a system is
configured per job and has a lot of memory, that is
typically an indicatio of the potential to need more virtual
memory space too (but even this will vary depending on exact
jobs and the way the app decides how large a space to
reserve for it's use).
kony
Seems like even if someone provides substantiation, they
just get some clown-wet-bag-something-or-other reply so it's
a wasted effort.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> John Weiss <jrweiss98155nospamatnospamcomcastdotnospamnet> wrote
>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>> Easy to claim. Hell of a lot harder to actually substantiate that claim.
>>> You should know, since you're the king of unsubstantiated
>>> and unsubstantiatable claims around here...
>> How odd that we aint seen even a single substantiation from you, ever.
> Seems like even if someone provides substantiation,
You never ever have, you pathetic excuse for a lying bullshit artist.
kony
wrote:
>I am the OP.
Can you prove that beyond a shadow of a doubt? Now that
Rod's involved we can't trust much of anything. ;-)
>Way back in the original post it says I run XP.
The generic answer is to put your pagefile on the most used
partition of the least used, *modern performance level*,
drive. Put that drive on the PATA controller channel that
is least used simultaneous to any other I/O that might be
occuring while the system is actively making use (reading or
writing) of virtual memory.
kony
<rod.sp...@gmail.com> wrote:
>kony <sp...@spam.com> wrote
>> Joe S <j...@foldback.net> wrote
>
>>> I run XP Pro.
>>> My mobo does not support SATA.
>>> I have several hard drives. All my HDD's are PATA and 133 MBps
>
>> You're about to ask about performance, but didn't tell us about
>> your particular drives so there is no answer that can be complete.
>
>Wrong, as always. The answer can obviously
>cover all the possibilitys and so be complete.
Nope, trying to divide access between drives and channels is
offset by the performance difference between all drives.
You can get better performance from two new 400GB drives on
the same channel than one 400GB on channel 0 and one 40GB on
channel 2, for example.
>
>> Obviously all drives don't have the same performance.
>> This includes different brand's firmware being better
>> optimized for certain access patterns/uses. It may
>> not matter much, or it could be an additive difference
>> as much or more than what channel they're plugged into.
>
>Hardly ever in practice.
Almost always in practice. Seldom does one buy a boatload
of identical PATA drives then later reconfigure them all on
the same system, unless that system is just a filestore
instead of actively used XP PC.
Rod Speed
>>>> Old Guy <olde...@oldestguy.com> wrote
>>>>> I didn't see any reference to the operating system in use.
>>>>> If its Linux, IIRC a swapfile is required. I think the
>>>>> recommendation is about twice the amount of memory.
>>>>> And the Linux system monitor indicates that it does get
>>>>> used even if there's plenty of real memory.
>>>> The more RAM, the bigger the swap file?
>>>> Apparently making an assumption about the reason you have more RAM.
>>> Don't know. I've been using Linux on and off for a long time,
>>> maybe ten years, and I think its always been that way.
>>> Doesn't windoze default to a max size 2X of memory?
>> See "Virtual Memory in Windows XP" http://aumha.org/win5/a/xpvm.htm
>> A snippet (see the link for full context) says:
>> "For any given workload, the total need for virtual addresses will not
>> depend on the size of RAM alone. It will be met by the sum of RAM
>> and the page file. Therefore in a machine with small RAM, the extra
>> amount represented by page file will need to be larger, not smaller,
>> than that needed in a machine with big RAM." etc etc etc.
> That is true if we consider the jobs the system is running to be a fixed variable.
Its true even if we dont.
> We often don't - often if a system isn't running huge jobs, there is no money
> (wasted?) put into massive amounts of memory for it, so when a system is
> configured per job and has a lot of memory, that is typically an indicatio of
> the potential to need more virtual memory space too (but even this will vary
> depending on exact jobs and the way the app decides how large a space to
> reserve for it's use).
Meaningless waffle and irrelevant to what is being discussed, the location
of the page file and the situations where the LOCATION matters.
Rod Speed
> Joe S <j...@foldback.net> wrote
>> I am the OP.
> Can you prove that beyond a shadow of a doubt?
> Now that Rod's involved we can't trust much of anything. ;-)
Never ever could bullshit its way out of a wet paper bag.
>> Way back in the original post it says I run XP.
> The generic answer is to put your pagefile on the most used
> partition of the least used, *modern performance level*,
> drive. Put that drive on the PATA controller channel that
> is least used simultaneous to any other I/O that might be
> occuring while the system is actively making use (reading or
> writing) of virtual memory.
The real generic answer is to ensure you have enough physical ram
so the page file isnt used because there isnt enough physical ram.
THAT provides a VASTLY better performance config.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> kony <sp...@spam.com> wrote
>>> Joe S <j...@foldback.net> wrote
>>>> I run XP Pro.
>>>> My mobo does not support SATA.
>>>> I have several hard drives. All my HDD's are PATA and 133 MBps
>>> You're about to ask about performance, but didn't tell us about
>>> your particular drives so there is no answer that can be complete.
>> Wrong, as always. The answer can obviously
>> cover all the possibilitys and so be complete.
> Nope,
Yep.
> trying to divide access between drives and channels is
> offset by the performance difference between all drives.
And that can be spelt out in the complete answer, you pathetic excuse for a bullshit artist.
> You can get better performance from two new 400GB drives on the same
> channel than one 400GB on channel 0 and one 40GB on channel 2, for example.
And that can be spelt out in the complete answer, you pathetic excuse for a bullshit artist.
>>> Obviously all drives don't have the same performance.
>>> This includes different brand's firmware being better
>>> optimized for certain access patterns/uses. It may
>>> not matter much, or it could be an additive difference
>>> as much or more than what channel they're plugged into.
>> Hardly ever in practice.
> Almost always in practice.
We'll see...
> Seldom does one buy a boatload of identical PATA drives
> then later reconfigure them all on the same system, unless
> that system is just a filestore instead of actively used XP PC.
Irrelevant to the last bit of your mindless waffle that I said hardly ever happens in practice.
kony
<rod.sp...@gmail.com> wrote:
>> That is true if we consider the jobs the system is running to be a fixed variable.
>
>Its true even if we dont.
>
Nope, otherwise one expects a system that runs larger jobs
to have been properly equipped for these tasks. Since size
of job obviously effects amount of real and virtual memory
used, it would have to be a fixed variable or else "it
depends" on that variable.
kony
Duh? It would seem obvious enough to have ample system
memory, but that won't keep the system from accessing the
pagefile either to some extent so long as it's enabled at
all, so there is still a minor penalty.
Yes we can see the pagefile is not only accessed during idle
time. Have you ever bothered to look for any system
monitoring tools that monitor this? I'm not going to do
your work for you.
kony
<rod.sp...@gmail.com> wrote:
Rod is trolling
>> Nope,
>
>Yep.
>
Ok then
Rod Speed
>>> Joe S <j...@foldback.net> wrote
>>>> Old Guy <olde...@oldestguy.com> wrote
>>>>> John Doe wrote
>>>>>> Old Guy <olde...@oldestguy.com> wrote
>>>>>>> I didn't see any reference to the operating system in use.
>>>>>>> If its Linux, IIRC a swapfile is required. I think the
>>>>>>> recommendation is about twice the amount of memory.
>>>>>>> And the Linux system monitor indicates that it does get
>>>>>>> used even if there's plenty of real memory.
>>>>>> The more RAM, the bigger the swap file?
>>>>>> Apparently making an assumption about the reason you have more RAM.
>>>>> Don't know. I've been using Linux on and off for a long time,
>>>>> maybe ten years, and I think its always been that way.
>>>>> Doesn't windoze default to a max size 2X of memory?
>>>> See "Virtual Memory in Windows XP" http://aumha.org/win5/a/xpvm.htm
>>>> A snippet (see the link for full context) says:
>>>> "For any given workload, the total need for virtual addresses will not
>>>> depend on the size of RAM alone. It will be met by the sum of RAM
>>>> and the page file. Therefore in a machine with small RAM, the extra
>>>> amount represented by page file will need to be larger, not smaller,
>>>> than that needed in a machine with big RAM." etc etc etc.
>>> That is true if we consider the jobs the system is running to be a fixed variable.
>> Its true even if we dont.
> Nope,
Yep.
> otherwise one expects a system that runs larger jobs
> to have been properly equipped for these tasks.
The whole point of a page file is to handle the situation where
there is a need for more physical ram than the system actually has.
And that doesnt necessarily impose much of a performance penalty
either, most obviously when the system keeps a number of larger
apps loaded for convenient switching between them, but where
they arent all running and consuming cpu resources all the time.
> Since size of job obviously effects amount of real and virtual memory used,
> it would have to be a fixed variable or else "it depends" on that variable.
Never ever could bullshit its way out of a wet paper bag.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> kony <sp...@spam.com> wrote
>>> Joe S <j...@foldback.net> wrote
>>>> I am the OP.
>>> Can you prove that beyond a shadow of a doubt?
>>> Now that Rod's involved we can't trust much of anything. ;-)
>> Never ever could bullshit its way out of a wet paper bag.
>>>> Way back in the original post it says I run XP.
>>> The generic answer is to put your pagefile on the most used
>>> partition of the least used, *modern performance level*,
>>> drive. Put that drive on the PATA controller channel that
>>> is least used simultaneous to any other I/O that might be
>>> occuring while the system is actively making use (reading or
>>> writing) of virtual memory.
>> The real generic answer is to ensure you have enough physical ram
>> so the page file isnt used because there isnt enough physical ram.
>> THAT provides a VASTLY better performance config.
> Duh? It would seem obvious enough to have ample system memory,
And that is obviously the generic answer that satisfys
all configs that the OP didnt spell out in detail.
> but that won't keep the system from accessing the pagefile
> either to some extent so long as it's enabled at all,
No one ever said it did.
> so there is still a minor penalty.
NOT when what pagefile activity that does still occur ONLY
happens in the background when nothing else is needing those
resources, in case there does turn out to be a need to more
physical ram than the system has installed, even when there
is still plenty of physical ram still unused.
> Yes we can see the pagefile is not only accessed during idle time.
No we cant. I told you how to prove that and you never did bother to check it that way.
> Have you ever bothered to look for any
> system monitoring tools that monitor this?
Corse I have.
> I'm not going to do your work for you.
Never ever could bullshit its way out of a wet paper bag.
You've never produced a shred of substantiation for your stupid
pig ignorant claim that Win uses the page file when the resources
are being used when there is plenty of free physical ram.
Rod Speed
Thanks for running up the white flag, child.
John Weiss
>
> The whole point of a page file is to handle the situation where
> there is a need for more physical ram than the system actually has.
That may have been the original idea, but actual implementation has been
corrupted way beyond that simplicity. As has been pointed out by several
people here already, Windows uses the pagefile even when there is plenty of
physical RAM for all current needs.
John Weiss
>
>> Yes we can see the pagefile is not only accessed during idle time.
>
> No we cant. I told you how to prove that and you never did bother to check
> it that way.
>> Have you ever bothered to look for any
>> system monitoring tools that monitor this?
>
> Corse I have.
Then you haven't looked very hard...
> You've never produced a shred of substantiation for your stupid
> pig ignorant claim that Win uses the page file when the resources
> are being used when there is plenty of free physical ram.
I am watching the Task Manager Performance page and can see the PF usage
change dynamically while working on something else. I can also watch the
Processes page and monitor what process is accessing the PF.
All this is happening with 2 GB RAM installed and over 1.2 GB free, and over
500 MB of pagefile in use!
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> The whole point of a page file is to handle the situation where
>> there is a need for more physical ram than the system actually has.
> That may have been the original idea,
Its STILL the whole point of a page file.
> but actual implementation has been corrupted way beyond that simplicity.
Nope, ALL that has changed is the realisation that it makes sense to
put what would be moved into the page file when there isnt enough
physical ram, into the page file ahead of time, using idle resources,
so that if there is a need for more physical ram than there is installed,
all that needs to happen is to reuse the physical ram thats been written
to the page file. You dont have to wait while that stuff is written to the
page file before the physical ram can be reused, its already in the page file.
> As has been pointed out by several people here already, Windows uses the pagefile even when there
> is plenty of physical RAM for all current needs.
And by me too. What is being missed completely by the pig ignorant is that
Windows does that BEFORE there is no more physical ram left, IN CASE
there is a need for more physical ram than is installed, instead of waiting
till there is no physical ram free before doing that. When that is done using
idle resources, there is NO downside with doing that and in fact it speeds
things up because you dont need to write that stuff to the page file WHEN
there is no more physical ram free, with the delay that is inevitable if you
leave writing to the page file till the last minute.
Its a VERY simple concept and fools like you cant even manage to grasp it.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>>> Yes we can see the pagefile is not only accessed during idle time.
>> No we cant. I told you how to prove that and you never did bother to check it that way.
>>> Have you ever bothered to look for any
>>> system monitoring tools that monitor this?
>> Corse I have.
> Then you haven't looked very hard...
Easy to claim.
Pity you havent even managed to grasp the reason Windows
uses the page file when there is still plenty of free physical ram.
>> You've never produced a shred of substantiation for your stupid
>> pig ignorant claim that Win uses the page file when the resources
>> are being used when there is plenty of free physical ram.
> I am watching the Task Manager Performance page and can see the PF usage change dynamically while
> working on something else.
Doesnt prove a damned thing about whether that is happening with free resources.
> I can also watch the Processes page and monitor what process is accessing the PF.
Doesnt prove a damned thing about whether that is happening with free resources.
> All this is happening with 2 GB RAM installed and over 1.2 GB free, and over 500 MB of pagefile in
> use!
Doesnt prove a damned thing about whether that is happening with free resources!!!
doe@harvesting.addys.for.porn.spam JAD
"John Weiss" <jrweiss98155nospamatnospamcomcastdotnospamnet> wrote in message
news:i8mdnbVGFobdU2jY...@comcast.com...
yeah its been a problem here...
2 gigs of ram
system managed virtual
2 X 1.9gigs swapfiles - 1 on each drive
I changed it to min 256 max 1024
all is well with PhotoShop and Illustrator (which were always the first to complain)
so far it has never gotten any bigger than the minimum
kony
Yes, but a fair percent of that is just allocation, not
actual use of the drive for paging data. You will still
have less paging with (enough) memory in the system.
kony
<rod.sp...@gmail.com> wrote:
>> All this is happening with 2 GB RAM installed and over 1.2 GB free, and over 500 MB of pagefile in
>> use!
>
>Doesnt prove a damned thing about whether that is happening with free resources!!!
>
Of course it does, unless you thought he had ~ 800MB of
memory used for the OS alone... otherwise there's a lot of
UNfree resources contending for system time and drive
access.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> John Weiss <jrweiss98155nospamatnospamcomcastdotnospamnet> wrote
>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>>> Yes we can see the pagefile is not only accessed during idle time.
>>>> No we cant. I told you how to prove that and you never did bother to check it that way.
>>>>> Have you ever bothered to look for any
>>>>> system monitoring tools that monitor this?
>>>> Corse I have.
>>> Then you haven't looked very hard...
>> Easy to claim.
>> Pity you havent even managed to grasp the reason Windows
>> uses the page file when there is still plenty of free physical ram.
>>>> You've never produced a shred of substantiation for your stupid
>>>> pig ignorant claim that Win uses the page file when the resources
>>>> are being used when there is plenty of free physical ram.
>>> I am watching the Task Manager Performance page and can see
>>> the PF usage change dynamically while working on something else.
>> Doesnt prove a damned thing about whether that is happening with free resources.
>>> I can also watch the Processes page and monitor what process is accessing the PF.
>> Doesnt prove a damned thing about whether that is happening with free resources.
>>> All this is happening with 2 GB RAM installed and over 1.2 GB free, and over 500 MB of pagefile
>>> in use!
>> Doesnt prove a damned thing about whether that is happening with free resources!!!
> Of course it does,
Of course it doesnt.
> unless you thought he had ~ 800MB of memory used for the OS alone...
Irrelevant to whether that use of the page file that he
can see is BEING DONE USING FREE RESOURCES.
> otherwise there's a lot of UNfree resources contending for system time and drive access.
Thanks for that completely superfluous proof that you have
never ever had a fucking clue about anything at all, ever.
kony
<rod.sp...@gmail.com> wrote:
>> unless you thought he had ~ 800MB of memory used for the OS alone...
>
>Irrelevant to whether that use of the page file that he
>can see is BEING DONE USING FREE RESOURCES.
>
If that's "free resources" then we can as easily argue that
every single thing windows or an app is doing is merely
using "free resources". Use of a bit of CPU time, memory
access, drive controller and drive. Just like having two
apps trying to run alongside each other. You can't *defer*
virtual memory, the whole point of it is that it's actively
happening as needed, but the "need" is a dumb logic that is
too conservative for well endowed systems, depending on how
the amount of physical memory compares to the requirements
of the jobs that system runs. To be most efficient there
would need be a user-selectable or learning profile and a
use pattern that remains fairly static - something we can't
necessarily assume on a PC.
If you're trying to say that windows waits till the system
utilization is low, that's about the last time there was a
need to free up memory, but by paging anything out it
creates the opportunity for the next use session to require
that paged data read back again when it was most important
for it to not be paged out. It can help to page out unused
data ahead of time, but it is done too aggressively within
the assumption it is a good thing to do when it is too often
just a wasted effort, and as mentioned above, then has to be
read back into physical memory because it can't predict the
future without a crystal ball.
What really happens is that applications allocate more
memory than they use, and the pagefile utilization figures
reflect this allocated (but often remaining unused) virtual
memory space. It is not likely that John's system (as an
example since he reported a figure) is actually paging out
most of that 500MB as data rather than just reserved,
allocated virtual space, but nevertheless there is pagefile
access ongoing, it is still a minor performance hit relative
to not having it happen. The question is really whether the
penalty is worse that the potential that having no paging
allocation would result in out of memory errors, something
that depends entirely on the actual uses of the system.
Some people can turn off their swapfile and run like that,
and others will do something mundane like loading a game,
only to find an error generated about 15 minutes into
gameplay (which I have done, the system had ample free
physical memory but windows wanted to allocate more and
doesn't like not being able to do what it wants, regardless
of lacking a real need).
It is slower than not doing it, as it does happen during
NON-idle times, right in the middle of heavy use. It
certainly did when it generated the errors during the
gaming. After investigation I did re-enable the pagefile on
the system exhibiting the problem to confirm this account.
Rod Speed
>>>>>> Corse I have.
>>>> Easy to claim.
>>> Of course it does,
>> Of course it doesnt.
>>> unless you thought he had ~ 800MB of memory used for the OS alone...
>> Irrelevant to whether that use of the page file that he
>> can see is BEING DONE USING FREE RESOURCES.
> If that's "free resources" then we can as easily argue that every single
> thing windows or an app is doing is merely using "free resources".
Mindlessly silly. Win is putting stuff in the page file
and still leaving it in physical ram with resources which
are not being used by the apps or the OS, stupid.
Even you cant actually be THAT stupid, you're clearly
desperately attempting to bullshit your way out of your
predicament and fooling absolutely no one at all, as always.
<reams of your terminally silly shit flushed where it belongs>
> If you're trying to say that windows waits till the system utilization is low,
Succeeding in saying, actually.
> that's about the last time there was a need to free up memory,
With the use of the page file when there is still plenty of free physical
ram, IT AINT ABOUT A NEED TO FREE UP MEMORY, ITS ABOUT
WRITING WHAT WILL BE PUT INTO THE PAGE FILE AHEAD OF
TIME AND LEAVING IT IN PHYSICAL RAM SO THAT IF THERE
BECOMES A NEED FOR MORE FREE PHYSICAL RAM, THAT
STUFF IS ALREADY IN THE PAGE FILE AND THERE WILL BE
NO DELAY WHILE ITS WRITTEN TO THE PAGE FILE.
> but by paging anything out it creates the opportunity for the
> next use session to require that paged data read back again
> when it was most important for it to not be paged out.
WHEN ITS WRITTEN THE PAGE FILE AHEAD OF TIME AND
LEFT IN PHYSICAL RAM SO THAT IF THERE BECOMES A
NEED FOR MORE FREE PHYSICAL RAM, THAT STUFF IS
ALREADY IN THE PAGE FILE AND THERE WILL BE
NO DELAY WHILE ITS WRITTEN TO THE PAGE FILE.
> It can help to page out unused data ahead of time,
Corse it can and thats the reason for that page
file activity when there is still free physical ram.
> but it is done too aggressively
It cant be done too aggressively IF ITS DONE WITH FREE RESOURCES.
> within the assumption it is a good thing to
> do when it is too often just a wasted effort,
Doesnt matter IF ITS DONE WITH FREE RESOURCES.
> and as mentioned above, then has to be read back into physical memory
NO IT DOESNT IF ITS WRITTEN TO THE PAGE
FILE BUT IS KEPT IN PHYSICAL MEMORY TOO.
If there becomes a need for more free physical ram later,
ITS ALREADY IN THE PAGE FILE AND THAT AREA OF
PHYSICAL RAM CAN BE REUSED IMMEDIATELY BECAUSE
ITS ALREADY BEEN WRITTEN TO THE PAGE FILE.
> because it can't predict the future without a crystal ball.
Dont need any crystal ball. IF there becomes a need for
more free physical ram, the physical ram being used by
the stuff thats been written to the page file incase there
becomes a need for physical ram can just be used without
any wait while its written to the page file.
Thanks for that completely superfluous proof that you
cant even manage to grasp even the simplest concepts.
> What really happens is that applications allocate more memory
> than they use, and the pagefile utilization figures reflect this
> allocated (but often remaining unused) virtual memory space.
Thats an entirely separate issue to what is being discussed,
what is WRITTEN to the page file AND LEFT IN PHYSICAL
RAM, so that if there becomes a need for more physical
ram that stuff is already in the page file and the physical
ram is instantly available, because its been written to the
page file already.
<reams of your shit thats completely irrelevant to
what is being discussed flushed where it belongs>
The Rod That Failed
Yeah, it was pretty funny when Rod had his ass nailed to the wall on the
"will the drive spin up is reset is asserted" issue. Thoroughly defeated
and humiliated, all Roddles could do was run away with his tail between
legs while claiming the OTHER guy was doing what Rod was in fact doing -
trying to bullshit his way out of his predicament.
The Rod That Failed
> "Rod Speed" <rod.sp...@gmail.com> wrote...
>>
>> How odd that we aint seen even a single substantiation from you, ever.
>
> The only "odd" thing is your "we". Though you may be blind to reality, that
> is not the case with most posters here.
You are arguing not only with a troll, not only with a kook, but with the
epitome of mental illness and testimony to what some lucky Australian
Mental Health workers have to go through on a routine basis.
Trying not to admit defeat after being wrong for the umpteenth consecutive
time is making the fruitcake writhe around in his straight jacket as he
furiously strikes at the keys with the pencil in his mouth - frequently
pausing to fling away the drool and occasionally stopping to bang his
helmeted head against the wall to relieve some of the frustration.
Rod Speed
The Rod That Failed <rod...@failure.org> desperately
attempted to bullshit its way out of its predicament and
fooled absolutely no one at all, as always.
Rod Speed
kony
<rod.sp...@gmail.com> wrote:
>
>> If that's "free resources" then we can as easily argue that every single
>> thing windows or an app is doing is merely using "free resources".
>
>Mindlessly silly.
Why would we expect you to agree Rod? You're on a roll
recently.
Of course it would reduce the delay to write something to
the pagefile, but not if the system is doing this writing
while it has so much free memory still. It's not just
waiting till there is some arbitrary free/idle time, it
can't work that way because that's not when the virtual
memory is needed - and it can't accurately preidict
everything that might be done with the system so as to page
it all out ahead of time, there's still access ongoing and
that while there is still free physical memory.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>>> If that's "free resources" then we can as easily argue that every
>>> single thing windows or an app is doing is merely using "free resources".
>> Mindlessly silly.
> Why would we expect you to agree Rod? You're on a roll recently.
Yep, done you like a fucking dinner, time after time after time, child.
> Of course it would reduce the delay to write something to the pagefile,
Its FINALLY actually dawned on this fool what is being discussed.
> but not if the system is doing this writing while it has so much free memory still.
Wrong, as always. The time to do it is when there are free
resources, because there may not be free resources later
if there becomes a need for more free physical ram later.
> It's not just waiting till there is some arbitrary free/idle time, it can't
> work that way because that's not when the virtual memory is needed
ITS DONE AHEAD OF TIME SO THAT THERE IS NO DELAY WHEN THERE
TURNS OUT TO BE A LATER NEED FOR MORE FREE PHYSICAL RAM.
> - and it can't accurately preidict everything that might be
> done with the system so as to pageit all out ahead of time,
DOESNT MATTER IF IT DOESNT ALWAYS GET THAT RIGHT WHEN
WRITING THAT STUFF TO THE PAGE FILE IS DONE WITH FREE
RESOURCES. THATS ALWAYS GOING TO BE BETTER THAN NOT
WRITING ANYTHING TO THE PAGE FILE IN CASE IT NEEDS TO
BE IN THE PAGE FILE LATER.
> there's still access ongoing
You dont know that.
> and that while there is still free physical memory.
Pathetic.
Thanks for that completely superflous proof that you have
never ever had a fucking clue about anything at all, ever.
The only viable approach for you now is to shut your stupid trap and hope
that those reading your shit forget your terminal stupiditys as quickly as possible.
kony
<rod.sp...@gmail.com> wrote:
>ITS DONE AHEAD OF TIME SO THAT THERE IS NO DELAY WHEN THERE
>TURNS OUT TO BE A LATER NEED FOR MORE FREE PHYSICAL RAM.
Ok, let's suppost it does an OUTSTANDING job of that, and it
doesn't impact system use at all. However, the system still
had free memory, and that code is now NOT in memory.
What happens when the user finishes the task that causes the
allocations to drop the code frorm cache so it's only in the
pagefile, then goes back to doing what they were previously
which was using that code that is now in the pagefile?
They have to wait for it to be paged back in. If you think
that is not a performance loss you are mistaken and it
certainly isn't free resource related. There are two sides
to paging Rod, what goes out may come back in - otherwise it
was kinda wasteful for the app or OS to have ever read or
generated that code from the HDD (original file?) in the
first place, except as I wrote previously, there is no
crystal ball, it has to rely on a generic logic that is not
suited to all systems or uses, it was tailored to get
conservatively equipped systems running XP.
John Weiss
>
> Of course it would reduce the delay to write something to
> the pagefile, but not if the system is doing this writing
> while it has so much free memory still. It's not just
> waiting till there is some arbitrary free/idle time, it
> can't work that way because that's not when the virtual
> memory is needed - and it can't accurately preidict
> everything that might be done with the system so as to page
> it all out ahead of time, there's still access ongoing and
> that while there is still free physical memory.
I just tried another simple experiment...
Open Explorer. Open the Processes window in Task Manager and activate the
VM column.
Access a folder or network drive with Explorer. Watch the VM usage
increase. Switch to another folder or drive. Watch it increase again.
Access the folder already accessed. Watch the VM usage increase yet again!
So, Windows is NOT simply reserving space for future usage; it is writing
data to the pagefile instead of physical RAM, and is apparently NOT reusing
that data! Neither is this being done "in the background" -- it is being
done at the time of access, by the foreground process!
Eric Gisin
>
> I just tried another simple experiment...
>
> Open Explorer. Open the Processes window in Task Manager and activate the VM column.
>
> Access a folder or network drive with Explorer. Watch the VM usage increase. Switch to another
> folder or drive. Watch it increase again. Access the folder already accessed. Watch the VM
> usage increase yet again!
>
> So, Windows is NOT simply reserving space for future usage; it is writing data to the pagefile
> instead of physical RAM, and is apparently NOT reusing that data! Neither is this being done "in
> the background" -- it is being done at the time of access, by the foreground process!
>
Commit charge (PF usage) is allocation, not actual written.
VM usage is simple allocated memory, nothing to do with pagefile.
John Weiss
>
> No, you do NOT know anything about what is written to pagefile.
> Commit charge (PF usage) is allocation, not actual written.
> VM usage is simple allocated memory, nothing to do with pagefile.
That is not what is indicated by the discussion of Virtual Memory in the
Task Manager Help topics. They relate VM directly to page files.
Eric Gisin
The Rod That Failed
>The Rod That Failed wrote:
>>
>> Yeah, it was pretty funny when Rod had his ass nailed to the wall on
>> the "will the drive spin up if reset is asserted" issue. Thoroughly
>> defeated and humiliated, all Roddles could do was run away with his
>> tail between legs while claiming the OTHER guy was doing what Rod was
>> in fact doing - trying to bullshit his way out of his predicament.
>Some gutless fuckwit desperately cowering behind
What "predicament" would I be in, Roddles?
Why don't you just admit that you were wrong on the "will the drive spin
up if reset is asserted" issue, Roddles?
John Weiss
>>>
>>> No, you do NOT know anything about what is written to pagefile.
>>> Commit charge (PF usage) is allocation, not actual written.
>>> VM usage is simple allocated memory, nothing to do with pagefile.
>>
>> That is not what is indicated by the discussion of Virtual Memory in the
>> Task Manager Help topics. They relate VM directly to page files.
> Nonsense. The description for Virtual Memory does not mention page file at
> all.
Bull!
Task Manager | Help | Task Manager Help Topics | Index | Memory | Usage,
Monitoring | Virtual Memory Size | Virtual Memory
CJT
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
John Weiss
>>
> If your system is paging, buy more RAM.
I got 2 GB. 1.2 GB of that is available. Pagefile use is still 500 MB.
What will more RAM do?
CJT
from _using_ that much.
Vic Smith
Here's a good article on VM/Page File.
It's from MS itself.
http://support.microsoft.com/kb/555223
--Vic
John Weiss
>>>If your system is paging, buy more RAM.
>>
>>
>> I got 2 GB. 1.2 GB of that is available. Pagefile use is still 500 MB.
>>
>> What will more RAM do?
>>
>>
> But is it actually paging? Having 500 MB reserved is much different
> from _using_ that much.
How does one definitively tell what is merely reserved and what is in use?
CJT
John Weiss
>>>
>>>But is it actually paging? Having 500 MB reserved is much different
>>>from _using_ that much.
>>
>> How does one definitively tell what is merely reserved and what is in
>> use?
>>
> Any _real_ OS would have tools for that. See the manual.
Ah... so you just plain don't know...
BTW, I did find the tools and did discover it's really paging some of that.
Eric Gisin
>>>from _using_ that much.
>>
>> How does one definitively tell what is merely reserved and what is in use?
>>
>>
> Any _real_ OS would have tools for that. See the manual.
>