I currently have 3 hard drives on a P4/Windows XP [Home Edition] system.
Here are the drives:

180 Gig
120 Gig
80 Gig

I want to use the 180 Gig as the main drive because it is the fastest, but I
will only need 30 Gigs of that drive to use for programs and for future
upgrades and programs, leaving me with 150 Gigs left. My question is, how
should I set up the partitioning? I know my main partition [30Gig] will be
my Primary/Active partition, but what about the 150 Gig I have left from and
from my other hard drives? Should they all be Primary too? Or Logical or
Extended partitions? Which is better for A/V and why?

Thanks in advance.

Smith

"Smith" wrote:

I currently have 3 hard drives on a P4/Windows XP [Home Edition] system.
Here are the drives:

180 Gig
120 Gig
80 Gig

I want to use the 180 Gig as the main drive because it is the fastest, but I
will only need 30 Gigs of that drive to use for programs and for future
upgrades and programs, leaving me with 150 Gigs left. My question is, how
should I set up the partitioning? I know my main partition [30Gig] will be
my Primary/Active partition, but what about the 150 Gig I have left from and
from my other hard drives? Should they all be Primary too? Or Logical or
Extended partitions? Which is better for A/V and why?

Thanks in advance.

Smith


If your going to use one of the drives for video editing then it needs
to be large as you need about 13 Gigs of free hard disk space for 1
hour of video. It's better to have one hard drive or hard drive
partition only for video work.

Regards Brian

Regards Brian.

"Smith" wrote ...
I currently have 3 hard drives on a P4/Windows XP
[Home Edition] system.
Here are the drives:

180 Gig
120 Gig
80 Gig

I want to use the 180 Gig as the main drive because it is
the fastest, but I will only need 30 Gigs of that drive to
use for programs and for future upgrades and programs,
leaving me with 150 Gigs left. My question is, how should
I set up the partitioning? I know my main partition [30Gig]
will be my Primary/Active partition, but what about the 150
Gig I have left from and from my other hard drives? Should
they all be Primary too? Or Logical or Extended partitions?
Which is better for A/V and why?

Don't partition unless it really buys you some advantage.
I've never found it advantageous to partition my drives.

Putting your C:drive partition on the same spindle as a
partition where you will store A/V data is specifically
recommended AGAINST by most people who do that
kind of work. I agree completely. It will thrash the drive
as it switches back and forth between the C partition and
the other "drive"

I would use the 80G drive as the "main"/boot/C: drive
and the 120G and 180G drives dedicated for A and V files.

Richard Crowley wrote:

Don't partition unless it really buys you some advantage.
I've never found it advantageous to partition my drives.

Putting your C:drive partition on the same spindle as a
partition where you will store A/V data is specifically
recommended AGAINST by most people who do that
kind of work. I agree completely. It will thrash the drive
as it switches back and forth between the C partition and
the other "drive"

Agreed... Use separate HDDs for your system files/software (C and A/V
files (x: where x C)

If you are editing mini DV video, the data rate is only 3.5 MB/s. This is easy
money for todays fast computers and hard drives. As long as you have plenty of
memory and preferably two or three fast drives, it doesn't matter how you
partition or where you store the video footage. I can even store some of the
video on my operating system boot drive and Adobe Premiere never misses a beat
playing the project from the timeline.

The key isn't how you partition or setup your hard drives. The key is getting a
fast computer with plenty of ram and fast hard drives.

Putting your C:drive partition on the same spindle as a
partition where you will store A/V data is specifically
recommended AGAINST by most people who do that
kind of work. I agree completely. It will thrash the drive
as it switches back and forth between the C partition and
the other "drive"

Although it makes things neater as far as finding things and easier to keep
the system up in case of a drive failure, putting the operating system on a
different drive doesn't make a difference either way. When you are recording
something, the computer doesn't "switch" between drives. The program is
loaded and stays in ram the entire time it is being run. There is very
little need to write to the drive that the program is on while you are using
it. Usually only small data and cfg files are written onto the same
drive/dir that the program occupies, certainly nothing to be worried about.
That said. there is the issue of wearing out your OS drive prematurely
(normally it wouldn't be used nearly as much as the data drives), as it is
time consuming to restore the OS and reconfigure your software the way it
was before (although there are software packages out there that automate
this process.) So, good advice, wrong reason :-)

"Romeo Rondeau" wrote in
message

Although it makes things neater as far as finding things and easier
to keep the system up in case of a drive failure, putting the
operating system on a different drive doesn't make a difference
either way.

The OS volume gets most of its program and config file activity during
booting.

That is unless it is also the swap file drive, which is the usual situation.
Swapping is something like half the I/O on a typical running system.

When you are recording something, the computer doesn't
"switch" between drives. The program is loaded and stays in ram the
entire time it is being run. There is very little need to write to
the drive that the program is on while you are using it.

The disk that the program is resident on gets most of its file activity
during program loading and function initiation. Most of the I/O activity
generated by an audio recording and editing program relates to audio data,
not program files. Most programs and subroutines are often not actually
loaded into RAM until their pages are actually referenced. Instead the
programs are mapped as extensions to the swap files. Again, in audio and
video, the programs are usually very small compared to the data. This is
quite different from something like a text editor that is editing a typical
letter or memo. The text editor is then quite large compared to the data it
operates on.

Usually only
small data and cfg files are written onto the same drive/dir that the
program occupies, certainly nothing to be worried about.

Analysis of disk activity during recording and editing shows that the
overwhelming data transfer activity involves to the drive where the data
being recorded or changed is being written to.

I/O for closing and saving a newly-recorded file is often significant. I/O
for saving out of a destructive editor is significant, as well.

OTOH, I/O for doing editing, closing or saving with a non-destructive editor
is very small. The big I/O hit with non-destructive editors comes during
rendering for mixing-down, whichever it is called.

It is very important from a performance standpoint to try to make any
operation that amounts to being file-to-file copy actually be a disk-to-disk
copy.

"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out of
your system drive.

Just pre-allocate the swap file, preferably when the system is new, or when
there happens to be an appropriately large chunk of unfragmented space on
the drive. AFAIK, this option has been available since Windows 286.

Just pre-allocate the swap file, preferably when the system is new, or when
there happens to be an appropriately large chunk of unfragmented space on
the drive. AFAIK, this option has been available since Windows 286.

386, I think, because the 286 didn't support virtual memory. In any case, when
you explicitly specify the size of the swapfile and the drive for it, the
swapfile keeps that size and "stays put" on the drive.

"William Sommerwerck" wrote in message


Just pre-allocate the swap file, preferably when the system is new,
or when there happens to be an appropriately large chunk of
unfragmented space on the drive. AFAIK, this option has been
available since Windows 286.

386, I think, because the 286 didn't support virtual memory.

Right, but Win286 did support swapping. Indeed, Windows 1.0 supported
swapping. However, this wasn't page swapping, it was program swapping.

http://www.upenn.edu/computing/print.../3/winmem.html

In any case, when you explicitly specify the size of the swapfile and the
drive for it, the swapfile keeps that size and "stays put" on the drive.

Right, and it shows up in the XP defrag map as being "unmovable".

Although it makes things neater as far as finding things and easier to
keep
the system up in case of a drive failure, putting the operating system
on a
different drive doesn't make a difference either way. When you are
recording
something, the computer doesn't "switch" between drives. The program
is
loaded and stays in ram the entire time it is being run. There is very
little need to write to the drive that the program is on while you are
using
it. Usually only small data and cfg files are written onto the same

True, if you're not using your computer for anything else during
capture.

However, and I don't think I'm alone here, I like to do _other_ things
with my computer _while_ I capture. And when you do other things, like
navigating the web, downloading and responding to posts in newsgroups,
mpeg encoding, etc. it is _very_ advantageous to have the OS and app
programs on a separate, physical disk, ideally attached to a separate
IDE channel, from the capture drive. And even if that's not possible,
having the capture and OS/apps on the same channel probably won't be a
problem with the busmastering controllers present on any computer able
to be used for A/V.

So for people like me, it does matter.

To the OP,

Why partition at all? Use the 80 for your OS and applications, the 120
for data, scratch disks and the paging/swap file then use the 180 for
capture. Put the 180 on a separate channel from the 80 and 120. This way
the capture file is on a separate drive on separate channel, so there
will be no possible interruption with subsequent potential lost frames
when accessing another disk for system or program activity. All of the
OS and application files will only have to be backed up once (or when
you add new applications) and you can do fast backup of your data files
on a daily basis on the 120. Keeping the paging/swap file on a separate
drive from the capture and OS disk is highly recommended so if the file
does have to be utilized, there's no delay in accessing it.

"Morrmar" wrote in message


However, and I don't think I'm alone here, I like to do _other_ things
with my computer _while_ I capture. And when you do other things, like
navigating the web, downloading and responding to posts in newsgroups,
mpeg encoding, etc. it is _very_ advantageous to have the OS and app
programs on a separate, physical disk, ideally attached to a separate
IDE channel, from the capture drive. And even if that's not possible,
having the capture and OS/apps on the same channel probably won't be a
problem with the busmastering controllers present on any computer able
to be used for A/V.

IME it's a lot more critical to get the swap file separated from the data
than to get the program files separated from the data.

"Arny Krueger" wrote in message
...
"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out of
your system drive.

Just pre-allocate the swap file, preferably when the system is new, or
when
there happens to be an appropriately large chunk of unfragmented space on
the drive. AFAIK, this option has been available since Windows 286.

The swap file is a non-issue with audio apps run on a machine with enough
RAM.

"Arny Krueger" wrote in message
...
"Morrmar" wrote in message


However, and I don't think I'm alone here, I like to do _other_ things
with my computer _while_ I capture. And when you do other things, like
navigating the web, downloading and responding to posts in newsgroups,
mpeg encoding, etc. it is _very_ advantageous to have the OS and app
programs on a separate, physical disk, ideally attached to a separate
IDE channel, from the capture drive. And even if that's not possible,
having the capture and OS/apps on the same channel probably won't be a
problem with the busmastering controllers present on any computer able
to be used for A/V.

IME it's a lot more critical to get the swap file separated from the data
than to get the program files separated from the data.


All of the above, while you're at it.

jb

"Arny Krueger" wrote in message
...
"Morrmar" wrote in message


However, and I don't think I'm alone here, I like to do _other_ things
with my computer _while_ I capture. And when you do other things, like
navigating the web, downloading and responding to posts in newsgroups,
mpeg encoding, etc. it is _very_ advantageous to have the OS and app
programs on a separate, physical disk, ideally attached to a separate
IDE channel, from the capture drive. And even if that's not possible,
having the capture and OS/apps on the same channel probably won't be a
problem with the busmastering controllers present on any computer able
to be used for A/V.

IME it's a lot more critical to get the swap file separated from the data
than to get the program files separated from the data.

This is true, but it doesn't really matter unless your machine has slow
drives, or not enough RAM. More RAM and your swapfile just sits there almost
all of the time. I try to build systems that the drives are 10 times faster
than what's typically needed for throughput. We're only talking about
capturing video, which used to be a big deal but with the drivespeeds that
we have today is not an issue. It was the old train of thought that you
would partition drives to get over the cluster overhead. It's not an issue
with modern filesystems. Seperating the swapfile is a good idea, but I've
found that these days, it's not critical. I'm working on a machine now that
has a stock Windows XP install that the only thing that has been changed is
that it's optimization is setup for background tasks (because I want
priority to go to the ASIO driver which runs as a background task.) True, I
am running seperate drives for OS and recording, but the swapfile being wild
doesn't hamper the system at all. It wouldn't hurt to pre-allocate the
swapfile. Although I can do several things at once without an hiccups
whatsoever, I don't do that kind of stuff on the clients dime. I always use
a RAID controller and at least 2 recording drives.

The program speed isn't as important these days with modern processors,
etc, as disk speed and cache.

Partitioning actually should make a single disk run slower as you need to
access bits of the applications as well as pushing video and audio streams
through the pipe.

The best advice I can give on drives is this:
Use a good well known drive like a Seagate with an 8MB cache. The drives
used on the JVC DR-DV5000 disk recorder are only 5400RPM but the 8MB of
cache helps greatly.

Put the OS on a smaller but still quick drive. Cache size here isn't as
big an issue.

The best part of the advice - put the OS drive and the Video drive on
seperate IDE channels. Put the OS drive on the same physical cable as
your CDROM and the video drive on it's own cable by itself.

The CDROM drives these days are all using at least a PIO mode and are
pretty quick. That on the OS drive isn't so much an issue. Giving the
video drive it's own IDE channel has always given me the best throughput.

SMM

On Mon, 15 Mar 2004 02:43:13 -0800, Smith wrote:

I currently have 3 hard drives on a P4/Windows XP [Home Edition] system.
Here are the drives:

180 Gig
120 Gig
80 Gig

I want to use the 180 Gig as the main drive because it is the fastest, but
I will only need 30 Gigs of that drive to use for programs and for future
upgrades and programs, leaving me with 150 Gigs left. My question is, how
should I set up the partitioning? I know my main partition [30Gig] will
be my Primary/Active partition, but what about the 150 Gig I have left
from and from my other hard drives? Should they all be Primary too? Or
Logical or Extended partitions? Which is better for A/V and why?

Thanks in advance.

Smith

"Romeo Rondeau" wrote in
message
"Arny Krueger" wrote in message
...
"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out
of your system drive.

Just pre-allocate the swap file, preferably when the system is new,
or when there happens to be an appropriately large chunk of
unfragmented space on the drive. AFAIK, this option has been
available since Windows 286.

The swap file is a non-issue with audio apps run on a machine with
enough RAM.

The swap file can be an issue if you want to do something else with the
machine while it's doing something that runs for a while, like a rendering
of a mixdown. When I built this 1 GB 3200+ I thought it would multitask
pretty well, but it really didn't do a lot of multitasking under a heavy
load, until I put the swap file on a drive that never has any active audio
files on it. Night and day!

"Romeo Rondeau" wrote in
message
"Arny Krueger" wrote in message
...
"Morrmar" wrote in message


However, and I don't think I'm alone here, I like to do _other_
things with my computer _while_ I capture. And when you do other
things, like navigating the web, downloading and responding to
posts in newsgroups, mpeg encoding, etc. it is _very_ advantageous
to have the OS and app programs on a separate, physical disk,
ideally attached to a separate IDE channel, from the capture drive.
And even if that's not possible, having the capture and OS/apps on
the same channel probably won't be a problem with the busmastering
controllers present on any computer able to be used for A/V.

IME it's a lot more critical to get the swap file separated from the
data than to get the program files separated from the data.

This is true, but it doesn't really matter unless your machine has
slow drives, or not enough RAM.

The machine I've been talking about is a A64 3200+ with a GB of RAM and 120
GB 7200 rpm drives, one drive per controller. Machine has 4 IDE controller
courtesy of SATA.

I've always found that putting the swap file on a less-used drive pushed
things along nicely. This was the most extreme case yet.

Putting your C:drive partition on the same spindle as a
partition where you will store A/V data is specifically
recommended AGAINST by most people who do that
kind of work. I agree completely. It will thrash the drive
as it switches back and forth between the C partition and
the other "drive"


"Romeo Rondeau" wrote ...
Although it makes things neater as far as finding things and easier to
keep
the system up in case of a drive failure, putting the operating system on
a
different drive doesn't make a difference either way. When you are
recording
something, the computer doesn't "switch" between drives. The program is
loaded and stays in ram the entire time it is being run. There is very
little need to write to the drive that the program is on while you are
using
it. Usually only small data and cfg files are written onto the same
drive/dir that the program occupies, certainly nothing to be worried
about.

Right. But the program (exe) files are not the issue. The swap file
is a significant source of thrashing when sharing a spindle between
OS and data. I was assuming that the swap file is on the same drive
as the OS, etc. (as is the default for most/all OSes)

That said. there is the issue of wearing out your OS drive prematurely
(normally it wouldn't be used nearly as much as the data drives), as it is
time consuming to restore the OS and reconfigure your software the way it
was before (although there are software packages out there that automate
this process.) So, good advice, wrong reason :-)

Drive wear and backup were not taken into consideration. Drives are
so cheap that wear isn't a serious consideration IMHO. The most
important thing to backup are the edits, and original docs/files. Raw
data that is transfered from another medium (tape, HD recorder, etc.)
can always be re-captured. The OS and layered apps can always be
re-installed. I do a re-format and re-install of the OS and apps
around once per year anyway, just to keep things "clean".

Of course these tradeoffs will be different for others under
different circumstances. But putting A/V data and OS/apps on the
same spindle (whether in partitions or not) remains a bad idea.

"Chris Phillipo" wrote ...
One thing I would do is make a seperate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out of
your system drive.

Not necessary with W2K or XP as they allocate contiguous swap file
extents automatically, IME. (As you can see for yourself with the defrag
display.)

Putting swap file on the same spindle as A/V data is never a good idea
whether in a separate partition or not. Even if DV is "only" 3.5Mb/s
there is no reason to tempt Murphy if you can logically avoid it!

In article ,
says...
"William Sommerwerck" wrote in message


Just pre-allocate the swap file, preferably when the system is new,
or when there happens to be an appropriately large chunk of
unfragmented space on the drive. AFAIK, this option has been
available since Windows 286.

386, I think, because the 286 didn't support virtual memory.

Right, but Win286 did support swapping. Indeed, Windows 1.0 supported
swapping. However, this wasn't page swapping, it was program swapping.

http://www.upenn.edu/computing/print.../3/winmem.html

In any case, when you explicitly specify the size of the swapfile and the
drive for it, the swapfile keeps that size and "stays put" on the drive.

Right, and it shows up in the XP defrag map as being "unmovable".


Size it down to a tiny amount, defrag, reset the setting
back up to what you want (I find 1 or 2Gb to be
sufficient).

"Arny Krueger" wrote in message
...
"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out
of your system drive.

Just pre-allocate the swap file, preferably when the system is new,
or when there happens to be an appropriately large chunk of
unfragmented space on the drive. AFAIK, this option has been
available since Windows 286.

I was under the impression that it's not a good idea to define a fixed-size
(maximum) swapfile, but that it was better to let windows manage its size
either in a separate partition, or preferably on a separate drive. The gist
I'm getting here is that it's NEVER a good idea to put it in a separate
partition. But is fixing the size to the max a good thing to do? Or does
it force a lot of extra and uneeded I/O?

Also, do the Rules of Thumb wrt NOT partitioning a single disk still apply
to SCSI disks?

"georgeh" wrote in message


"Arny Krueger" wrote in message
...

"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the
swap file. Stays nice and defragmented without fragmenting the
heck out of your system drive.

Just pre-allocate the swap file, preferably when the system is new,
or when there happens to be an appropriately large chunk of
unfragmented space on the drive. AFAIK, this option has been
available since Windows 286.

I was under the impression that it's not a good idea to define a
fixed-size (maximum) swapfile, but that it was better to let windows
manage its size either in a separate partition, or preferably on a
separate drive.

If you let windows manage its swap file with a small initial size, then
every once in a while everything has to stop while the swap file is
enlarged. If you let windows manage its swap file with a large initial size,
then there are no extensions unless life as your PC knows it is about to
end.

The gist I'm getting here is that it's NEVER a good idea to put it in a
separate partition.

If you let windows manage its swap file with a small initial size, then
putting it in a goodly-sized partition all by itself is almost as good as
letting windows manage its swap file with a large initial size.

Putting the swap file in its own partition is also a way to force the swap
file to be where you want it on the drive. However, I've found that its far
more important for the swap file to operate in pre-allocated space and
rarely or never extend itself, than for it to be in any particular spot on
the drive except maybe at the end where I/O can be quite slow.

But is fixing the size to the max a good thing to do?

IME at worst, it wastes space. We've generally got space to burn, right?

Or does it force a lot of extra and unneeded I/O?

If you give the swap file a large initial allocation, it still only uses
what it needs. No matter what you do except totally eliminate it, the swap
file will absorb about half the I/O power of your system. I've never seen
Windows run in a machine with so much RAM that there was zero swapping when
there was also a swap file. Let me assure you that 1 GB of RAM no way
appreciably limits or eliminates swapping. It simply reduces it some.
Obviously, running in vastly constrained RAM pushes swapping right through
the roof, but once you have sufficient RAM, further reductions in swapping
come at a pretty high price. Furthermore, there is de-facto swapping of
memory-mapped files. But there doesn't usually seem to be a big I/O load
there. YMMV.

Also, do the Rules of Thumb wrt NOT partitioning a single disk still
apply to SCSI disks?

Yes, SCSI and IDE are different and SCSI can be the superior protocol, but
at a fairly basic level they are just two ways to do the same thing.

On 16 Mar 2004 14:51:47 GMT, (georgeh)
wrote:

"Arny Krueger" wrote in message
...
"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out
of your system drive.

I was under the impression that it's not a good idea to define a fixed-size
(maximum) swapfile, but that it was better to let windows manage its size
either in a separate partition, or preferably on a separate drive.

Under Windows 9x, that was probably true, to an extent. The floating
file size ensures you're not wasting space. But it is a performance
hit -- Windows has to adjust the file up and down, which takes time.

If you dedicate a partition to it, there's absolutely no reason not to
set the swap size to the same as the partition size. That makes for
the fastest paging possible. But not necessarily the fastest system
throughput, since you'll spend more time seeking at the start of a
paging operation (eg, heads move from your active partition to your
paging partition).

My educated guess is that this is still generally a win. Most of the
time, you're not paging to the swap file, anyway. Under modern OSs
(definitely under the NT-Windows, Linux, pretty much anything else
that does paging these days), most of the actual paging you do is code
paging, which goes back to the original files, not to the swap
partition. That's for data. Ordinarily, you don't use it. When you do
use it, you want it fast. So the separate partition is reasonable.
Linux and most versions of UNIX do it this way, so I suspect their
designers found this to be the case.

If you're not dedicating a partition, on the NT-based OSs, you have
some control. You can allocate a starting size for your swap file, and
get the inhernet performance improvements, yet still allow it to grow
if necessary. This is probably part of why VM works better in the
NT-based Windows than 9x (I'm sure there are many reasons).

The gist
I'm getting here is that it's NEVER a good idea to put it in a separate
partition.

I completely disagree, at least for the modern versions of Windows. I
don't know enough about paging behavior under 9x to know if it's a bad
idead under 9x (nor would I care, those OSs are no longer pertinent).

But is fixing the size to the max a good thing to do? Or does
it force a lot of extra and uneeded I/O?

Fixing the max size spends disc space you might use for something
else. That's it. Otherwise, it's a performance win.

Also, do the Rules of Thumb wrt NOT partitioning a single disk still apply
to SCSI disks?

All of the same rules apply.

And, for performance tuning, there is NO hard and fast rule about
either partitioning or not partitioning a single disc. When you have
two independent discs (all SCSI drives, assuming you enable
reselection, and ATA drives on separate buses), it's naturally better
to use separate drives rather than separate partitions, far as that
gets you. But partitioning can actually improve performance, depending
on access habits.

For example, consider a digital audio workstation (DAW). Most of the
time in a DAW system, you're not going to be actively paging -- well
tuned DAWs have enough RAM for everything, given today's cheap RAM
prices. When you start up your OS and DAW software, you're doing a ton
of activity on the system drive, nothing on the data drive. Run your
DAW app through its paces for a few minutes, and you may still be
grabbing a little data from the system drive, but fairly soon, all
activity is on the data drive.

It's obvious why dual drives makes this a good situation; and as well,
you can pay more for the data drive, to lower seek times, and save
that money on the system drive. But how about a partition? Within
limits (based on your software and your drive's seek time), you may
well get a faster system with a partition here. Based on the behavior
I described, your flurry of activity on the system drive will be
faster if you restrict all access to one part of the disc. A
partition. Same with the data drive.

The one place you'd lose with the single drive done this way is with
temporary files. It's faster, by far, to locate your temporary files
on your system drive, if you're using a different drive for data,
simply because copies from one to another are common, and it's always
faster to copy drive to drive (even on the same ATA bus) than to copy
within a drive. Partitioning simply makes that drive to drive copy
worse, as you're guaranteeing a longer seek time.
Dave Haynie | Chief Toady, Frog Pond Media Consulting
| Take Back Freedom! Bush no more in 2004!
"Deathbed Vigil" now on DVD! See http://www.frogpondmedia.com

On Tue, 16 Mar 2004 10:37:56 -0500, "Arny Krueger"
wrote:

"georgeh" wrote in message


"Arny Krueger" wrote in message
...

"Chris Phillipo" wrote in message


Just pre-allocate the swap file, preferably when the system is new,
or when there happens to be an appropriately large chunk of
unfragmented space on the drive. AFAIK, this option has been
available since Windows 286.

I was under the impression that it's not a good idea to define a
fixed-size (maximum) swapfile, but that it was better to let windows
manage its size either in a separate partition, or preferably on a
separate drive.

If you let windows manage its swap file with a small initial size, then
every once in a while everything has to stop while the swap file is
enlarged.

Yup. And that's a big operation, compared to the normal act of
swapping.

Though I should mention, in this day of cheap RAM, if you see undue
swapping, performance loss due to swapping, etc. why not spend the $50
and get another big chunk of RAM.

If you let windows manage its swap file with a large initial size,
then there are no extensions unless life as your PC knows it is about to
end.

And, as you learn your applications and common use, you'll know what
size works and what size doesn't. Especially in the NT-based OSs, you
can even manage paging activity. The details reported need work, but
at least you can tell, easily, where your VM vs. real memory is.

In watching that, though, it's important to understand how a modern OS
works. Back in the caveman days, VM was simply a way to ensure you had
more memory for an application. These days, it's a performance hack.
Applications don't have to worry so much about memory, they can do a
big virtual allocation, then let the VM worry about supplying the
memory. An app can virtually load code that might only rarely be
needed, so it's virtually there, but never enters real memory unless
it's called. And in doing this, the OS has more free real memory than
it had in a non-VM system. So the OS adapts to the unallocated memory
pool -- it allocates buffers, etc. to speed things up. It's using the
unused memory to make the system faster. And that, too, shows up on
the memory allocation reports, but it's kind of a false number,
because it'll vanish if your apps need more memory.

The gist I'm getting here is that it's NEVER a good idea to put it in a
separate partition.

If you let windows manage its swap file with a small initial size, then
putting it in a goodly-sized partition all by itself is almost as good as
letting windows manage its swap file with a large initial size.

Or even better, other than the fact the dedicated partition can't
grow. But performance-wise, it can be superior.

Putting the swap file in its own partition is also a way to force the swap
file to be where you want it on the drive.

Exactly why it can be better on performance.

However, I've found that its far
more important for the swap file to operate in pre-allocated space and
rarely or never extend itself,

Yup. The location involved one seek per page fault -- that's probably
under 8ms. The extension operation involves all kinds of disc
activity; probably thousands of times more delay. They don't happen
often, but if you tweak up your system so this only happens in a
panic, or never happens, you'll find the relatively small bit of
permanent space well worth the price.

than for it to be in any particular spot on
the drive except maybe at the end where I/O can be quite slow.

Speed drops a bit toward the center (toward the spindle), since most
drives use a stepped CAV (constant angular velocity) method. Knowing
this, you can allocate you drive space to maximize things. But the
transfer rate isn't usually that critical (though it's most critical
for paging). There's always a trade-off. Put your swap space in the
logical middle of the drive (common in Linux), and your seek to that
swap space is minimized across all code and data. Put it on the outer
tracks, and your seeks could get big, but the transfer rate is
optimal. In general, the former is tbe best configuration, given that
seek transfer, time-wise.

But is fixing the size to the max a good thing to do?

IME at worst, it wastes space. We've generally got space to burn, right?

Or does it force a lot of extra and unneeded I/O?

If you give the swap file a large initial allocation, it still only uses
what it needs. No matter what you do except totally eliminate it, the swap
file will absorb about half the I/O power of your system. I've never seen
Windows run in a machine with so much RAM that there was zero swapping when
there was also a swap file.

However, most of the swapping isn't even involving the swap file. Code
is simply kicked out of memory, files are mapped in as swap space too,
so when code is needed again, it's sucked from its normal location in
memory. That's the only reason you can't delete a running program in
Windows (UNIX, OS/2, etc).

The VM manager wants to take memory for improving system performance.
Chance are, with any sane amount of RAM, the OS is going to think it
can do better than your dormant code. So it'll toss stuff out, even
when there's no memory panic, simply to apply that RAM in the interest
of system performance. So yeah, you will always have swapping, but
it's not necessarily all going to the swap file.

Obviously, running in vastly constrained RAM pushes swapping right through
the roof,

That's called thrashing -- you don't have enough RAM for a "working
set" on the one application (plus driver/OS overhead) you're running.
So it has to page constantly. That should be a thing of the past --
mmeory is just too cheap to deal with that. Your time HAS to be worth
more than, say, $50 a month/year.

bt once you have sufficient RAM, further reductions in swapping
come at a pretty high price.

In fact, the paging that takes place IS intentional. And algorithmic,
too; whether swapping out excess code on a fairly lightly used 4GB-RAM
machine really could ever speed things up, But the OS doesn't really
grok that, so it's still dumping the otherwise worthless code, on some
schedule of age.


Dave Haynie | Chief Toady, Frog Pond Media Consulting
| Take Back Freedom! Bush no more in 2004!
"Deathbed Vigil" now on DVD! See http://www.frogpondmedia.com

Romeo Rondeau wrote:

Putting your C:drive partition on the same spindle as a
partition where you will store A/V data is specifically
recommended AGAINST by most people who do that
kind of work. I agree completely. It will thrash the drive
as it switches back and forth between the C partition and
the other "drive"


Although it makes things neater as far as finding things and easier to keep
the system up in case of a drive failure, putting the operating system on a
different drive doesn't make a difference either way. When you are recording
something, the computer doesn't "switch" between drives. The program is
loaded and stays in ram the entire time it is being run. There is very
little need to write to the drive that the program is on while you are using
it. Usually only small data and cfg files are written onto the same
drive/dir that the program occupies, certainly nothing to be worried about.
That said. there is the issue of wearing out your OS drive prematurely
(normally it wouldn't be used nearly as much as the data drives), as it is
time consuming to restore the OS and reconfigure your software the way it
was before (although there are software packages out there that automate
this process.) So, good advice, wrong reason :-)



I usually partition my drives although I don't have close to the
original poster's amount. Putting windows and all the applications on
one drive isa good idea I think because they et fragmented and so when
you defragment them you don't have to defragment everything you have,
just your operating system and program files, cache, etc. Makes sense to
me anyways.

jason



--
((¯`'·.¸(¯`'·.((¯`'·.¸ * jason bean* ¸.·'´¯))¸.·'´¯)¸.·'´¯))

For me , said Sherlock Holmes, "there still remains the cocaine bottle,"
and he reached his hand up for it.

http://home.cogeco.ca/~jbean3
http://musicpage.kicks-ass.org/

I usually partition my drives although I don't have close to the
original poster's amount. Putting windows and all the applications on
one drive isa good idea I think because they et fragmented and so when
you defragment them you don't have to defragment everything you have,
just your operating system and program files, cache, etc. Makes sense to
me anyways.

It does make sense, I do it myself. It just isn't nearly as critical these
days considering the speed of today's hard disks.

In article ,
says...
On Tue, 16 Mar 2004 10:37:56 -0500, "Arny Krueger"
wrote:
Obviously, running in vastly constrained RAM pushes swapping right through
the roof,

That's called thrashing -- you don't have enough RAM for a "working
set" on the one application (plus driver/OS overhead) you're running.
So it has to page constantly. That should be a thing of the past --
mmeory is just too cheap to deal with that. Your time HAS to be worth
more than, say, $50 a month/year.

Not to mention that thrashing is a good way to kill the
hard drive. How fast? (shrug) Definitely accellerates
the wear-n-tear on the drive heads along with increased
heat from all of the head activity. Think I've killed
one or two drives along the way with thrashing (which is
why all of my machines now have oodles of memory).


bt once you have sufficient RAM, further reductions in swapping
come at a pretty high price.

In fact, the paging that takes place IS intentional. And algorithmic,
too; whether swapping out excess code on a fairly lightly used 4GB-RAM
machine really could ever speed things up, But the OS doesn't really
grok that, so it's still dumping the otherwise worthless code, on some
schedule of age.


WinXP is reportedly a bit too aggressive at paging
things out to disk (compared to Win2000). Even with
lots of memory free, it tends to dump stuff into the
swap file. (Covered somewhat over at the NewsBin Pro
forums with regards to loading up million header
newsgroups.)

"Arny Krueger" wrote in message
...
When I built this 1 GB 3200+ I thought it would multitask
pretty well, but it really didn't do a lot of multitasking under a heavy
load, until I put the swap file on a drive that never has any active audio
files on it. Night and day!


Actually, there are performance benefits to having large drives, each with
their own share of the pagefile. They'd have to be allocated for the entire
pagefile. For instance, Windows recommended pagefile is 1.5 times the
amount of ram for 512 MB, and 1/2 the ram size for 512 MB, leaving the max
size for 3 times the amount of ram in both cases. So let's say you have 512
MB of ram then your pagefile would be 256MB with 1.5 MB as the max. But
you can make that pagefile performance quicker if you have 128 MB on two
separate drives (not partitions). In a circumstance where lots of
applications are running and the OS is frequently changing out code and
data, this offers the ability to pull/put code/data off/on the drives twice
as quick. The more drives you space it over, the quicker the response time
and the smaller the portion of drive used to hold the pagefile.

Where it might be obvious is in a case such as one of my own computers, with
187 gigs of space over 5 drives, the smallest being the 6 GB IBM Deskstar
boot, which is also the slowest of the drives running 16.6 MB PIO Mode 4.
Placing the pagefile on ANY other drive of faster performance will boost
performance of the computer noticeably in the above situation. Spreading it
out to two separate drives will again increase performance, as would over
three drives. Eventually it would be like a squirrel sticking it's head out
of knotholes in a tree, first one side, then the other. After three drives,
for all practical purposes the squirrel has his head out both knotholes all
of the time, so there's no possible performance improvements.

But for those that want to eek out the extreme in performance of pagefile
swapping, spreading it around handles it best.

--


Roger W. Norman
SirMusic Studio

georgeh wrote:

I was under the impression that it's not a good idea
to define a fixed-size (maximum) swapfile,

It can be problematic with an unskilled user.

but that it was better to let windows manage its size

The workaround is then to set minimum "large enough" and not set a max,
and you will still gain the "no resizing" advantage. The resizing issue
is not a large issue in most contexts because windows learns along the
way and settles for "just large enough".

either in a separate partition,

There is generally no reason to do that, unless you want to decide where
on the disk the page/swap file is located.

or preferably on a separate drive.

OS and page/swap file should be on seperate spindles if at all possible.
If a windows version that allows multiple pagefiles is used, then it
should be distributed over all spindles except the one with the OS, with
NT4 a 2 megabyte pagefile on the boot drive (magical word, always the
drive where %windir% resides) is compulsory.

The gist I'm getting here is that it's NEVER a good idea
to put it in a separate partition.

I don't agree. It is a very good idea to have a windows pagefile on a
FAT32 partition with 4 kbyte block size (to fit windows memory map's use
of 4 kb segments) just as it is a good idea to have audio tempfiles that
will not go larger than 4 GB on fat32. FAT32 is a tad faster at
sequential reads than NTFS according to the knowhow I have gathered.
That said: there may be many other concerns overriding this, it is never
whether this or that is good, both often are, but it is what choices are
best for this setup, whatever it may be.

But is fixing the size to the max a good thing to do?

I always do it, my impression from my p2-300 remains that it makes for
the lowest total system overhead, that impression was however from 98.2
and may or may not apply with recent versions. Fixing the size early is
however a vry simple and very efficient way to keep the pagefile
outermost on a drive.

Also, do the Rules of Thumb wrt NOT partitioning a single
disk still apply to SCSI disks?

There are NO rules of thumb with respect to NOT partioning a single
disk, it just can not be said like that. One should however be very
aware that partitioning may cause later problems. Partioning does
however also allow you to select wise block sizes in case of FAT32 and
it keeps any disk problem as may occur smaller.

Partioning may also be an advantage in terms of backup and recovery
strategy. If you want to be able to make disk image backups on a single
drive computer partitioning gets to be quite relevant. The Powerquest
tools are generally very useful.


Kind regards

Peter Larsen


--
*******************************************
* My site is at: http://www.muyiovatki.dk *
*******************************************

"Dave Haynie" wrote in message
...
Under modern OSs
(definitely under the NT-Windows, Linux, pretty much anything else
that does paging these days), most of the actual paging you do is code
paging, which goes back to the original files, not to the swap
partition. That's for data.

Well, not exactly. Windows swaps out code when some application goes
inactive for a while, not just data. Data gets swapped out when the
application is running and needs more space, but code gets swapped out when
it's still up on the taskbar but has gone inactive. Otherwise the
executable code has to be called and it would instantiate a whole new
instance of that application. You can't just reach into an executable and
pull code out. You have to place the code being used into the swapfile
because within the registers being used is the information about where the
data should be returned when the application resumes.

For instance, if the code necessary were to be pulled from the executable in
it's home directory, it would not necessarily set up any registers for data
values of the data already in the system, so it would either crash the
application, or it simply wouldn't know how to find the registers. If the
executable portion of the code had an if/then loop, for example, but it also
zero'd a value for storage of the answer, that value would have no
pertinence to the data that had been restored from the pagefile. Obviously
this is an excellent way to crash an application.

Nope, when you minimize an application and the OS needs the memory space, it
takes both the data and the excuting code and places them into the pagefile,
with all the appropriate information about the EXISTING STATE of the
registers and the code executing on the data.

This is probably part of why VM works better in the
NT-based Windows than 9x (I'm sure there are many reasons).

Not really. VM works better under NT based applications because it truly
allocates operational memory space separately for each application or even
each instance of the same application. Housekeeping for each application is
separate, also, while under Win9X the housekeeping was under ring0
operations that could bring down the whole computer. Now application
housekeeping is done under ring2 within each application space so that a
housekeeping operation can only bring down that particular application.
While that's good for a true multitasking environment and stability, it's
not good because of security risks involved with having housekeeping going
on outside of the highly secured ring0 operations. That's why hackers can
sneak in on applications and why MS has had to fight so hard to keep
patching applications that allow people to sneak in. It also wasn't an
operable part of the original NT 3.51, so applications could bring down the
system, but the system itself was far more secure than NT 4 on up.
--


Roger W. Norman
SirMusic Studio


On 16 Mar 2004 14:51:47 GMT, (georgeh)
wrote:

"Arny Krueger" wrote in message
...
"Chris Phillipo" wrote in message


One thing I would do is make a separate partition just for the swap
file. Stays nice and defragmented without fragmenting the heck out
of your system drive.

I was under the impression that it's not a good idea to define a
fixed-size
(maximum) swapfile, but that it was better to let windows manage its size
either in a separate partition, or preferably on a separate drive.

Under Windows 9x, that was probably true, to an extent. The floating
file size ensures you're not wasting space. But it is a performance
hit -- Windows has to adjust the file up and down, which takes time.

If you dedicate a partition to it, there's absolutely no reason not to
set the swap size to the same as the partition size. That makes for
the fastest paging possible. But not necessarily the fastest system
throughput, since you'll spend more time seeking at the start of a
paging operation (eg, heads move from your active partition to your
paging partition).

My educated guess is that this is still generally a win. Most of the
time, you're not paging to the swap file, anyway. Ordinarily, you don't
use it. When you do
use it, you want it fast. So the separate partition is reasonable.
Linux and most versions of UNIX do it this way, so I suspect their
designers found this to be the case.

If you're not dedicating a partition, on the NT-based OSs, you have
some control. You can allocate a starting size for your swap file, and
get the inhernet performance improvements, yet still allow it to grow
if necessary.

The gist
I'm getting here is that it's NEVER a good idea to put it in a separate
partition.

I completely disagree, at least for the modern versions of Windows. I
don't know enough about paging behavior under 9x to know if it's a bad
idead under 9x (nor would I care, those OSs are no longer pertinent).

But is fixing the size to the max a good thing to do? Or does
it force a lot of extra and uneeded I/O?

Fixing the max size spends disc space you might use for something
else. That's it. Otherwise, it's a performance win.

Also, do the Rules of Thumb wrt NOT partitioning a single disk still
apply
to SCSI disks?

All of the same rules apply.

And, for performance tuning, there is NO hard and fast rule about
either partitioning or not partitioning a single disc. When you have
two independent discs (all SCSI drives, assuming you enable
reselection, and ATA drives on separate buses), it's naturally better
to use separate drives rather than separate partitions, far as that
gets you. But partitioning can actually improve performance, depending
on access habits.

For example, consider a digital audio workstation (DAW). Most of the
time in a DAW system, you're not going to be actively paging -- well
tuned DAWs have enough RAM for everything, given today's cheap RAM
prices. When you start up your OS and DAW software, you're doing a ton
of activity on the system drive, nothing on the data drive. Run your
DAW app through its paces for a few minutes, and you may still be
grabbing a little data from the system drive, but fairly soon, all
activity is on the data drive.

It's obvious why dual drives makes this a good situation; and as well,
you can pay more for the data drive, to lower seek times, and save
that money on the system drive. But how about a partition? Within
limits (based on your software and your drive's seek time), you may
well get a faster system with a partition here. Based on the behavior
I described, your flurry of activity on the system drive will be
faster if you restrict all access to one part of the disc. A
partition. Same with the data drive.

The one place you'd lose with the single drive done this way is with
temporary files. It's faster, by far, to locate your temporary files
on your system drive, if you're using a different drive for data,
simply because copies from one to another are common, and it's always
faster to copy drive to drive (even on the same ATA bus) than to copy
within a drive. Partitioning simply makes that drive to drive copy
worse, as you're guaranteeing a longer seek time.
Dave Haynie | Chief Toady, Frog Pond Media Consulting
| Take Back Freedom! Bush no more in 2004!
"Deathbed Vigil" now on DVD! See http://www.frogpondmedia.com

"Roger W. Norman" wrote in message

"Arny Krueger" wrote in message
...
When I built this 1 GB 3200+ I thought it would multitask
pretty well, but it really didn't do a lot of multitasking under a
heavy load, until I put the swap file on a drive that never has any
active audio files on it. Night and day!


Actually, there are performance benefits to having large drives, each
with their own share of the pagefile. They'd have to be allocated
for the entire pagefile. For instance, Windows recommended pagefile
is 1.5 times the amount of ram for 512 MB, and 1/2 the ram size for
512 MB, leaving the max size for 3 times the amount of ram in both
cases. So let's say you have 512 MB of ram then your pagefile would
be 256MB with 1.5 MB as the max. But you can make that pagefile
performance quicker if you have 128 MB on two separate drives (not
partitions). In a circumstance where lots of applications are
running and the OS is frequently changing out code and data, this
offers the ability to pull/put code/data off/on the drives twice as
quick. The more drives you space it over, the quicker the response
time and the smaller the portion of drive used to hold the pagefile.

I'm a long time advocate of multiple small page files when it fits, going
back to the 1980s and my former life as a VM/CMS system programmer. However,
one has to consider the situation very carefully.

On the VM/CMS system I had about 40 active users and as long as most of them
could get page service, I was a happy camper. I had up to 8 devices on two
channels with page files on them, so there was almost always a clear path to
some page that was needed, some place. Work progressed in general even if
one user was tied up for a while.

On my XP systems there is just one user, and he is me so he must be kept
VERY happy. ;-)

The place where multiple distributed page files run into trouble is when
there is also a heavy I/O load on a device that has a page that needs to be
swapped in for the action to proceed. In a multi-user situation, that
particular user or small group of users is dead in the water, but the other
users usually get good service. In a single user situation, anything that
holds up that one active user is a bad thing.

IDE drives multitask rather poorly, as a rule. SATA does not seem to change
this. SATA is just about trading off silicon for copper and vinyl. However
in the current transition atmosphere, SATA leads to motherboards with a
profusion of IDE controllers which is a good thing if you exploit it.

I periodically move big files into an archive folder on my swap drive, and
it's mostly dedicated to paging yet the space is entirely useful. I favor
large devices as on the average and all other things being equal, bigger
devices are faster. Right now 120 GB seems to be the sweet spot for
price/performance. Tune in next week, it might change.

I've experimented with split swap files, but always returned to the idea of
a lazy volume with the one swap file on it. If the swap volume becomes
inaccessible at boot time, XP auto-allocates a swap file on the boot volume.

In the current context, its very economically attractive to just add RAM to
reduce paging, up to the 1 GB point. When you have just one page volume,
managing its I/O rate can be very important.

On the average a page is paged in twice for every time it is written, so
this is a case where mirroring can provide a substantial performance
advantage, since an I/O busy for reading on one half the mirrored set is
routed to the other drive.

"Dave Haynie" wrote in message



Under modern OSs
(definitely under the NT-Windows, Linux, pretty much anything else
that does paging these days), most of the actual paging you do is code
paging, which goes back to the original files, not to the swap
partition. That's for data. Ordinarily, you don't use it. When you do
use it, you want it fast. So the separate partition is reasonable.
Linux and most versions of UNIX do it this way, so I suspect their
designers found this to be the case.

AFAIK, since Windows NT (1993), there has always been Windows support for
memory-mapped code and data.

Win95 picked it up from NT.

Code paging is very advantageous because it speeds program loading by both
minimizing and deferring I/O and real memory use until it is actually
needed.

However, code paging has natural limits on it, such as the code can't be
modified in RAM in actual use. You don't want to change a program library on
disk every time you use it.

With a data file, you do want the data on disk to be modified if its
modified in RAM.

Here's a reference that covers some of these issues for newbies:

http://www1.cs.columbia.edu/~novik/c...tes/lect08.ppt

... You can't just reach into an executable and
pull code out.

Yes you can. It is what all the newer OSses do (NT, linux, most unixes
released in the last 20 years or so). Simple proof: Executable file of 20MB
that uses only 1 MB (total) memory.
Better proof: Read the documentation for the NT kernel.

On UNIX systems, you can prove this quite well by creating a shared library,
say "shared.so" with a function hello() that just dumps "hello world" on std
out. Create an executable, load shared.so and call hello(). Then go to sleep
until the use presses a key, and call hello, then wait for a key, etc..

Be root, and use a hex editor to change "world" into "all!!" in the
shared.so on disk.

Wake up the program, it will probably still print "hello world".

Now put some serious heavy load on the system (e.g. while fork()
malloc(100000)

Make sure the system is running out of memory.

Wake up the hello application, and chances are that it will now print "hello
all!!"

This is quite a known problem on Solaris systems. Replacing a library would
often crash running application because it would fetch pages from the newer
lib into the old lib in memory.

On Wed, 17 Mar 2004 07:56:42 -0500, "Roger W. Norman"
wrote:

"Dave Haynie" wrote in message
...
Under modern OSs
(definitely under the NT-Windows, Linux, pretty much anything else
that does paging these days), most of the actual paging you do is code
paging, which goes back to the original files, not to the swap
partition. That's for data.

Well, not exactly. Windows swaps out code when some application goes
inactive for a while, not just data. Data gets swapped out when the
application is running and needs more space, but code gets swapped out when
it's still up on the taskbar but has gone inactive. Otherwise the
executable code has to be called and it would instantiate a whole new
instance of that application.

Nope. NT's memory manager is largely based on VAX/VMS, which I know
considerably better than NT. But either way. In both OSs, code is file
mapped into VM (in NT, this pertains to both applications and DLLs).
The is true of most modern OSs -- you don't swap code to the swap
parititon/file, you simply re-load from disc. OS/2, for example, did
this long before there even WAS a Windows NT.

You can't just reach into an executable and pull code out.

Sure you can. Why not? Code NEVER changes. Same reason you only need
to load one image of an application, regardless of how many copies you
run (again, in modern OSs). That's why fork() is even reasonably
efficient in UNIX/Linux.

In NT, the executable file is file-mapped when you load an executable.
The whole file is mapped, as-is, into virtual memory (it may or may
not be full loaded into real memory at this point). When a piece of
code hasn't been used in awhile, the page is simply marked as
uncommitted. If it's needed again, the page will fault, the OS will
re-map the page back from the executable file.

You have to place the code being used into the swapfile
because within the registers being used is the information about where the
data should be returned when the application resumes.

Registers are DATA, not code. They're unrelated. And you don't write
registers to swap space, anyway -- you only swap out code that's not
running. Registers are saved as part of the task/process contect frame
within the OS.

For instance, if the code necessary were to be pulled from the executable in
it's home directory, it would not necessarily set up any registers for data
values of the data already in the system, so it would either crash the
application, or it simply wouldn't know how to find the registers.

What registers? Code, pre-defined data, and process-specific data all
occupy totally different segments in the executable, and totally
different pages in a working program. The code pages are read-only in
NT and virtually every other OS; you'll crash the application with a
page-fault exception if you attempt to write to a code page. Not true
back in the MS-DOS days, (I'm not sure about Win9x), but of course,
MS-DOS didn't have VM or thousand of other "real OS" features.

Most modern OSs (and I was fairly sure this was true of NT, though I
didn't check just now), including OS/2 and UNIX, support uncommitted
code loads, based on this same principle. You basically map the code
segments from the executable to the page table, but don't actually
load them. The VM system then proceeds to load them, on demand. This
is why system like UNIX, Linux, BeOS, etc. can use gigantic shared
system library modules without worrying about efficiency -- only the
code actually used (well, within a demand page size, usually 4K) is
ever loaded.

If the
executable portion of the code had an if/then loop, for example, but it also
zero'd a value for storage of the answer, that value would have no
pertinence to the data that had been restored from the pagefile.

Again, you're confusing code with data. The loop (if/then isn't a
loop, it's a conditional, but whatever) itself resides in a code page.
The variable COULD reside in a data page, but your example, it's
almost certainly stored on the stack, which is yet a different kind of
data page.

Nope, when you minimize an application and the OS needs the memory space,

And by the way, paging has nothing to do with "minimizing an
application". The VM system drops pages based, usually, on a
modification of the LRU algorithm (least recently used; a common
modification is called the "Clock" algorithm -- look it up if you're
interested).

When you de-focus or minimize an application, you're not longer
interacting with it, but it (or portions thereof) are often still
running.

The VM system itself really don't pay attention to individual
application, but the page replacement algorithm is based on a global
evalutation of every process (applications are processes, but so are
dozens of other programs, run by the OS, drivers, etc). Basically,
every process in NT has a defined working set maximum, the maximum
number of pages expected in that app's working set. This maximum is
defined dynamically by NT, based on the total available memory, but
also guided by a process's ability to provide an estimate of its
needs.

When an application needs a new page, and it's at it's working set
maximum, an old page will be reused (first flushed to the swap file,
but only if it's a dirty page -- a data page that has changes). If the
app isn't near it's maximum working set, the other processes are
"trimmed" (MS likes that term, rather than "page stealing"), based
first on being over their working set limit. This is designed to offer
a compromise between local and global paging effects. It also explains
(better than I had head before) why your application might be paging,
even when the system seems to otherwise have enough memory.

A good part of MS's page replacement algorithm is designed to be
CPU-independent (as is NT in general). They apparently have a few
x86-specific tweaks, but largely the OS does its own page management
calculations, rather than relying on special features of the CPU
(obviously, of course, the MMU-specific code is in there, but it's
part of the HAL).
Dave Haynie | Chief Toady, Frog Pond Media Consulting
| Take Back Freedom! Bush no more in 2004!
"Deathbed Vigil" now on DVD! See http://www.frogpondmedia.com

Nope, when you minimize an application and the OS needs the memory space,

And by the way, paging has nothing to do with "minimizing an
application".

Actually the prior poster, even though apparently ignorant about how his (or
hers) system works, is closer to the truth than you'd expect. NT 3.5 would
do a sort of "garbage collect" when you minimized an application. Don't
recall the exact details, it was probalby something like GlobalAlloc(-1) but
it's way off topic anyway.

On Tue, 16 Mar 2004 10:37:56 -0500, "Arny Krueger"
wrote:

If you give the swap file a large initial allocation, it still only uses
what it needs. No matter what you do except totally eliminate it, the swap
file will absorb about half the I/O power of your system. I've never seen
Windows run in a machine with so much RAM that there was zero swapping when
there was also a swap file.

What exactly do we mean by "swapping" nowadays? Swapping chunks of
program code in and out of inadequate physical memory is surely
history? Windows XP seems to like having a swap file, but doesn't
appear to do anything at all with it on my recent systems. I've
rendered huge video files which, according to some people, ought to
increase page file usage enormously. But no, the usage graph just
sits there. Unless I'm actually loading a program, or playing/saving
audio, music or other files, there's rarely a flicker from my HD
activity LED. Certainly nothing to indicate that "about half the I/O
power of my system" is being used.

Are you suggesting that when data on the hard drive is required, it is
routinely loaded to memory, only to be paged back out to the hard
drive, thence back into memory........ A rather odd procedure, to
say the least :-)

CubaseFAQ www.laurencepayne.co.uk/CubaseFAQ.htm
"Possibly the world's least impressive web site": George Perfect

On Wed, 17 Mar 2004 07:56:42 -0500, "Roger W. Norman"
wrote:

Nope, when you minimize an application and the OS needs the memory space, it
takes both the data and the excuting code and places them into the pagefile,
with all the appropriate information about the EXISTING STATE of the
registers and the code executing on the data.

Isn't that the nub? WHEN THE OS NEEDS THE MEMORY SPACE. My
experience of today's systems is that even if a program has been
closed (not just minimised) and another run, the first will generally
reopen very quickly. Because program code is now generally small
compared to physical memory, Windows DOESN'T need the memory space,
so it caches recently-used program code "just in case".

CubaseFAQ www.laurencepayne.co.uk/CubaseFAQ.htm
"Possibly the world's least impressive web site": George Perfect

Gee, and after all those years as an NT MVP. Damned glad I gave up 25 years
of computer work to move into audio.

--


Roger W. Norman
SirMusic Studio

"Mike Looijmans" wrote in message
...
Nope, when you minimize an application and the OS needs the memory
space,

And by the way, paging has nothing to do with "minimizing an
application".

Actually the prior poster, even though apparently ignorant about how his
(or
hers) system works, is closer to the truth than you'd expect. NT 3.5 would
do a sort of "garbage collect" when you minimized an application. Don't
recall the exact details, it was probalby something like GlobalAlloc(-1)
but
it's way off topic anyway.

"Smith" wrote in message
news:3Nf5c.32133$Zp.7798@fed1read07...
I currently have 3 hard drives on a P4/Windows XP [Home Edition] system.
Here are the drives:

180 Gig
120 Gig
80 Gig

80 GB--OS+Program Files
120GB-Capture/Storage
180GB-Capture/Storage #2

It makes sense and using the 180 as the main drive means that you will be
depriving yourself of the largest and most needed drive
in the capture chain

JeffH
Ch.S.